A few days ago, I began receiving the following warning on a backup that has been running without incident for a couple years. I’ve search the forums for similar questions. All the ones I found seem to involve backups to an SMB share, but that’s not the case in my system. The system is running Linux Mint 20.3. Duplicati is backing up to an internal hard drive in a removable bay, mounted as local storage.
Some of the solutions offered include running Verify, which confirms the warning. I then ran Repair, which reports "Failed to perform verification for file: duplicati-b87e318a075f34cd3a08a73f8c25638b3.dblock.zip, please run verify; message: Object reference not set to an instance of an object."
Instructions in other threads also suggest running ‘Purge broken files,’ but I can’t find that feature anywhere.
This ‘MissingRemoteHash’ is a bit misleading, since (as the full error message suggests), it’s really a matter of bad or missing remote data. What has (probably) happened here is that the backend had a bad problem after Duplicati had terminated (from its point of view) the uploading of data and some files have been corrupted and can’t be used.
To clean these files, first never ever touch directly them on the backend, it must be done through Duplicati so it can clean its local state in sync with the remote changes.
So, select your backup in the Web UI, click on Advanced / Command line, you’ll see the backup command selected, change it to ‘purge broken files’, remove the files to backup and the filters (these parameters don’t make sense for purge broken files) and click the Run button (bottom right).
You can first list the broken files to check what the purge will do, if you can list more than your 13 files take some more time to assess the situation, else go for it. Good luck.
Well, reading again your post and my reply, I think I got the ‘13 bad files’ from another post
You have only one bad file.
I’d try to see if it is concerning real data by using the ‘affected’ command (replace the backed up files by the actual name of your remote file), then if it’s returning none or an error, try to see if it’s part of the last backup or not (with the file date) and if yes, delete the last backup (if you are sure it will not delete important data that you could have removed from the source).
To delete the last backup, use the ‘delete’ command and add an additional parameter ‘version’ and set it to 0.
Hmm, the backup still warns about that file. I’m not too concerned about losing the data in this backup, but I’d rather not lose the whole history. You suggested deleting the “last backup.” I don’t see how to do that. All I can see is to delete the entire backup with all its versions.
Possibly the one exception to not touching files is that list-broken-files seems to need to see a missing destination file before it considers source files broken. If you like, giving it a new prefix or moving will do.
Looking at the file’s time (if plausible) might give some clue about when the file was made or damaged.
Have you had any filesystem issues, or maybe the removable bay got removed at an inopportune time?
When such size errors come up, I usually do a decimal-to-hex because even value suggests filesystem.
33554432 turns out to be 2000000 in hex. That might set a new record for a suspicious super-even size.
You should be able to list and purge the broken Synaptic source files. I’m glad they weren’t important files.
yet that’s quite doable. After selecting delete and emptying the ‘commandline arguments’ box, scroll down all the way and pick an advanced option, select ‘version’ from the ‘core options’. Enter a 0 in the value. Then click run. The last backup version should be removed (marked deleted to be purged later)