Btrfs Snapshot – Restore Single Files from a Btrfs Snapshot Without Full Copy

btrfssnapshot

Background

I maintain a series of hourly snapshots on my btrfs filesystem using btrbk. The subvolume and snapshots are stored like this (names shortened to make it easier to follow):

/@vol               (subvolume)
/btrbk/@vol.00      (snapshots of /@vol, one per hour)
/btrbk/@vol.01      ...
/home/user/vol      (mountpoint for /@vol)

Now I deleted a single file in /home/user/vol which I should not have deleted. No problem, I can easily restore from the latest snapshot:

# cd /home/user/vol
# cp -a --reflink=always /btrbk/@vol.01/all_ipv4_numbers.txt ./
cp: failed to clone './all_ipv4_numbers.txt' from '/btrbk/@vol.01/all_ipv4_numbers.txt': Invalid cross-device link

Seems I can't "reflink" the file. But I don't want to end up with two copies of the file. Ideally I want it to look like nothing happened between the most recent snapshot and the next snapshot that will be taken in the future.

^{(Yes, I also have actual backups, but restoring from snapshots are more convenient whenever available!)}

Question

How do I restore a single file from a btrfs snapshot while keeping all the nice references and magic that makes btrfs know that it is the same data in all the snapshots?

Best Answer

You can only use cp --reflink when the source and target are both on the same mount point. For this purpose, mounting the same filesystem to multiple directories doesn't count. Mount the "root" volume of the btrfs filesystem somewhere, then do cp --reflink between the snapshot subvolume and @vol that are under that directory.

Related Solutions

Linux – Restore Btrfs snapshot from subdirectory to parent

I think this is where you went wrong:

If I try to run:

btrfs subvolume snapshot /mnt/disk/root/snapshots/2015-05-01 /mnt/disk/root

It creates the new subvolume as /mnt/disk/root/2015-05-01 instead of replacing /mnt/disk/root/.

btrfs subvolume snapshot is used to create a snapshot of the first argument, and it place it in the directory given by the second argument. It sounds like you're expecting it to replace /mnt/disk/root instead.

Before you try to overwrite the /mnt/disk/root subvolume, you'll need to move or delete it (for example mv /mnt/disk/root /mnt/disk/root-backup-during-restore). Then do:

btrfs subvolume snapshot /mnt/disk/root/snapshots/2015-05-01 /mnt/disk/

And then:

mv /mnt/disk/2015-05-01 /mnt/disk/root

Btrfs – Understanding Snapshots and Space Usage

I think that most of your questions can be answered simply by remembering that in Btrfs, a snapshot is not really special, it's just a Btrfs subvolume. It just happens that when it's created, it has initial contents instead of being empty, and the storage space for those initial contents is shared with whatever subvolume the snapshot came from.

A snapshot is just like a (full) copy, except it's more economical because of the shared storage.

If I don't do snapshots, can you roll back a single file to several changes ago?

No. Just like with any regular filesystem, modifying files is destructive. You can't magically go back to an earlier version.

Can btrfs snapshots of root be used and thought of just like VMware/VirtualBox snapshots?

VM disk images are usually block devices, not filesystems or files on filesystems, so I think it's a little different.

You could use a Btrfs file as backing store for a VM virtual block device, I guess. In which case the answer to that question is yes. Except if you use the NOCOW option (which is actually recommended for disk images). Then probably not, because copy-on-write is the magic that makes snapshots work.

I label snapshot A, make changes and label it B. If I go back to snapshot A and make changes (even just by booting changing /var/log), are those changes made in a "detached" or "unlabeled" snapshot, so those changes would be invisible if going back to B?

Every subvolume (including snapshots) in Btrfs has a name, so you cannot have an "unlabeled" snapshot.

In general, any changes you make in one Btrfs subvolume (whether it was created as a snapshot or not) are absolutely not ever visible in another Btrfs subvolume. Just remember that a snapshot is just like a copy, but more economical.

When deleting a file, is there "this file is deleted" metadata written, so space is still taken by all the versions of the file?

When deleting a file, its directory entry is removed. That is a modification to the directory, and like all modifications, it will be private to the subvolume in which it occurred. Then after that, if and only if the storage space for the file is not used by any other part of the filesystem, it's freed.

Deleting a file whose storage is shared between multiple snapshots is a lot like deleting a file in any regular filesystem when it has multiple (hard) links. The storage [inode] is freed iff it is not referenced anymore.

If I build gcc from source, as an example, I think the build directory winds up being 5-8GB. If I build it periodically from source, I'm "chewing up" a bunch of hard drive space, right?

If you build gcc multiple times in multiple different directories, then yeah, it will use more and more space. If you delete copies in between builds or overwrite the same build directory each time, then, no, there's no particular reason why it would keep using more and more space.