Howto make sure that the backups are restorable?

Getting Help
#1

Hi all,

I run a daily backup of my NAS to the Azure Storage Blobs. Usually I just run restic backup and weekly a restic forget --prune. A few days ago I had a case where a hard drive failed and I had to run a restic restore from Azure. However, the indexes were corrupt (“Invalid data returned”) and I could not run a restore. Fortunately I still had the backup on another hard drive …

How can I make sure that the backups are valid and that I can restore them? restic check takes extremely long, the upload speed is also a bottleneck.

Is it possible to log error messages somewhere?
Does it make sense to regularly run a restic rebuild-index?
Is there a possibility to do a restic restore --dry-run?

Thanks and best regards!

#2

Hi,
Someone else might have better ideas, but I wrapped the backups of my nas in a scripts which:

  • backups
  • selects 1 file from the nas
  • retores that file to a temp location
  • compares that restored file and the live one
  • and mails me the result.
1 Like
#3

In fact, the best way to check if your backups can be restored is to call restic check --read-data. This however checks the whole repository and therefore all snapshots. There is no way so far to limit check --read-data to the data needed by only one snapshot.
If you run check without --read-data it will check all the metadata (including the index) which should be really fast. With 0.12.0 extra checks were added such that this is also able to detect missing or incomplete pack files. Also prune or forget --prune from 0.12.0 catches most errors in metadata.

The other possibility is to actually do a real restore and throw it away. This only “checks” the metadata and file contents needed for that particular restore.

No. If you run prune regularly, the index will be always rebuilt after a prune run. IMO, restic rebuild-index only makes sense if your index contains entries which are in fact missing and this leads to a situation where prune or check does not work.

No, this is not implemented.

Note that there is the experimental PR

but this will not do what you intend a --dry-run should be doing!

#4

This is a pretty good idea as you should always test if restoring actually works!

If you want to randomly check parts of your backup contents, you can also use something like restic check --read-data-subset=1%…

#5

Thank you for your information! Yes, read-data takes a really long time and i will probably be able to run it monthly in the future. Currently it checks 5% ( check --read-data-subset=5%) of the data and saves the output to a log file. when restic is done, it sends a mail. then i check manually if the check has run on errors

#6

Still it would be interesting what Was the problem in your case.

#7

unfortunately, i can no longer reproduce this. i tried several snapshots to restore the backup, but all indexes were broken