“2025-12-01 18:30:18 +02 - [Warning-Duplicati.Library.Main.Operation.FilelistProcessor-MissingRemoteHash]: Remote file duplicati-b3f59b1f53a5e42308f11319dced19e54.dblock.zip.aes is listed as Uploaded with size 35913728 but should be 51407597, please verify the sha256 hash "nTvz4xU7zxnvPcoxI7SvVwIcMs0oHmm6E0wYXYllVzc="”
I tried purge-broken-files
Listing remote folder ...
Remote file duplicati-b3f59b1f53a5e42308f11319dced19e54.dblock.zip.aes is listed as Uploaded with size 35913728 but should be 51407597, please verify the sha256 hash "nTvz4xU7zxnvPcoxI7SvVwIcMs0oHmm6E0wYXYllVzc="
Remote file duplicati-b547a68e0df13411fb2a399b3732c8605.dblock.zip.aes is listed as Uploaded with size 35651584 but should be 51789021, please verify the sha256 hash "pi0x8N1g2IyN77/T7YrZDTf7HR2sBZpeU6+Ig06UDAU="
Remote file duplicati-b4391aee6078f4555ba98c0e3b65dca84.dblock.zip.aes is listed as Uploaded with size 35586048 but should be 51893037, please verify the sha256 hash "/OuFt8xNmfphG944YigyOMAgkjybqD8dXWV7jH8EVVo="
Remote file duplicati-bf426ae80110f43f1b0152b388060ec92.dblock.zip.aes is listed as Uploaded with size 15466496 but should be 51529501, please verify the sha256 hash "31IrkAOwiqj3Wwyv0ACJXddGObh1Qx4e5x5T2+mREMg="
Return code: 0
I renamed all four files to include a prefix of old- ex. old-duplicati-bf426ae80110f43f1b0152b388060ec92.dblock.zip.aes and ran the purge-broken-files once more:
The two numbers are not comparable, as they are different types of files.
You did the right thing in making 4 damaged dblockcompletedly hidden.
The purge-broken-files would purge whatever files they had affected.
Since a dlist file says what files are in that version, some get updated.
If it’s not complaining, that’s an improvement. How do you usually test backup?
One good one to practice occasionally is to see if Database will recreate nicely.
Rename the old one or copy it somewhere just in case recreate problem arises.
Testing restore is good too. You can also use The TEST command on all files
(however it can be a big download if remote) to check that file hash look correct.
The routine verification of all files is only a size check, because that’s really fast.
Thanks for the continued support, and for pushing me to actually test my backups. That’s a good practice for anyone doing backups. To check if their data they expect to backup, is being backed up and that it can be restored. Randomly picking some data from different locations, and attempting to restore them from time to time.
As for the database, can you elaborate (or point me to an up-to-date documentation that explains how to go about this?
For ex., where’s the database? On my own PC where my Duplicati is running or is it on the remote destination, where my backups are being stored?
I was able to track down the path where the database is (from the web UI, under my backup job’s context menu → Database → Placement, but I see two .sqlite files
These are same DB, in Placement, and neither is Server DB.
The local job per-backup DB name is <random-letters>.sqlite.
In 2.2.0.1 the buttons look like below:
The Restore button name will change, but function is the same.
I’m suggesting you either manually copy DB then click Restore,
or manually rename the DB in Explorer, then you’d click Repair.
If DB has any problem, you then can move your old DB back in.
Ordinarily if DB is lost, you just recreate it. If it resists, you can restore using Duplicati Recovery Tool which is more forgiving of problems, but not as nice.
Job configuration (meaning what you type when creating job) is in server DB.
Losing that can lose data access unless you saved critical info to restore with Direct restore from backup files (which lists the sort of critical info you’ll need).
To preserve your job’s full configuration (critical info plus the rest), use Export.
