Comparing to my output with logging, those are probably dlist files, but you can look in Google Drive.
Backup below is kind of small, but maybe you have one with lots of files so the dlist comes to 60MB:
Because Duplicati is oriented around a database. This tells it what versions there are, what files are in a version, where to find the blocks of the files that need to be put back together for your restore, and so on. Duplicati.CommandLine.RecoveryTool.exe takes a different approach but it might download more data…
How the backup process works
How the restore process works
Don’t rely on the names in /tmp. The generic plan for naming is that the file begins with dup-. Duplicati knows what’s inside, but it’s hard for you to know except by size and maybe copying it and looking in it. Running at an enhanced log level would also give you the remote name, but you can’t set it up mid-run.
That would be associated with an SQLite database of same name without the suffix. If journal is getting larger after watching it for awhile, you’re probably still in the process of getting a temporary database up.
That starts after a successful database rebuild, however your experience with GUI makes me think you won’t get one. You can let this run and see if it gives you 1602 warnings again, or try this a different way.
For best chances of getting everything, use Duplicati.CommandLine.RecoveryTool.exe, which explains:
This tool can be used in very specific situations, where you have to restore data from a corrupted backup. The procedure for recovering from this scenario is covered in Disaster Recovery.
Any full restore will need a lot of downloading. If the goal is just to look to see what files are present, there might be some other ways. You don’t seem to be using encryption, so you can just open a dlist .zip file. Inside is a filelist.json file (see above “How” articles if you like) which is a long line with files and their info:
[{“type”:“Folder”,“path”:“C:\backup source\exclude2\”,“metahash”:“byLC8ETJHhEJjfN9ipe+NSGO83/WAu2NzvNmQMohffw=”,“metasize”:139,“metablockhash”:“byLC8ETJHhEJjfN9ipe+NSGO83/WAu2NzvNmQMohffw=”},{“type”:“File”,“path”:“C:\backup source\A.txt”,“hash”:“VZrq0IJk1XldOQlxjN0Fq9SVcuhP5VWQ7vMaiKCP3/0=”,“size”:1,“time”:“20201121T225725Z”,“metahash”:“hrBVpOwh+sSaiR+cg+GWpnSsnYPxuOKQ7/lmZBhkYM0=”,“metasize”:137},{“type”:“File”,“path”:“C:\backup source\exclude2\empty.gify”,“hash”:“47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=”,“size”:0,“time”:“20210323T165612Z”,“metahash”:“mtpO5hgKUEfN5tSeQ/u1XwZUfsL52TGx3vaMFaZWoEQ=”,“metasize”:137}]
Database management Repair button would be one way, if you wanted to try to set up a job, otherwise recreate is sort of implied by restore request without a database. Another option is to explcitly do repair:
If no local database is found or the database is empty, the database is re-created with data from the storage.
One advantage of doing it this way is that I believe you can say –version=0 for latest, which might avoid processing all of your versions. Does it seem plausible that you have over 90 dlist files in Google Drive?
tempdir describes it. Note that for most complete DB results you might want to use the TMPDIR method.
If you’re going to add that option, please raise logging level as well, and possibly even get a log-file using log-file-log-level=verbose to get output at the level of my third screenshot. It also avoids screen clutter… Peek at it with tail or less if you want the story behind what the screen is showing at its default output.
Please do consider what you’re trying to do. Troubleshoot original warnings? See file info? Restore files?