Last edited:
Hi all,
I’m observing a data integrity issue on my Synology NAS that I cannot fully explain and would appreciate some clarification.
For some reason, one of my video files can be downloaded in a corrupted state, even though I have btrfs-checksums enabled and data-scrubbing did even find checksum mismatsches on the same file.
This raises two questions for me:
Before replacing the failing drive 3, I triggered a manual data scrub.
It reported:
Additionally, similar checksum mismatches were reported in older snapshots:
To investigate further, I tried downloading the affected file from the NAS. To my surprise, the download completed without any errors.
In order to check the downloaded file's integrity, I retrieved the same file from two independent Hyper Backup destinations (one USB, one cloud). The retrieved files are byte-identical to each other.
The file downloaded from the NAS, however, differs in two 4 KiB blocks separated by approximately 124 KiB of identical data.
The corruption is reproducible: multiple downloads of the same file produce identical differences.
Questions:
I’m observing a data integrity issue on my Synology NAS that I cannot fully explain and would appreciate some clarification.
For some reason, one of my video files can be downloaded in a corrupted state, even though I have btrfs-checksums enabled and data-scrubbing did even find checksum mismatsches on the same file.
This raises two questions for me:
- How can corrupted data be served via normal file access even though it contains a checksum mismatch?
- Are these checksum mismatches originating from Btrfs, RAID, or another layer?
- DS423
- DSM 7.3.2-86009 Update 3
- One storage pool with SHR-1 and 4 HDDs
- One unencrypted volume taking up the whole space
- Encrypted share with "Enable data checksum for advanced data security" enabled
- Drive 3 is on the brink of failing (1 reallocated sector, 1 pending sector, extended SMART test reported an unrecoverable error).
Before replacing the failing drive 3, I triggered a manual data scrub.
It reported:
Checksum mismatch on file [/volume1/MyShare/_BeforeReencode/SomeVideoFile.avi].Additionally, similar checksum mismatches were reported in older snapshots:
Checksum mismatch on file [/volume1/@sharesnap/@MyShare@/GMT+01-2026.01.31-23.35.01/[...]/ECRYPTFS_FNEK_ENCRYPTED.FZ[...]9k--]To investigate further, I tried downloading the affected file from the NAS. To my surprise, the download completed without any errors.
In order to check the downloaded file's integrity, I retrieved the same file from two independent Hyper Backup destinations (one USB, one cloud). The retrieved files are byte-identical to each other.
The file downloaded from the NAS, however, differs in two 4 KiB blocks separated by approximately 124 KiB of identical data.
The corruption is reproducible: multiple downloads of the same file produce identical differences.
Questions:
- How is it possible that a file reported as having checksum mismatches during scrub can still be read and downloaded without any error or warning?
- Shouldn’t Btrfs (or the storage stack) prevent such reads?
This post includes affiliate links. As an Amazon Associate, SynoForum.com may earn a commission if you make a purchase — at no extra cost to you.
It helps support our community! Learn more...
