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…
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…
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.
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!!!).
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.
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).
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.