Did you ever see it? If not, it didn’t disappear, it was never added. I think it’s added after backup is done.
Stopping the backup in a controlled manner, such as using “Stop after current file” will log it as a partial.
These are also restartable just by doing another backup. Power-fail on initial backup is a messier issue.
Nothing easy, but if you want to do an experiment to reconnect the remote files to the backup, look here.
I haven’t used it in exactly your case, but I did just try it out on a backup where I deleted the remote dlist, which is similar. The dlist file records all the files backed up, and it too is recorded only at end of backup.
Although unexpected backup interruptions do happen, the initial backup is the most sensitive because a filelist (a remote file with dlist and a date in its name – look for one in finished backup) hasn’t uploaded.
Having the initial backup be a small one (critical files or just random) first prevents the no-filelist problem.
EDIT 1:
If you want to try the experiment, I can give a tentative list of directions beyond what the linked topic gave.
It’s somewhat involved, but can probably be finished in less than an hour (if it works at all) after starting it.
EDIT 2:
Default parallel uploading these days adds some uncertainty (compared to my test) to what got uploaded. This may cause the Recreate to download more, but some Internet connections download faster. Yours?
EDIT 3:
Not so sure the extra downloads can happen (which is good because B2 charges). I got an error instead.
Steps list is something like this, however it certainly hasn’t been tested with your exact situation. Care to?
-
If backup is encrypted, install AES Crypt to decrypt and encrypt .zip files as needed.
-
Create a backup to a local folder of some small file. Don’t bother encrypting. Run it.
-
Open the dlist .zip in its folder, copy filelist.json somewhere, drag it into notepad.
-
Edit the file so contents are the two characters
[]. Save it then drag to update .zip. -
If the remote backup is encrypted (.zip.aes), use AES Crypt to also encrypt this file.
-
Copy the file to the remote. Though it names no files, it will avoid missing filelist.
-
Edit the remote backup job to have no-auto-compact checked, to avoid unwanted actions.
-
Press the Recreate button on the Database screen. Watch progress bar advance to right.
-
If a dindex file got to the destination ahead of its associated, dblock, error is like
2020-10-11 19:07:44 -04 - [Error-Duplicati.Library.Main.Operation.RecreateDatabaseHandler-MissingFileDetected]: Remote file referenced as duplicati-b42c95467115040cb9d6f5fecd3e41e33.dblock.zip by duplicati-ibf2836edd79e4a3899c61513ff871d4d.dindex.zip, but not found in list, registering a missing remote file
Bad reference can be fixed by deleting the dindex file. Repeat until Recreate is fine. -
Run the remote backup, and the hope is that it will reattach to already uploaded data.
The database Recreate should have recorded what was remote already, so it should know.
The standard deduplication feature reuses known blocks in new backups to avoid upload.
At some point during backup, uploaded blocks will run out, and new blocks will upload. -
If backup finishes, try a test restore with no-local-blocks set to ensure downloading.
-
You can remove the no-auto-compact option if all is well. Usually you want compacting.