Recommendations for testing full restore?

Getting Help
1

I’ve been using restic for a while under Linux to backup to Backblaze B2 and it’s been great. My scripts already do a check after every backup. I’ve done spot checks to see if files seem to be backed up, but I haven’t tested a full restore yet. Even though I trust restic and check, it seems like it would be a good idea to test a full restore.

Does anyone have any suggestions or scripts to test a full restore? Do you just restore to a temp directory and walk the directories you back up and do a diff of some sort? I do have enough room on my drive to do a full restore to a temp directory on that drive, but is there a way to test a restore without doing that?

Thanks.

2

If you don’t use Windows you can run restic mount, then compare your source data with the mounted data. I believe this is as close you can come to restore without actually restoring to disk.

The comparison can be done directly using a suitable diff tool, or indirectly by means of comparing lists of e.g. md5sum hashes.

3

Apart from mounting, there is another way to do a full restore without actually using up disk space.

You can export the snapshot (or a subdirectory of it) as a tar stream, and you can pipe that to tar and use tar to do the diff.

4

If you want to test a full restore, I recommend you use the same command you would use to do the actual full restore. Else you test another functionality than the one you intend to use :wink:

About alternatives for restore: The restore command is the most optimized one and especially is able to minimize traffic from the backend which all other alternatives (mount or dump) are not able to. So, to do a real restore, restore is the recommended command to use.

4 Likes
5

The way I test (small home user, not a business) is to go "I’m going to pretend my mailserver crashed and my wife urgently needs an email from 2 years ago” and to test I can restore it.

Until I can read the email on my screen, I don’t consider the test passed.

2 Likes
6

My constraint on restore test is disk space, not network/traffic.

And since restore test is much more frequent, I’d rather test with dump.

And if I think ‘restore’ will behave differently than ‘dump’, then I’ll just use dump to restore when an actual disaster happens.

bottom line: I optimise for the part that happens more often, in a way that I can background it and look at the result later, knowing that nothing is happening to my disk space during this operation.

7

This is called DR test (Disaster Recovery exercise)
A proper way to do that is:

  1. Create a test plan
  2. Find a free weekend
  3. Run the test
  4. Analyze test results

I do that once in a while on my personal computers. The last time (it was over 2 years ago), the test was as follows:

  1. Turn off your laptop (pretend it is dead)
  2. Take a new laptop
  3. Run the recovery tasks
  4. Try using it to see what is broken