Rollback Btrfs root snapshot

Hello,

I am playing with btrfs and especially its snapshot capability for my root (/) volume.

I have created one volume with one subvolume mounted at /.

I have created a snapshot with:

[root@k1 ~]# btrfs subvolume list /
ID 256 gen 2302 top level 5 path root
ID 259 gen 1703 top level 256 path var/lib/portables
ID 272 gen 2289 top level 256 path .snapshots/root/20201223

(by the way if someone know what is the purpose oif var/lib/portables and if there is a way to disable it)

I have set the default subvolume to be my snapshot:

[root@k1 ~]# btrfs subvolume get-default /
ID 272 gen 2289 top level 256 path root/.snapshots/root/20201224

After a reboot it seems my change has not been taken in consideration (original subvolume is being mounted):

[root@k1 ~]# btrfs subvolume get-default /
ID 272 gen 2289 top level 256 path root/.snapshots/root/20201223

I have tried to re-generate my GRUB config with grub2-mkconfig but it doesn’t change anything.

The subvol option is not set in hte grub config, so it should be the default one.

Any ideas?

(PS: I know I should have put /boot into a subvolume to be consistent in case of kernel update, this is just for learning purpose)

Thanks in advance.

Regards,

Jérémy

2 Likes

To permanently change your root sub volume etc/fstab has to be adjusted accordingly.

To ease your efforts you may consider using snapper which provides a convenient high-level way of managing snapshots.

If you are using snapper

Snapper assumes complete control over what is the active root, via btrfs subvolume set-default.

You will need to remove the subvol=root option from fstab. And also modify /etc/default/grub adding the line:
SUSE_BTRFS_SNAPSHOT_BOOTING=true

And then run grub2-mkconfig -o /boot/... filling out the rest of the path based on the location to grub.cfg for your firmware type.

Hmmm, when I do this, it does work but there’s an unwanted $(extra_cmdline) item at the end of the boot parameters. I’m not sure where it’s coming from.

/etc/grub.d/00_header:383:if [ -n "\$extra_cmdline" ]; then
/etc/grub.d/10_linux:70:	GRUB_CMDLINE_LINUX="${GRUB_CMDLINE_LINUX} \${extra_cmdline}"
/etc/grub.d/20_linux_xen:77:	GRUB_CMDLINE_LINUX="${GRUB_CMDLINE_LINUX} \${extra_cmdline}"

OK it’s related to finding read-only snapshots. I think. None of that is wired up with BootLoaderSpec stuff yet. Also, while booting read-only snapshots works up to a point, because /etc and /var are in the read-only root subvolume snapshot, they’re read-only too which will cause startup to fail.

So doing a rollback on boot is not exactly ready, you’re pretty much in adventure land if you’re playing with this (which is why none of it’s installed or enabled by default yet).

If you can boot, snapper rollback should work since it’ll just change the default subvolume.

If you aren’t using snapper

I’ll describe what I do since I’m also not using snapper. I assume that you haven’t modified fstab or any of the grub stuff and that you haven’t changed the default subvolume.

Mount the top level of the file system, make a read-only snap shot

mount /dev/sdXY /mnt
cd /mnt
btrfs sub snap -r root root.20201224

I make read-only snapshots out of habit, mostly. Ok let’s say I mess up something and want to do a rollback.

mount /dev/sdXY /mnt
cd /mnt
mv root rootmessedup
btrfs sub snap root.20201224 root
reboot

In this case I’m renaming the current root subvolume to something descriptive. Renaming it while it’s in use is not a problem (I do it all the time; and behind the scenes, btrfs tracks subvolumes by ID not name). Next I make a read-write snapshot of the snapshot I want to rollback to. And then reboot.

An optimization probably is to remove subvol=root from fstab, that way you could instead directly choose to rollback to read-write snapshots from within GRUB if you know the name. Just change rootflags=subvol=root to rootflags=subvol=root.20201224. Of course, you’d need to be making read-write snapshots in this case.

The reason I prefer snapshots “hidden” away in the normally not mounted top-level, is so they don’t clutter up other commands like find, du, backup programs, and so on. Also there is a (perhaps small) security concern with keeping stale binaries in a readily available search path, even if it is a hidden .directory. So I just prefer to keep them totally out of site.

3 Likes

I’d prefer that either and already do that for my /home file system which is backed up with btrbk. But I think snapper can’t handle this, does ist?

Not yet.

1 Like

Thank you very much for your explanation. Following your instructions i am now able to “rollback”.

The only part I don’t fully understand is:

Since the default subolume is “root”, the top level (subvolid 5) of the filesystem should not be mounted here, or I am missing something?

I had to force the top level manually:

mount -t btrfs subvolid=5 /dev/sdaXY /mnt/tmp

If you aren’t using snapper

I assume that … you haven’t changed the default subvolume.

The mkfs time default subvolume is ID 5 at the top level of the file system. Fedora’s installer doesn’t change this.

Also, I actually tested fstab conflicts after writing the earlier comment …

The fstab / entry’s use of subvol=root is superfluous and ignored. The equivalent CLI command is mount -o remount,subvol=root and it would be wrong behavior if this command could switch subvolumes on a remount. i.e. the default subvolume or rootflags defined. I’ve applied strike though to the earlier suggestion.

The default subvolume is used only when a btrfs filesystem is mounted without subvol or subvolid options supplied.

For example, when /dev/sda3 is a btrfs,
mount /dev/sda3 /mnt, then the default subvolume will be mounted to /mnt

when subvol or subvolid is used, the default subvolume has no effect the the mount, like
mount -o subvol=rootfs /dev/sda3 /mnt
mount -o subvolid=277 /dev/sda3 /mnt

So for a rootfs roll back, you need to adjust so that the kernel root parameter (as specified in the bootloader), the fstab entry (as in /etc/boot/fstab) and the filesystem all need to match.

If your fstab/kernel cmdline use /dev/sda3, or part-UUID without subvol or subvolid options, then you need to change the default subvolume option in btrfs.

Or you need to change kernel parameter and fstab to match your desired root in the btrfs.