Now that Backblaze supports refundable snapshots-by-mail, I thought it would be fun to order a copy of all my backup repositories and verify them. The idea seems sound: I can do
duplicati-cli test '/mnt/Backblaze Snapshot/bzsnapshot_2018-04-09-18-54-36/my-repository-name all --dbpath=/root/.config/Duplicati/BLAHBLAH.sqlite --full-remote-verification --passphrase=blahblah
and it works correctly as long as the repository is still in sync with my local database. But that’s usually not true, and in those cases I get a bunch of errors about missing or extra files. Which makes sense, since the remote files that I’m verifying are no longer in sync with my local database.
But is there a correct way to accomplish this? Can I verify my remote backup without using the local database files?
When listing contents or when restoring files, the local database can be skipped.
This is usually slower, but can be used to verify the actual contents of the remote store
But I’m not sure if it can be used with the test command.
Otherwise you’d have to recreate the DB a lot of times, which doesn’t seem ideal.
Hmm, I just tried --no-local-db. But as you expected, it doesn’t seem to have any effect on test.
My real goal is to get a strong verification that my B2 snapshot is, in fact, a good backup. I could do this by restoring several files and doing spot-checks. But it would be very nice if I could get Duplicati to confirm that the backup image is a valid repository.
Maybe recreating the database is what I want… It’s fine with me if the process takes a few days. If I were to run a repair on my B2 snapshot and it were to successfully create a database, would this constitute strong evidence of the integrity of the archive?
Well, recreating the database is a good indicator. It’ll definitely figure out if any part of the backup is missing.
That being said I do not think it would detect silent corruptions in archives. You could recreate a database and have single files be corrupted on restore.
Maybe a combination of recreate and test would suffice? I know some people go to the extend of actually doing restores to confirm files are restored as intended but it may be overkill for your use case.
What sort of a test are you expecting if there’s no local database against which to compare the backed up data - wouldn’t it just be a “yep, I can uncompress everything without any errors” test?
A stopgap might be to have test look at the destination data and determine the most recent version date then use that date from the local database for the testing. Of course this still won’t handle situations where retention policy may have kicked in AFTER the repository snapshot was made…
If the snapshot request to your destination is timely, you could:
make sure there’s no backup running
manually back up the sqlite file for your job (maybe a name like BLAHBLAH-bzsnapshot_2018-04-09-18-54-36.sqlite)
request the repository snapshot
When the snapshot arrives just use the backup of the sqlite file for the --dbpath parameter of your test command.
I see your point, and I like your suggestion. B2 is able to capture a snapshot within a couple hours and my backups run nightly, so I could totally just make a copy of the local database that’s in sync with the remote snapshot. And so I will!