What does `restic restore --verify` do?

[fd0]

Hey, welcome to the forum! I’ve split this out into a new thread, since it’s not really about restic check.

@Sina

a) The “–verify” flag puts “restore” into a “simulation” mode without any write activity to the target (defined by “-t”)

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.

@Sina

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)

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.

@Sina

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)

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.

@Sina

c) would mean some potential to expand the functionality

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)?