If local files means source files, Repair won’t touch those. It’s a DB process to reconcile with the backup, however there’s a known issue when an old DB is restored (e.g. from an image backup) and Repair runs.
Apparently the stale DB is a convincing enough DB that agreement with remote is made by deleting new files from remote. Not good. I just did Repair to a totally new empty DB, and it rebuilt the DB from remote. Using the Recreate button deletes the old DB first, so there’s no chance of accidental damage to remote.
This is the one that got to 1 TB and never finished (and never made its dlist, so it won’t recreate) I believe.
It’s also the original debug target, but it takes two weeks to get to the 1 TB. If there’s anything left of its DB then looking inside may be possible. If the DB is gone, and no log files exist, then all there is is your recall.
You can see if the DB in the Database page has a plausible size. if it’s below 1 MB it’s probably too empty. You can also see if you can spot any history on anything in the job’s Show log General or Remote pages. Finding older history would mean there’s something to look at or work on. If it’s extremely new, that’s bad.
Duplicati can ordinarily resume an interrupted backup from where it left off, but yours was getting an error. Possibly the problems in Docker contributed, but I guess first step is to see if there’s any sign of a DB left.
I do have an experimental method that “might” be able to make use of your backup files even if DB is gone, however I’d prefer if the original DB is still there, as there’s a chance it has clues. A big log might do better, however it’d be nice if we didn’t have to wait 2 weeks for something to fail before having some information.
I suspect the Repair button on the 1 TB partial will wind up in “No filelists found on the remote destination”, because I think Duplicati runs repair internally before the backup if needed, and that might go into recreate.
Tries to repair the backup. If no local database is found or the database is empty, the database is re-created with data from the storage. If the database is in place but the remote storage is corrupt, the remote storage gets repaired with local data (if available).
but there’s a lot of uncertainty about how much of a database existed at what times during all the testing.