BTRFS rollback - Current State / Possible Solutions?

spurious_access · 2013-08-12 17:32:54

Wasn't sure if this was the correct section to post this in since it's not exactly regarding a fresh installation. Let me know if it would go better elsewhere!

I'm trying to figure out what the current state of "rollback" support is in regards to BTRFS snapshots. I know that previously there were some hangups because of the bootloaders not being able to boot from a subvolume, but using GRUB2 even if I have everything in a BTRFS subvolume (__active in an attempt to get the mkinitcpio hook to work) I can boot up just fine, and there have been other posts indicating that this is no longer an issue (is it only not an issue with GRUB2?).
I haven't been able to actually get it to work, but my understanding is that mkinitcpio-btrfs package is intended to give options in the bootloader or during boot to boot from different BTRFS snapshots. This would be very convenient to be able to do. However, after playing around with it and trying some things from the comments I have been unable to get that to work with GRUB2 (and it hasn't been updated for over a year so I guess I shouldn't count on GRUB2 support being forthcoming).

The behavior that I'd like to achieve is the ability to boot into a BTRFS snapshot of my root in the case that I completely kill my current arch install, and be able to do this without booting into a different OS or live image.

One solution I've been thinking about is just writing a bash script to take the snapshots and rename them to rotate them in and out of "rollback". What I mean by this is to have the most recent snapshot always named "rollback_1", the second named "rollback_2" etc. and have preconfigured grub entries to point to those subvolume names and pass in the appropriate rootflags. Would this work? The only issue I see is the fstab entry for root would be incorrect, but I don't know how that is handled when you pass "root" as a kernel parameter. From what I've read it seems that the fstab entry is ignored, but I'm not sure if that's right.
Along similar lines, another option would be to write a script or program that would generate a grub configuration that would include dated snapshots, and run this every time you took a new snapshot.
Given these two solutions, the former would certainly be easier. Of course I'd prefer to just use an existing solution if I can!

So overall, questions are:
-Are full rollbacks (including kernel) supported as of GRUB2? Am I missing something?
-Does anyone have experience getting mkinitcpio-btrfs to work with GRUB2? Does this offer more/better functionality than just having appropriate grub entries?
-Any problems using a static grub configuration to boot into snapshots and renaming the snapshots every time I do a back up?
-What is the relationship between the "root" kernel parameter and fstab?

cngn · 2013-08-13 08:14:42

Have you tried it? Hit 'e' while in grub and edit the paths (AFAIK two) to the new subvolume.

Last edited by cngn (2013-08-13 08:20:30)

spurious_access · 2013-08-13 16:51:45

I know that I can boot into a subvolume by changing the parameters in GRUB, that's why I one solution I mentioned was to have static grub entries and then just keep renaming the snapshots. However if I do this, the fstab is conflicting with what is actually the current root. I guess part of my problem here is I don't understand what the point is of even listing the root directory in fstab if it doesn't matter.

Last edited by spurious_access (2013-08-13 16:52:10)

WonderWoofy · 2013-08-13 19:51:03

Honestly, I think that the mkiniptcio-btrfs package is worthless. It is easy enough to simply keep your root filesystem (including your /boot and /var) on the same subvol, and then specifying this from the kernel command line.

So for example, I have my system set up like this:

/ (subvolid=0)
|-rootfs
|-home
`-snaps
   |-rootfs@date1
   |-rootfs@date2
   `-rootfs@date3

So I set up my fstab so that it looks something like this:

$ cat /etc/fstab
/dev/disk/by-label/my-btrfs  /  btrfs  noatime,autodefrag,compress=lzo  0  0
<snip>

So that I can have my kernel command line include rootflags=subvol=rootfs. Then in the event that I want to "rollback" my system, I can simply edit the kernel command line before booting and specify rootflags=subvol=snaps/rootfs@date1.

Done. No need for some silly initramfs hook, no nothing. Just btrfs using teh native functionality that it provides.

spurious_access · 2013-08-13 21:09:51

@WonderWoofy
Thanks for that, that's about what I am leaning toward. I had /var on a separate subvol, but I think I'll move it back to my main one since it's going to get screwy if I try to do rollbacks by specifying everything in the kernel command line.
One thing I would like to do that I mentioned would be to just have grub entries for the snapshots rather than have to edit the command line every time. This would have a few advantages, including if I don't have it set up in such a way that I'm taking snapshots on completely regular/predictable intervals, as well as simple convenience.
I'm thinking the best way to achieve this would be a script in /etc/grub.d to automatically generate menu entries to boot into the most recent snapshots, then just regenerate my grub config every time I take a snapshot of root. I'm not too experienced in shell scripting though so I haven't quite figured out how to do this yet.

WonderWoofy · 2013-08-13 21:31:34

How about instead just set yourself a limit to the last x snapshots. Then give them predicable consistent names. For example, the most recent can be rootfs@last1, then before you take a new snapshot, move that to rootfs@last2, then make a new rootfs@last1. Then before the next snapshot move them to rootfs@last3 and rootfs@last2 to make a new rootfs@last1. That way you can have persistent grub entries (or any bootloader for that mattter) that won't have to rely on grub2's sometimes inconsistent config generation scripts.

Personally I like to date my snapshots, just so that I can know exactly when they were from. But to me it isn't hard to press 'e' before I boot and change the rootflags. In fact, for this reason, I keep the rootflags=subvol=rootfs as the first kernel command line argument. The boot manager I use (gummiboot) puts the cursor at the beginning of the line, so doing it this way ensures that I don't have to hit the arrow key too many times.

FWIW, when I first started using btrfs I had /var on a separate subvol. After a while I realized how much of a PITA it would be if I had to actually roll back at all. So I integrated it back into the rootfs. I think this is a much better setup for a home user like myself.

You have to consider this... how often do you think you'll actually boot into and old subvol/snapshot? I don't think that this is a very common necessity. It certainly should not be frequent enough for you to want to have grub autodetect every possibly snapshot you have as being a root filesystem. It may be nice to have old versions of files and whatnot, but you should only be booting into a snapshot if you experience breakage. If you are booting into the snapshots all the time... then you're likely having/creating issues for yourself that should be looked into and solved instead.

spurious_access · 2013-08-13 22:21:36

I'd probably still only list the last 10 snapshots or so no matter how I end up doing it. If I were going to do it with a static grub config, I'd still name the snapshots with the date they were taken but create symlinks to them named last1, last2 etc. and have GRUB point to the symlinks. (Or at least I think GRUB can do symlinks...) Then when I take a new snapshot, recreate the symlinks to point to the appropriate snapshots.
The only difference in outcome between having a static grub config and a generated one would be that the generated one could include the date/name of the snapshot in the grub entry, whereas with the static one it would just show "last1, last2, etc". Regenerating the GRUB config and including the times of the snapshots in the menu seemed a bit "cleaner" than renaming files or creating symlinks all the time. I'll probably play around with it a bit to see what I can get to work.

WonderWoofy · 2013-08-13 22:48:28

I don't think that symlinks would work in this case. You have to remember that you are mounting an individual b-tree here, so if you use a symlink, you are essentially asking it to mount one btree's symlink that points to a whole new btree... which doesn't make sense. Subvols work as directories in their own right, but the way they are laid out within the filesystem is not like that of a normal filesystem like ext4.

I think if you are going to do dates, then you should do two snapshots per snapshot creation. You make one that is a dated (optionally read-only) snapshot, then take a snapshot of that snapshot as the bootable subvol. This is actually quite similar to having a symlink because it is just a new btree root pointing to the same extents. So it won't be taking up any more filesystem space. If you do one read-only, then you will also have the ability to use it with btrfs send/receive, which is a pretty awesome feature.

I guess though that you could do it the other way around. You could have a common naming scheme that is included in the bootloader config. Then symlink to that particular snapshot with a dated name. But then you run into the issue of the dates getting potentially wonky when your snapshots rotate. Also, if you can't mount the thing, I really don't know what it would be worth.

spurious_access · 2013-08-14 00:49:05

Admittedly, when I suggested that I was only guessing. However, I just tried it and symlinks work just fine, both for specifying the location for the kernel and specifying the subvolume in the kernel parameter. It appears you can use a symlink to a subvolume just like you would a subvolume itself.
To test I created a snapshot: btrfs_root/__snapshots/test1
as well as a link to that snapshot: btrfs_root/test1_ln

So here are the relevant lines from my grub config that I tested with:

set root='hd2'
linux /test1_ln/boot/vmlinuz-linux-ck root=UUID=1d547c9b-25a3-45d6-a530-058aba54be5d rw rootflags=subvol=test1_ln
initrd /test1_ln/boot/initramfs-linux-ck.img

It boots up just fine with this config, and I am able to confirm that it is using the test1 subvolume as intended. So this means I could easily have symlinks in the btrfs filesystem root pointing to snapshots in a snapshot folder. That said, I like the send/receive feature as well so I may just take 2 snapshots every time anyway so that I have a RO copy as well.

WonderWoofy · 2013-08-14 02:25:33

Neato! I also just guessed that symlinks wouldn't work... that is pretty awesome. Thanks for working that out.

spurious_access · 2013-08-14 09:54:32

Alright, just for the record here's what I have so far. This is the solution of a dynamically created grub config. Placed it in /etc/grub.d/, it creates a grub submenu that contains all the snapshots in the snapshot folder. It is a bit hacked together but it appears to work. I may play around with it to see if I can cut out some of the stuff that grub puts in that seems unnecessary and maybe generalize the config a bit .

#! /bin/sh
set -e

btrfs_root="/mnt/btrfs_root/"
snap_dir="__snapshot/"

echo "submenu 'Arch Linux-CK Snapshots' {"

for item in $(ls "$btrfs_root$snap_dir" | sort -r)
do
        echo "menuentry 'Arch Linux-CK Snapshot "$item"' --class arch --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-ck kernel-true-1d547c9b-25a3-45d6-a530-058aba54be5d' {" | sed "s/^/$submenu_indentation/"
        echo "    load_video" | sed "s/^/$submenu_indentation/"
        echo "    set gfxpayload=keep" | sed "s/^/$submenu_indentation/"
        echo "    insmod gzio" | sed "s/^/$submenu_indentation/"
        echo "    insmod btrfs" | sed "s/^/$submenu_indentation/"
        echo "    set root='hd2'" | sed "s/^/$submenu_indentation/"
        echo "    if [ x$feature_platform_search_hint = xy ]; then" | sed "s/^/$submenu_indentation/"
        echo "        search --no-floppy --fs-uuid --set=root --hint-bios=hd2 --hint-efi=hd2 --hint-baremetal=ahci2  1d547c9b-25a3-45d6-a530-058aba54be5d" | sed "s/^/$submenu_indentation/"
        echo "    else" | sed "s/^/$submenu_indentation/"
        echo "        search --no-floppy --fs-uuid --set=root 1d547c9b-25a3-45d6-a530-058aba54be5d" | sed "s/^/$submenu_indentation/"
        echo "    fi" | sed "s/^/$submenu_indentation/"
        echo "    echo    'Loading Linux ck kernel ...'" | sed "s/^/$submenu_indentation/"
        echo "    linux   /$snap_dir$item/boot/vmlinuz-linux-ck root=UUID=1d547c9b-25a3-45d6-a530-058aba54be5d rw rootflags=subvol=/$snap_dir$item" | sed "s/^/$submenu_indentation/"
        echo "    echo    'Loading initial ramdisk ...'" | sed "s/^/$submenu_indentation/"
        echo "    initrd  /$snap_dir$item/boot/initramfs-linux-ck.img" | sed "s/^/$submenu_indentation/"
        echo "}"
        echo ""
        echo ""
done
echo "}"

Arch Linux

#1 2013-08-12 17:32:54

BTRFS rollback - Current State / Possible Solutions?

#2 2013-08-13 08:14:42

Re: BTRFS rollback - Current State / Possible Solutions?

#3 2013-08-13 16:51:45

Re: BTRFS rollback - Current State / Possible Solutions?

#4 2013-08-13 19:51:03

Re: BTRFS rollback - Current State / Possible Solutions?

#5 2013-08-13 21:09:51

Re: BTRFS rollback - Current State / Possible Solutions?

#6 2013-08-13 21:31:34

Re: BTRFS rollback - Current State / Possible Solutions?

#7 2013-08-13 22:21:36

Re: BTRFS rollback - Current State / Possible Solutions?

#8 2013-08-13 22:48:28

Re: BTRFS rollback - Current State / Possible Solutions?

#9 2013-08-14 00:49:05

Re: BTRFS rollback - Current State / Possible Solutions?

#10 2013-08-14 02:25:33

Re: BTRFS rollback - Current State / Possible Solutions?

#11 2013-08-14 09:54:32

Re: BTRFS rollback - Current State / Possible Solutions?

Board footer