Why Can a Home NAS Snapshot Preserve Data That Is Already Corrupted?

A home NAS snapshot can preserve corrupted data because its job is to retain a filesystem state, not to decide whether every file in that state is healthy. If a database, document, photo, or media file is already damaged when the snapshot is created, restoring that snapshot can reproduce the same damaged version.

The timing of the corruption matters. A snapshot may protect an earlier version from a later overwrite, but it cannot manufacture a clean version that was never captured. Copy-on-write block sharing also creates a second case: physical damage to a block may affect more than one filesystem view that still references that block.

A Snapshot Preserves a Filesystem State, Not a Known-Good Copy

A filesystem snapshot records a storage state at a particular point in time. In OpenZFS, for example, a snapshot is a read-only version of a filesystem or volume, and it initially shares data with the active dataset rather than duplicating every file. The OpenZFS snapshot documentation describes how the snapshot retains data that would otherwise remain shared until the active dataset changes.

That operation does not establish whether the stored content is semantically correct. A filesystem can preserve a structurally readable file even when an application has written invalid records, a synchronization tool has copied the wrong version, or ransomware has replaced the original bytes with encrypted content. Snapshot success therefore means that a state was retained; it does not certify that the state was good.

Corruption Present at Snapshot Time Becomes Part of the Recovery Point

Consider a scheduled snapshot created at midnight. If an application corrupts a database at 10:00 p.m., the midnight snapshot records the post-corruption filesystem state. Rolling back to that snapshot returns the database to midnight, but midnight is already too late to provide a healthy copy.

The same sequence can occur after a faulty synchronization, an incomplete import, an accidental save, or unauthorized encryption. The snapshot does not “bake in” corruption as a special property; it simply retains the version that existed at capture time. An older snapshot may still contain a usable version, but every snapshot created after the damage can contain the same logical error.

Corruption Timing Determines Whether a Snapshot Can Help

A snapshot is most useful when the unwanted logical change happens after the recovery point. If Monday’s snapshot contains a healthy file and the live file is overwritten on Tuesday, the Monday view can still expose the earlier data. If the file was already wrong on Monday, that same recovery point cannot solve the problem.

Underlying storage damage creates a different path. A snapshot may have been healthy when created, yet later become unreadable if a physical block that it still references is damaged and the filesystem cannot reconstruct a verified copy. That is why corruption timing must be considered together with block sharing and storage redundancy.

Copy-on-Write Block Sharing Can Expose One Damaged Block Across Snapshots

Copy-on-write snapshots are space-efficient because unchanged data is shared. The Btrfs storage model documentation explains that a snapshot and its source subvolume share their common, unmodified data. A snapshot is therefore a historical filesystem view, not automatically a second physical copy on separate media.

When the live file is modified normally, copy-on-write allocates new storage for the change while the snapshot continues to reference the earlier blocks. This separation is what makes rollback possible. However, if an unchanged block is still shared and that stored block later becomes unreadable or returns incorrect data, all views that depend on it may encounter the same failure.

Checksums and redundant storage can change the outcome by detecting the mismatch and supplying another copy, but the snapshot itself does not create that protection. Copy-on-write provides version separation; it does not create an independent hardware failure domain.

Checksums and Scrubs Test Integrity; Snapshots Do Not

Snapshots, checksums, and scrubs belong to different parts of the protection stack. A snapshot preserves history, a checksum helps determine whether stored bytes changed unexpectedly, and a scrub proactively reads stored data to look for errors. Treating these features as interchangeable leads to false confidence about what a recovery point can prove.

Checksums Can Detect Unexpected Block Changes

The Btrfs checksumming documentation states that checksums are calculated before writes and verified after blocks are read from storage. A mismatch can reveal that the retrieved block is not the same as the block the filesystem expected to store.

A matching checksum does not prove that a document, database, or media file is logically correct. If an application writes bad data through the normal write path, the filesystem can calculate a valid checksum for those bad bytes. The block is intact from the filesystem’s perspective even though the application-level content is unusable.

Redundancy Determines Whether a Scrub Can Repair the Damage

A scrub can detect checksum errors, read errors, and certain metadata problems, but detection is not the same as repair. The Btrfs scrub documentation explains that automatic repair on replicated storage uses verified good data from another replica. Without a valid alternate copy, the filesystem may identify the damaged block without being able to reconstruct it.

A USENIX study of ZFS data integrity similarly separates checksum-based detection from recovery using redundancy. The practical lesson is narrower than “scrubs fix corruption”: a scrub can repair only the failures for which the storage system can locate or reconstruct trustworthy replacement data.

Snapshot Retention Helps Only If a Healthy State Still Exists

Corruption is not always noticed immediately. A rarely opened photo, archive, or project file may remain damaged for weeks before someone tries to use it. If snapshot rotation has already removed every version from before the damage, a deep collection of recent snapshots can still contain no healthy recovery point.

Retention should therefore reflect the likely detection window, not just how frequently snapshots are created. Hourly snapshots provide fine-grained recent history, while longer-lived daily, weekly, or monthly points extend the period in which an unnoticed error can be escaped. There is no universal schedule: the useful interval depends on change rate, available capacity, and how quickly important files are normally checked.

Verify a Snapshot Before Replacing Live NAS Data

Choosing a snapshot by date is only the first step. Before rolling back an entire dataset or replacing the live file, restore a candidate version to a separate location when the home NAS platform permits it. This prevents an unverified recovery attempt from overwriting newer data that may still be useful.

1. Estimate when the corruption first appeared.
2. Select a snapshot from before that time.
3. Restore the candidate into an alternate folder or clone.
4. Open, validate, or compare the recovered content before replacing live data.

Validation should match the data type. A known checksum can verify an unchanged archive, while a database may require its own consistency check and a photo or video may need to be decoded. For the broader relationship among recovery points, independent copies, and off-device protection, see this home NAS backup strategy.

FAQ

Can a Snapshot Taken Before Corruption Still Become Unreadable?

Yes. A snapshot protects an earlier logical state from later file changes, but it may still share the same storage pool and physical blocks. If one of those blocks is damaged and no verified redundant copy is available, the earlier snapshot can become unreadable even though it predates the logical corruption being investigated.

Does a Successful Snapshot Mean Every File Inside It Is Healthy?

No. A successful snapshot indicates that the filesystem created the recovery point. It does not mean that every file was opened, decoded, checked against a trusted version, or validated by the application that created it.

Can a Data Scrub Repair Corruption Written by an Application?

Usually not when the application wrote the incorrect content normally. In that case, the filesystem may store the bad bytes with a valid checksum, leaving no block-level mismatch for the scrub to detect. Recovery requires an earlier healthy version, an application-aware repair process, or an independent copy.

Does Replacing a Corrupted Live File Repair Older Snapshots?

No. Replacing the live file writes or references healthy data for the active dataset, but older snapshots continue to represent their historical states. A snapshot that retained the corrupted version normally remains corrupted until it expires or is deleted.