[Solved] Btrfs rolling back root subvolume

jayflo · 2013-11-22 00:13:34

I've recently converted the partition (/dev/sda3) containing / to btrfs. In doing this, btrfs creates a default subvolume that is the top level of the filesystem which I am taking as / itself. Now, suppose I take a snapshot of this partition using

btrfs subvolume snapshot / /root_snapshot_1

So that the snapshot lies within my / directory. If i then set root_snapshot_1 as the default subvolume so that I boot into that snapshot rather than my currently active (the original default) subvolume /, what happens to all the files that lie outside of the root_snapshot_1 subvolume? (E.g. the home, usr, etc. directories) Certainly I wouldn't see the original default (/) as a directory inside root_snapshot_1?

How do I arrange my system so that I can have the current default subvolume (/, the active one) "side by side" with the snapshot (backup) subvolumes so that I can boot to anyone of them, or delete any one of them?...Rather than having them nested.

Last edited by jayflo (2013-11-23 02:38:12)

WonderWoofy · 2013-11-22 01:20:55

Just snapshot the / twice, once for whatever you are going to use and once for the snapshot backup. Then delete everything that is not a subvol inside /.

So say, as an example, you were to make / -> /snap1 & /snap2. Then you could boot one of those by using the kernel command line's rootflags option. So if snap1 were to be the primary, you would do 'rootflags=subvol=snap1' (this would actually be equal to 'rootflags=subvol=/snap1'). This will effectively hide the original / and /snap2.

Now to work on things, you probably want to mount the filesystem somewhere in with the mount option 'subvolid=0' which is a reference to the very root of the entire btrfs filesystem. I have chose to put it at /var/lib/btrfs-root and I do this because that is where I found the clean chroots are made by devtools... so these seemed like chroot'able things as well, and I couldn't think of a better place...

But wherever you put it, navigate there, and you will find you original /, /snap2, and /snap1 again. You probably want to delete everything from / except /snap1 and /snap2.

Hopefully that makes as much sense as it does in my head.

jayflo · 2013-11-22 03:44:41

Thanks for the reply woofs. Sometimes I think I have a handle on this, but then I just confuse myself again. Suppose I call my current default subvolume _original. Within _original I'll create a subvolume called _snap located at /_snap.

By setting the kernel option 'rootflags=subvol=_snap' I will boot into _snap but I will still only be able to see a standard arch directory structure, i.e. / --> /usr, /var, /home, etc... even though there is another "copy" of arch (_original) outside of _snap.

Now, you're saying to create another subvolume (now inside _snap) say _btrfs-root located at /_btrfs-root. Then if I set _btrfs-root to have subvolid=0, when I 'cd /btrfs-root' (still in _snap), the file structure will look as if I were in _original. Namely, I would see var, usr, home,..., AND _snap. I can then delete everything outside of _snap (which is more or less _original which I am not using that anymore) and can save all subsequent snapshots within /_btrfs-root (which is inside _snap). This effictively places all subsequent snapshots side by side w/ _snap.

Does that make sense? And if so, is that what you're saying? If this is the case, it is confusing because you effectively have a "higher subvolume" accessible from within one of its own subvolumes (but this would make sense why nothing is recursive when dealing with snapshots).

Last edited by jayflo (2013-11-22 03:49:31)

WonderWoofy · 2013-11-22 05:15:57

jayflo wrote:

Thanks for the reply woofs. Sometimes I think I have a handle on this, but then I just confuse myself again. Suppose I call my current default subvolume _original. Within _original I'll create a subvolume called _snap located at /_snap.
By setting the kernel option 'rootflags=subvol=_snap' I will boot into _snap but I will still only be able to see a standard arch directory structure, i.e. / --> /usr, /var, /home, etc... even though there is another "copy" of arch (_original) outside of _snap.

So far, yes that is right.

Now, you're saying to create another subvolume (now inside _snap) say _btrfs-root located at /_btrfs-root. Then if I set _btrfs-root to have subvolid=0, when I 'cd /btrfs-root' (still in _snap), the file structure will look as if I were in _original. Namely, I would see var, usr, home,..., AND _snap. I can then delete everything outside of _snap (which is more or less _original which I am not using that anymore) and can save all subsequent snapshots within /_btrfs-root (which is inside _snap). This effictively places all subsequent snapshots side by side w/ _snap.

Not quite with the btrfs-root part. What I am saying here is because you have now booted the /snap subvolume, you can now not see anything outside of that (as you mentioned above). But often times it is good to make other snapshots within that subvolid=0 (the root of the entire filesystem). So to get access to those, you have to mount it somewhere. I was just giving you reasoning for the place that I chose to do it.

Does that make sense? And if so, is that what you're saying? If this is the case, it is confusing because you effectively have a "higher subvolume" accessible from within one of its own subvolumes (but this would make sense why nothing is recursive when dealing with snapshots).

So each subvolume, no matter where it is, is its own b-tree. So it is mountable from that point. I have chosen to use btrfs somewhat like its own kind of logical volume manager, where I can use it to make a separate home, rootfs, and snapshots. By doing this, I am able to roll back quite easily.

Here is a tree-like representation of what I have going on from subvolid=0:

subvolid=0
 |- rootfs    (from here of course there is /usr, /etc, /var, /tmp, and so forth)
 |- home      (and its contents of course)
 `- snaps 
     |- rootfs@2013-10-1
     |- rootfs@2013-11-1
     |- home@2013-10-1
     `- home@2013-11-1

So my fstab would look like this:

LABEL=btrfs   /   btrfs   noatime                 0   0
LABEL=btrfs   /   btrfs   noatime,subvol=home     0   0

...and my kernel command line would be:

initrd=/boot/initramfs-linux.img root=LABEL=btrfs rw rootflags=subvol=rootfs

So if I wanted to instead boot from a previous snapshot of my rootfs, I would instead use rootflags=subvol=snaps/rootfs@2013-11-1.

Does that make more sense?

jayflo · 2013-11-23 01:59:31

Thanks so much for you patience woofs. I really appreciate your time helping me get a handle on this. I think we are nearing the end...

Ok, so suppose that with a fresh btrfs converted / partition, I do the following:

btrfs subvolume snapshot / /arch

Then set it so that I boot into this snapshot:

initrd=/boot/initramfs-linux.img root=LABEL=btrfs rw rootflags=subvol=arch

Now, I've booted into 'arch'. Next (please forgive me if the command syntax is not correct)

mount -t btrfs -o subvolid=0 /dev/sda3 /btrfs-root

Since this command is executed while I am booted into 'arch', this should create a folder '/btrfs-root' (within the 'arch' snapshot) where the root of the entire filesystem can be accessed/viewed. Suppose I

cd /btrfs-root
ls

What do I see? Is equivalent to reverting the kernel options

initrd=/boot/initramfs-linux.img root=/dev/sda3 rw

booting into the original installation, then

cd /
ls

? Whatever the answer turns out to be, for some reason it still seems weird to me that you can view the entire btrfs file system from 'inside' one of the subvolumes contained in that file system.

Last edited by jayflo (2013-11-23 02:12:50)

WonderWoofy · 2013-11-23 02:27:07

Yeah you've got it I think. If you cd into /btrfs-root, you will find the original converted filesystem and you will see /arch again as well (it would be /btrfs-root/arch in your example).

This isn't really weird at all. From any Linux installation, if your rootfs was ext4 and on /dev/sda3 (as an example), if you did:

# mount /dev/sda3 /mnt

...you would find another copy of your filesystem within /mnt.

The idea is simply to give you access to everything simply for administration purposes. You don't have to do this at all, I just find it is convenient to keep my snapshots where it does clutter other things up. I have mine with the 'x-systemd.automount,noauto' mount options, so it isn't even mounted most of the time. It will only mount on first access.

Oh, and doing the following will not create the directory, like any mount command, you will need to do this on an existing directory, as it won't be created for you.

# mount -t btrfs -o subvolid=0 /dev/sda3 /btrfs-root

(also, mount is pretty smart these days, and you don't need the '-t btrfs'.)

Last edited by WonderWoofy (2013-11-23 02:27:30)

jayflo · 2013-11-23 02:37:43

Thanks for your help woofs! You are a gentleman (or woman, but probably man...) and a scholar.

WonderWoofy · 2013-11-23 02:43:35

Hmmmm.... not a scholar, not a woman, nor a gentle-anything... I'm a man though.

GSF1200S · 2014-05-24 23:12:24

WonderWoofy wrote:

jayflo wrote:
Thanks for the reply woofs. Sometimes I think I have a handle on this, but then I just confuse myself again. Suppose I call my current default subvolume _original. Within _original I'll create a subvolume called _snap located at /_snap.
By setting the kernel option 'rootflags=subvol=_snap' I will boot into _snap but I will still only be able to see a standard arch directory structure, i.e. / --> /usr, /var, /home, etc... even though there is another "copy" of arch (_original) outside of _snap.
So far, yes that is right.
Now, you're saying to create another subvolume (now inside _snap) say _btrfs-root located at /_btrfs-root. Then if I set _btrfs-root to have subvolid=0, when I 'cd /btrfs-root' (still in _snap), the file structure will look as if I were in _original. Namely, I would see var, usr, home,..., AND _snap. I can then delete everything outside of _snap (which is more or less _original which I am not using that anymore) and can save all subsequent snapshots within /_btrfs-root (which is inside _snap). This effictively places all subsequent snapshots side by side w/ _snap.
Not quite with the btrfs-root part. What I am saying here is because you have now booted the /snap subvolume, you can now not see anything outside of that (as you mentioned above). But often times it is good to make other snapshots within that subvolid=0 (the root of the entire filesystem). So to get access to those, you have to mount it somewhere. I was just giving you reasoning for the place that I chose to do it.
Does that make sense? And if so, is that what you're saying? If this is the case, it is confusing because you effectively have a "higher subvolume" accessible from within one of its own subvolumes (but this would make sense why nothing is recursive when dealing with snapshots).
So each subvolume, no matter where it is, is its own b-tree. So it is mountable from that point. I have chosen to use btrfs somewhat like its own kind of logical volume manager, where I can use it to make a separate home, rootfs, and snapshots. By doing this, I am able to roll back quite easily.
Here is a tree-like representation of what I have going on from subvolid=0:
subvolid=0
 |- rootfs    (from here of course there is /usr, /etc, /var, /tmp, and so forth)
 |- home      (and its contents of course)
 `- snaps 
     |- rootfs@2013-10-1
     |- rootfs@2013-11-1
     |- home@2013-10-1
     `- home@2013-11-1
So my fstab would look like this:
LABEL=btrfs   /   btrfs   noatime                 0   0
LABEL=btrfs   /   btrfs   noatime,subvol=home     0   0
...and my kernel command line would be:
initrd=/boot/initramfs-linux.img root=LABEL=btrfs rw rootflags=subvol=rootfs
So if I wanted to instead boot from a previous snapshot of my rootfs, I would instead use rootflags=subvol=snaps/rootfs@2013-11-1.
Does that make more sense?

Im not sure if this is a necrobump at 6 months, but ill give it a shot rather than creating a new thread.

I had Arch's root filesystem on /dev/sda5. So, mounting /dev/sda5 to a directory would result in that directory containing /bin /boot /etc /usr etc. I decided to setup btrfs snapshots. I created a snapshot using / called "rootfs" under subvolid=0, and created another snapshot called "snapshots". I deleted all the original root directories leaving only the rootfs and snapshots subvolumes. Heres a basic tree to show my current setup:

subvolid=0
 |- rootfs    (within this subvolume is /bin, /etc, /usr, et cetera..)
 |- home    (this is actually a directory since my /home is on a different partition; ignore this for now)
 |- snapshots

It all works. I made a backup in "snapshots" called latest, and I could boot from it. Heres my questions:

1) You mention simply using a rootflags kernel line option to change to whichever snapshot. I cant do that. In my grub.cfg I need to do this:

...
linux  	/rootfs/boot/vmlinuz-linux-grsec root=UUID=69959f88-8935-48bf-8868-8a50d1d74bb1 init=/usr/lib/systemd/systemd rw  quiet rcutree.rcu_idle_gp_delay=1 rootflags=subvol=rootfs
	echo	'Loading initial ramdisk ...'
	initrd	/rootfs/boot/initramfs-linux-grsec.img
...

Notice the /rootfs on the linux and initrd lines. Makes sense.
So suppose an update or my stupidity causes my root filesystem to be screwed. If I want to boot my backup, I cannot just change my rootflags- I have to do this:

...
linux 	/snapshots/latest/boot/vmlinuz-linux-grsec root=UUID=69959f88-8935-48bf-8868-8a50d1d74bb1 init=/usr/lib/systemd/systemd rw  quiet rcutree.rcu_idle_gp_delay=1 rootflags=subvol=snapshots/latest
	echo	'Loading initial ramdisk ...'
	initrd	/snapshots/latest/boot/initramfs-linux-grsec.img
...

Am I missing something? Is there a way where I only have to change rootflags=subvol=rootfs -to- rootflags=subvol=snapshots/latest
I guess this isnt really a big deal... I think it might have to do with btrfs' make-default, but if I use that, would I even be able to use snapshots since they would essentially be hidden from grub once /dev/sda5 mounted?

2) I mount subvolid=0 at /mnt/btrfsroot. So if my rootfs snapshot was screwed and I had booted on snapshots/latest, would it be ok to essentially just delete the rootfs subvolume at that point and create a snapshot of snapshots/latest as a new rootfs? Im pretty sure this is fine, but I dont want to find out im wrong when I end up with no root

3) I see you label your backups by date which is cool. How do you remember (other than I notice you do them monthly) what to put on the linux, initrd, and rootflags line?

Anyways, thanks for the help. This thread is definitely what made all this click. I still dont understand what snapshots really are. It seems they are like inode level symlinks but most documentation on it is pretty confusing to my lowly linux self...

WonderWoofy · 2014-05-25 00:33:33

GSF1200S wrote:

...a bunch of stuff...

No, you are right that you would have to change the kernel path and initrd= as well. I didn't mention this I think probably because I use UEFI, and thus my initramfs and kernel are on the EFI System Partition. Maybe one day, there will be a bootloader that can somehow parse the rootflags option to find the right initramfs and kernel, but as of today, I don't think one exists. A while back after talking to srs5694, he seemed to suggest that rEFInd would be able to use its autoscanning of filesystems to recognize subvolumes and search for ones that contain a <subvol>/boot/* but I have never actually tested this.

GSF1200S wrote:

I still dont understand what snapshots really are. It seems they are like inode level symlinks but most documentation on it is pretty confusing to my lowly linux self...

Snapshots are actually quite simple. If you think about btrfs' structure as just a bunch of subvolumes, each one is its own btree. So in other words, each is its own hierarchical tree. Each tree obviously starts somewhere, and so each one has a single btree root. When you take a snapshot, it is simply adding a new btree root, but its second level simply points to the original subvolume's second level of the btree. So it is essentially just allowing you to access the same parts of the filesystem, but starting from a different btree root.

Now when you start writing to this new snapshot (assuming it is writable), then the changes get added underneath this new btree's structure. This keeps the original in tact. So common unchanged blocks continue to be shared between the two until a change is made.

(Hopefully that last part wasn't just entirely confusing)

GSF1200S · 2014-05-25 00:46:05

WonderWoofy wrote:

GSF1200S wrote:
...a bunch of stuff...
No, you are right that you would have to change the kernel path and initrd= as well. I didn't mention this I think probably because I use UEFI, and thus my initramfs and kernel are on the EFI System Partition. Maybe one day, there will be a bootloader that can somehow parse the rootflags option to find the right initramfs and kernel, but as of today, I don't think one exists. A while back after talking to srs5694, he seemed to suggest that rEFInd would be able to use its autoscanning of filesystems to recognize subvolumes and search for ones that contain a <subvol>/boot/* but I have never actually tested this.
GSF1200S wrote:
I still dont understand what snapshots really are. It seems they are like inode level symlinks but most documentation on it is pretty confusing to my lowly linux self...
Snapshots are actually quite simple. If you think about btrfs' structure as just a bunch of subvolumes, each one is its own btree. So in other words, each is its own hierarchical tree. Each tree obviously starts somewhere, and so each one has a single btree root. When you take a snapshot, it is simply adding a new btree root, but its second level simply points to the original subvolume's second level of the btree. So it is essentially just allowing you to access the same parts of the filesystem, but starting from a different btree root.
Now when you start writing to this new snapshot (assuming it is writable), then the changes get added underneath this new btree's structure. This keeps the original in tact. So common unchanged blocks continue to be shared between the two until a change is made.
(Hopefully that last part wasn't just entirely confusing)

That makes perfect sense.

So if you delete the original tree, then anything that the second tree was "sharing" will simply become property of that tree. When changes are made, it simply leaves the old data there and writes to a new block (unless no tree points to the old data.. etc). I think it all makes sense now. Thanks

WonderWoofy · 2014-05-25 05:07:46

GSF1200S wrote:

So if you delete the original tree, then anything that the second tree was "sharing" will simply become property of that tree. When changes are made, it simply leaves the old data there and writes to a new block (unless no tree points to the old data.. etc). I think it all makes sense now. Thanks

Yup, that sounds about right. Glad I was able to help you make sense of things.

Arch Linux

#1 2013-11-22 00:13:34

[Solved] Btrfs rolling back root subvolume

#2 2013-11-22 01:20:55

Re: [Solved] Btrfs rolling back root subvolume

#3 2013-11-22 03:44:41

Re: [Solved] Btrfs rolling back root subvolume

#4 2013-11-22 05:15:57

Re: [Solved] Btrfs rolling back root subvolume

#5 2013-11-23 01:59:31

Re: [Solved] Btrfs rolling back root subvolume

#6 2013-11-23 02:27:07

Re: [Solved] Btrfs rolling back root subvolume

#7 2013-11-23 02:37:43

Re: [Solved] Btrfs rolling back root subvolume

#8 2013-11-23 02:43:35

Re: [Solved] Btrfs rolling back root subvolume

#9 2014-05-24 23:12:24

Re: [Solved] Btrfs rolling back root subvolume

#10 2014-05-25 00:33:33

Re: [Solved] Btrfs rolling back root subvolume

#11 2014-05-25 00:46:05

Re: [Solved] Btrfs rolling back root subvolume

#12 2014-05-25 05:07:46

Re: [Solved] Btrfs rolling back root subvolume

Board footer