Given two ZFS pools where snapshots from one are sent to the other, is it possible to automatically repair a damaged snapshot using a copy of that snapshot stored on the other pool?
I'm hoping this will only ever be a hypothetical question, but it seems worth knowing! As far as I can tell zfs scrub only works for a single pool, and only repairs if there is redundancy in that one pool; I guess what I'm looking for is some way to compare two snapshots and repair a damaged one using the other (assuming the other is intact).
For example, if I were to have a ZFS setup limited to a single disk and where space may limit the ability to use the copies option for self-healing of all data, like on a laptop. In such a case ZFS is still nice to have for its other features (native compression and encryption, corruption detection, and the speed of backups using zfs send), however, a single flipped bit could cause corruption in a file. While in such a trivial case I could just replace the one file, I'm still curious whether a snapshot could be used for a more complex case (e.g- if some piece of metadata were corrupted, or a specific file can't be identified).
Best Answer
ZFS snapshot can not be "repaired". You can re-send it, but you can not simply correct a single corrupted block if your pool has no redundancy.
For data bit-rot, one should be able to do a manual low-level overwrite of the corrupted data (ie: rewriting raw blocks to match the stored checksum), but I never tried it. Metadata bit-rot generally means something very wrong happened because, even on single-disk pools, ZFS keeps multiple copies of all metadata by default.
As a side note, such "snapshot repair" method was discussed on the project's github issue by it was never implemented as far I know.