snapshot rollback

This is a conceptual btrfs question :-)

I have this btrfs filesystem:

root@xerus:~# mount | grep /test
/dev/sdd4 on /test type btrfs (rw,relatime,space_cache,user_subvol_rm_allowed,subvolid=5,subvol=/)

with some snapshots:

root@xerus:~# btrfs subvolume list /test
ID 736 gen 9722 top level 5 path .snapshot/2018-12-02_1215.test
ID 737 gen 9722 top level 5 path .snapshot/2018-12-02_1216.test
ID 738 gen 9722 top level 5 path .snapshot/2018-12-02_1217.test

I now want to do a rollback to .snapshot/2018-12-02_1217.test I can do it with:

mount -t btrfs -o subvol=.snapshot/2018-12-02_1217.test /dev/sdd4 /test

But (how) can I delete the original root subvol to free disk space?

Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum TIK         
Universitaet Stuttgart         E-Mail: [email protected]
Allmandring 30a                Tel:    ++49-711-68565868
70569 Stuttgart (Germany)      WWW:    http://www.tik.uni-stuttgart.de/
REF:<[email protected]>

Found:

https://btrfs.wiki.kernel.org/index.php/Manpage/btrfs-subvolume

A freshly created filesystem is also a subvolume, called top-level, internally has an id 5. This subvolume cannot be removed or replaced by another subvolume.

Ok, it seems my idea (replacing the original root subvolume with a snapshot) is not possible.

Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum TIK         
Universitaet Stuttgart         E-Mail: [email protected]
Allmandring 30a                Tel:    ++49-711-68565868
70569 Stuttgart (Germany)      WWW:    http://www.tik.uni-stuttgart.de/
REF:<[email protected]>

Disclaimer: You probably want to wait at least 24 hours before trying my directions in case anyone has am important correction to make. You should have a means of recovering in case I got it completely wrong. (ie. good backups)

It is common practice with installers now to mount your root and home on a subvolume for exactly this reason. (And you can convert your current system as well. Boot your system with a removable boot media of your choice, create a subvolume named @. Move all existing folders into this new subvolume. Edit the @/boot/grub/grub.cfg file so your Linux boot menu has the @ added to the paths of Linux root and initrd.

Ex:

linux /@/boot/vmlinuz-4.15.0-43-generic
root=UUID=78d04a41-3786-4140-aeb8-5f2f809e7ba7
initrd /@/boot/initrd.img-4.15.0-43-generic

(you can make this change directly into the grub menu at boot time instead of editing the grub.cfg file, if you prefer.)

Edit the @/etc/fstab file so that mount points to the device we are changing have the subvol=@ option.

Example:

UUID=78d04a41-3786-4140-aeb8-5f2f809e7ba7 / btrfs
noatime,nossd,subvol=@ 0 1

Reboot, and if the system successfully boots, you should run update-grub to fix up the grub.cfg file.

From a running system, if you need to see the root subvolume again, (so you can see and manipulate the @ subvol,), mount it somewhere else:

mkdir /mnt/sda1
mount /dev/sda1 /mnt/sda1

From that point forward, it's easy to rename /mnt/sda1/@ and replace it with a snapshot of your choice,. (then reboot.)

Personally, I use a slightly different strategy. My basic principle is that no btrfs filesystem should have any files or directories in its root -- only subvolumes. This makes it easier to do stuff with snapshots if I want to.

For system disks I use a variant of the "@" approach. I create two subvolumes when I create a system disk: rootfs and varfs (I separate the two because I use different btrbk and other backup configurations for / and /var). I then use btrfs subvolume set-default to set rootfs as the default mount so I don't have to tell grub, etc about the subvolume (I should mention that I put /boot in a separate partition, not using btrfs).

In /etc/fstab I mount /var with subvol=varfs. I also mount the whole filesystem (using subvolid=5) into a separate mount point (/mnt/rootdisk) so I can easily get at and manipulate all the top-level subvolumes.

Data disks are similar. I create a "home" subvolume at the top level in the data disk which gets mounted into /home. Below /home, most directories are also subvolumes (for example, one for my main account so I can backup that separately from other parts of /home). I mount the data disk itself (using subvolid=5) into a separate mount point:
/mnt/datadisk -- which I only use for doing work with messing around with the subvolume structure.

It sounds more complicated than it is, although it is not supported by any distro installers that I am aware of. And you should expect to get a few config things wrong while setting it up and will need to have an alternative boot to use to get things working (a USB disk or an older system disk). Particularly if you want to use btrfs-over-LVM-over-LUKS. And don't forget to fully update grub when you think is working and then test it again without your old/temporary boot disk in place!

Basically, I make many different subvolumes and use /mount to put them into the places they should be in the filesystem (except for / for which I use set-default). The real btrfs root directory for each filesystem is mounted (using subvolid=5) into a separate place for doing filesystem operations.

I then have a cron script which checks that every directory within the top level of each btrfs filesystem (and within /home) is a subvolume and warns me if it isn't (I use special dotfiles within the few top-level directories which I don't want to be their own subvolumes).

Contact me directly if you would find my personal "how to set up my system and root disks, for debian, using btrfs-over-lvm-over-luks" notes useful.

Graham

Near as I can tell you have to stop using whatever is using the subvolume you consider stale, so that you can umount the subvolme and then delete it. I think the more complicated rollback is for system root because that pretty much takes a reboot to clean everything up. So for example:

[chris@flap ~]$ sudo btrfs sub list -t /

ID    gen    top level    path
--    ---    ---------    ----
258    38163    5        home
274    38155    5        root
280    36478    5        images
281    12926    5        home.20190624
282    12927    5        root.20190624
283    17109    5        root.20190626
285    17573    5        root.20190626-2
286    17840    5        root.20190626-3
# mount /dev/ /mnt
# mv root rootold
# btrfs sub snap root.20190626-3 root
## reboot when I'm ready to rollback

The system does not get cranky at the rename. The mount command immediately sees the rename so 'rootold' is still mounted at / and everything works. But on reboot, I get a rollback. And I don't have to update grub stuff this way. And then at my leisure I delete the rootold subvolume.

In any case, I would not do a rollback by directly using the subvolume I want to rollback to, I would make a snapshot of it and use the snapshot. That way if I do something stupid during the rollback, I haven't messed up my only copy of that subvolume.

For /home, it's similar except I just log out instead of reboot. It's slightly annoying that I need root user enabled, because of course if I login as chris, the subvolume mounted on /home is pinned. I can't umount it now. Or alternatively a slightly more complicated setup with each user getting their own subvolume, and then I could login as some alternate admin user to do the rollback. But I'd still do it the same
way: umount /home, rename the subvolume, snapshot the snapshot I want to rollback to giving it the name that's used in fstab, and then I just 'mount /home' and continue on.

Chris Murphy