I’ve been using the --upload-verification-file option and notice that this results in a single verification file that is overwritten each time the backup is run. If a backup is interrupted during the upload, this could result in an incomplete/unusable verification file in the repository, with no backup one to revert to.
My suggestion is to upload a time-stamped verification file instead with each dlist file. That is in alignment with Duplicati’s philosophy of making backup sets as resilient as possible regarding corruption of individual files. I realize the verification file is just an added layer of redundancy/convenience, but it would be good if it aligned with the approach taken with the rest of the repository files.
I suppose we could use the same timestamp as the dlist file already uses. This would also make the filenames alphabetically sortable, making it easy for a script to find the newest.
Here’s another idea for an enhancement: Include the date each file was last verified against the hash in the uploaded verification file (to go with Repository validation & contents UI module). That way the verification status/history of the repository can also rebuilt using the data in the repository if the database is lost. This would save a lot of time re-verifying files if the DB is lost.
so, this isn’t implemented so far? just tried to solve a problem with the --upload-verification-file option, and found only a duplicati-verification.json file in the backup directory.
in fact, think there’s also a bug with this option…adding --upload-verification-file to an already existing backup gives an error
Object reference not set to an instance of an object.
…while uploading the verification file. The option works though when added to a new created backup(job).
I’m using 2.0.3.4 canary and just tested adding --upload-verification-file=true to one of my existing test backups. The file was added at the destination and I didn’t have any object reference errors.
used 2.0.3.3 beta and now updated to 2.0.3.5 canary under Win7x64 – same result. When adding the option to an already existing job, it ends with the same error.
This topic has been flagged as planned so it sounds like it’s made it to the roadmap, though I couldn’t say when it will arrive.
In the mean time, what happens if you manually create an empty duplicati-verification.json file at the destination (or copy one over from another destination)?