Scope of `restic check`

#1

If I understand correctly, restic check verifies the internal consistency of the repository.

Is there a command that verifies that the data in the repo and the data on the disk are actually the same? If run right after a backup has finished, it should report “OK”, if the on-disk data hasn’t changed in between…

#2

No, there’s no such command, at least not yet. What’s your use case?

#3

I want this too. Basically a way of confirming that the backup is accurate and complete. How else to know that the backups are working?

#4

I perform a restore and check that the restore matches the contents on disk – for files that haven’t changed since the last backup, of course… I agree it might be nice to have this option in restic, personally…

#5

Sounds like a nice thing to have, although somewhat outside of restic’s core feature set. So while it’s nice to have I personally think it’s of somewhat low priority compared to some other features, e.g. compression. Then again, perhaps it’s a simple thing to implement.

Either way; To verify that the files in your backup match the files you backed up, you really shouldn’t trust the backup software. The only proper way to test your backups is by restoring them (and verifying the result), not by asking the software that could have failed to do its job to verify its job. This is not specific to restic, it’s the same with any other backup software.

So all in all, I support the idea in general (as a quick and dirty type of check, but not true verification), but I think there are other much more important features to implement, and even if this feature existed it’s not something I would rely on to verify my backups, so IMO it’s of limited use.

#6

This would require double the disk space (the original files, plus the restored test files), and requires an enormous amount of time and effort: restore (takes time, make sure you don’t accidentally overwrite your files!), perform binary comparison (takes time), delete the restored files (make sure you don’t accidentally delete the real files!!!).

#7

Sure. But it is the only way to verify your backups for sure. Until you have them restored and verified, you are only speculating.

1 Like
#8

Agreed (adding characters to reach the 20 character minimum).

#9

Yep, but even a feature built-in to restic would have to do something similar, unless there’s a clever way to just unpack each file at a time, or something.

#10

Hm, now that you mention it, there’s something clever restic can do: For each file both present in the repo and in the local file system, read the file and see whether it contains the same blobs as recorded in the snapshot. That’d be clever indeed. We’d need to agree upon a user interface though (and I don’t see this as a high-priority feature right now).

1 Like
#11

Not a high prio, agree, but would be useful. If nothing else, to avoid that double disk space usage when comparing backup and local file system.

And thus was born restic verify :slight_smile:

Somebody should open proper issue on Github, lest this nice idea gets lost…

#12

I’ll happily do that - after all, that’s just what I wanted to achieve :grinning:

#13

Someone suggested the word “compare” would be more suited for this action (than “verify”).

#14

Why not, the terminology is Iess important that the functionality itself.
I created https://github.com/restic/restic/issues/1280

What does `restic restore --verify` do?
#15

I think this is a good fire drill to do on a periodic basis. Pretend your house burned down and you need to restore from scratch. Oh, you have offsite backup? Cool… do you remember your restic pw? Your S3/B2 credentials, etc? So many ways this can go wrong if you’ve never attempted/verified a restore.

1 Like
split this topic #16

2 posts were split to a new topic: What does restic restore --verify do?