I am curious what happens when we have a corrupted uncorrectable file in a file system with snapshots—such as BTRFS—and we try to replace the file from backup? I suspect, that the snapshots will still contain the corrupted version of the file. Is there a way to fix these errors in snapshots too?

Another related question what happens if the snapshot itself is damaged? Will we lose it?


The snapshots will still contain corrupted versions, because the idea of them is that they are Point-In-Time. At the point in time in question they happened to be corrupt.

After Googling BTRFS sbnapshots it looks like you should be able to mount the snapshots, make changes to that file on the snapshot and that will work.

If its just the file thats damaged, and you have a backup, it should not be to big a deal. If the filesystem is damaged, that could be a lot worse.

With respect of "what happens if the snapshot itself is damaged" - this should be unlikely under BTRFS, but I expect the logic would be to copy it to another block device, and then attempt recovery on that block device as if it were the original FS.

(Disclaimer - I've never used BTRFS. I'm little more then a novice when it comes to ZFS, but I've got a fairly good grasp of the concepts)


I use BTRFS. I can confirm and elaborate some of what this answer says; and I can add something more.

You can mount any snapshot. You can modify it unless it was created with 'read-only' option. Snapshot is just a subvolume, it doesn't "remember" which other subvolume it was created from. A source subvolume and its snapshot are initially equivalent. It's better to think of a newly created snapshot as a "fork" rather than a literal "snapshot", "copy", "frozen state" or any other name that suggests its inferior status with respect to the "original".

When you fork a subvolume (create a snapshot) you can think of a Point-In-Time snapshot if you choose not to modify the "copy" anymore (either by explicitly creating it as read-only subvolume or by simply doing nothing to it, leaving it alone), while the "original" is possibly still in use. I use snapshots to backup my system before 'apt-get upgrade' but I never bother to create them 'read-only'. My point is: their Point-In-Time status isn't because of some metadata on my disk but because of metadata in my head – I just refrain from modifying them.

Snapshots share (initially almost all) data blocks with the "original" subvolume. If a content of a given block makes a file corrupted then the file is corrupted in every snapshot that shares the block. Overwriting (modifying) the file in one of the subvolumes maps it to block(s) containing the new content only in the context of this subvolume; other subvolumes remain as they were.

If you happen to have a corrupted file shared between multiple subvolumes and you want to replace it from backup then you can:

  • (common method) overwrite the whole file (or unlink and create again), this will remap all its parts to other blocks;
  • (unusual method) apply binary patch to the file, this will remap some of its parts to other blocks (this is possible if the corruption is within the file, not within the filesystem, e.g. invalid but otherwise readable PDF).

Doing this independently in multiple subvolumes will cause independent remapping, it will take unused blocks multiple times instead of just once.

To avoid this and make these replaced files in multiple subvolumes share all their blocks, proceed as follows:

  1. If it's not already mounted, mount the root of BTRFS filesystem somewhere: mount -o subvol=/ …. This way all the possible subvolumes will be available under a single mountpoint.
  2. Replace the file from backup in any single subvolume.
  3. For every other subvolume where the file needs to be replaced
    1. unlink (remove) the file,
    2. then copy (cp) the already replaced file from another subvolume with --reflink=always option; it's important to do this within a single mountpoint.
  4. You can now umount the root of BTRFS filesystem.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.