Do I understand right:
a) The “–verify” flag puts “restore” into a “simulation” mode without any write activity to the target (defined by “-t”)
b) Compare is done “byte by byte” (file in target path vs reconstructed file from backup) - not using any “hash-shortcuts” (so uncovering even the extremely unlikely case of a collision)
c) Additional files in the target tree (whether new or not backed up) will not be reported (as only files from the snapshot are compared)
c) would mean some potential to expand the functionality
Anyway many thanks to the contributors to restic for the great work!
Hey, welcome to the forum! I’ve split this out into a new thread, since it’s not really about restic check.
That’s not quite right: --verify enables an additional check after restore has been done, which goes over all files, reads them again and verifies that the correct data is read.
No: restic will re-read the files, cut them into blocks and computes the sha256 hash of the blocks, then it compares the list of hashes obtained this way with the list of hashes the repository lists for this file. So the (extremely unlikely) event of a collision of the hash and the file size is not covered. To be honest, it would make no sense to do that in the restorer code: if a collision were to occur at backup time, the wrong data was already written to the repo. The restorer code cannot do anything here.
I’m not sure I understand the question correctly. When --verify is specified, restic goes through the list of files of the snapshot it has just restored, and checks if the files have correctly been written to disk. It does not concern itself with additional files which just happen to be nearby.
Maybe, depending on whether or not we decide it’s sensible to do that. I assume you’re talking about a kind of “dry run” mode for the restorer, which tells you what files have been modified (so they would be restored from the snapshot)?
So now I understand the --verify flag doesn’t really deliver the requested feature. Maybe I missed something on the feature request page… (“Closed” opposed to sth. like “Solved”?)
c) revealed to my “hopeful” first (wrong) understanding, indeed hoping for a “dry restore run” comparing with the status quo at the target.
To see the positive side: That way the syntax looks more self-explanatory to me.
