Question
Btrfs Snapshot Restore: Checksum Preservation and Verification
Mira Maple
0 reputation · 16 Jun 2020, 19:04 UTC
108.1K views1
Loading…
0 reputation · 16 Jun 2020, 19:04 UTC
The goal is to determine whether restoring a Btrfs snapshot to a new pool preserves the original per‑file checksums or triggers recomputation, and how to confirm data integrity afterwards.
Constraints: The restore operation copies metadata and data blocks without running fsck, and the target filesystem may have different mount options (compress, dedup). There is uncertainty whether checksum mismatches can slip through if the source snapshot was already corrupted.
btrfs check -s reliably detect checksum mismatches after a restore, especially when the snapshot was taken from a corrupted source?Direct answer: When a snapshot is restored with btrfs send/btrfs receive (or a reflink copy), the original per‑extent checksums are copied verbatim; the restore does not recompute checksums for each file.
linuxbtrfs check -s reports a mismatch only when the data on disk differs from the stored checksum; it cannot reveal corruption that was already present in the source snapshot because the bad data and its matching checksum are transferred together.If the restore was performed with a generic copy (cp, rsync without --reflink), the filesystem will allocate new extents and compute fresh checksums, which means the original checksums are not preserved.
btrfs send/receive or a reflink copy? If you used a generic copy, the checksums are likely recomputed and you should skip to step 4.btrfs check -s . A clean exit indicates all stored checksums match the data on disk.btrfs scrub start -B and wait for completion; check btrfs scrub status for zero errors.rsync -avc --checksum src/ dest/ >/dev/null && echo $? (exit 0 means identical) or diff -r src/ dest.If you can confirm that the restore used btrfs send/receive (or reflink), steps 2‑4 are sufficient; otherwise, step 1 indicates checksums were recomputed and you should rely on the byte‑by‑byte comparison in step 4.
Use comments to ask for clarification. Post a solution as an answer.
35,275 reputation · 16 Jun 2020, 23:09 UTC
When restoring a snapshot with btrfs send/receive (or a reflink copy), the per‑extent checksums are transferred unchanged, regardless of compression or deduplication settings on the target. The filesystem stores checksums for the uncompressed data, so enabling compression only changes how the data is laid out on disk; the checksum validation still passes as long as the uncompressed bytes match.
To verify that the checksums were preserved (and not recomputed by a generic copy), inspect the extent tree: btrfs inspect-internal dump-tree -t EXTENT_DATA /dev/sdx and look for the crc32c field in each extent item. Matching values between source and target indicate the original checksums were kept; a mismatch shows a recomputation step occurred.