Restore generated corrupted files

[enboig]

After more debugging on #1585 I discovered that:

1. I created a ZFS raidZ filesystem with a "bad shape" disk (smartmon reporting errors).
2. I restored a snapshot.
3. Changed broken disk
4. I discoverd some files from restore where broken.

I assumed raidZ should have protected me from failing this, don't know why "corrupted restoration" happened.

After some working, and checking a "broken file":

1. Restored it on another computer, file was OK; so corruption wasn't on snapshot.
2. Restored it over previous file, file continued corrupted.
3. Deleted file.
4. Restored it it, file was OK

Checksums where diffenet between 1 and 2, but equal between 1 and 4.

Shouldn't restore check file checksum to ensure file has to be restored?

[aawsome]

@enboig The default behavior of restore is to only restore files which either do not exist or if the metadata (modification time and file size) differs between the on-disc and the on-snapshot file.
In your case of corrupted files, I think that the metadata of the file was not changed and hence nothing was restored at all.

This default is chosen to speed-up restores (especially in the case where the on-disc state is similar to the on-snapshot-state, e.g. restoring to an older version of a directory tree)

There is however the option

 --verify-existing  Always read and verify existing files (don't trust correct modification time and file size)

[enboig]

I am restoring from hetzner. I recall some errors and retries happened when restoring. Hetzner uses SFTP and has a 10 connection limit, so if some backup job happens when restoring, it could hit the limit easily.

Could it be that some errors ended creating holes in files when restoring, and successive restores didn't complete empty holes I didn't use --verify-existing?