Search btrfs on this forum and my name will come up - a lot! Here's my latest entry into the btrfs catalog of tools;
Defensive upgrading using btrfs subvolume snapshots
As I have noted before: I usually don't upgrade, rather, I do a full install of the new version of Kubuntu in parallel (along side) my current install. In my view, this prevents me from leaving my computer un-bootable in case of a total failure of the upgrade and it ensures I don't drag some old edits or settings along that are improper for the newest version. I have also often complained about the continual failure of Ubiquity (our installer) in many situations. Often, on my older desktop (circa 2006) and complicated setup (4 hard drives and an SSD) Ubiquity just can't get the job done.
Enter btrfs and subvolume snapshots:
I am currently running 13.04 from a 212GB btrfs filesystem. The same filesystem also holds my older 12.10 install, a Neptune 3.1 install, a dedicated install to manage grub for me, and two homes - one for 12.10 and another for 13.04. These "separate" locations are not partitions, rather they are subvolumes. I will be speaking about subvolumes throughout this text and may leave off the word subvolume in most instances for brevity, so don't let that confuse you.
Here's my current subvolume list:
I have played a bit with snapshots in the past, but not used them to their full extent. Snapshots are like frozen moments in time for a filesystem. Snapshots are not backups in the true sense of the word: if a file that exists in the source filesystem gets corrupted or damaged, it will also be corrupted or damaged in the snapshot. A btrfs snapshot begins life with no data of it's own - it not a duplicate of the source. However, as you amend your filesystem (add, amend and subtract files) the snapshot grows. Each deleted file is not actually deleted, rather it's location pointer is removed from the source subvolume but left in the snapshot. So deleting a file doesn't actually delete it at all - it's just changes from the source subvolume to the target (snapshot) subvolume. Eventually, if you changed or deleted every file in a subvolume, the snapshot would grow to the size of the original source subvolume.
What's the point of this?
Well, you can use this in several ways. The most common way might be to "rollback." Say you want to try out a new program that requires many new libraries and compiling, but you aren't sure it's going to be safe. So you make a snapshot before installing it. Then, after installing and testing you decide it's OK: Simply delete the snapshot. If it's not OK: Delete the source, rename the snapshot to the sources name, reboot, and you're right back where you began. Also it's great for protection from oneself. You could have a cron job that makes a daily snapshot of your home and deletes snapshots more than a week old. Then you'd have a whole week to go back and recover a file you may have deleted and changed your mind about. Neat!
Enter the impending death of support for my current install!
OK, so the above title is a little over-dramatic. Support for 13.04 ends soon so I must upgrade or face the end of updates and the like. No time to do it like the present. Upgrading, rather than my usual new install, also avoids the potential Ubiquity messes. The only question is do I trust the upgrade? No need to worry: Let the snapshotting begin! PLEASE NOTE: btrfs commands, like any filesystem command, require root privileges. Rather than typing "sudo" a ba-zillion times, I opted to use "sudo -i" so I could just be root for awhile.
First, I make snapshots of my home and root directories. The btrfs filesystem I'm working on is on /dev/sda2. The "Top Level" holds all the subvolumes in the filesystem. To make things a bit easier, I mounted the "Top Level" to /mnt/sda and cd'd into it to do the snapshotting. I want the snapshots to have useful names, so I added the date and time to the name of the original subvolume in this format: yymmddhhmmss. Today is Jan. 20th, 2014 and it's 10:56 am.
and now my list of subvolumes looks like this:
A check of total space used confims very little additional space was used when creating the snapshots:
Before snapshots:
After snapshots:
and to verify my version:
Now, on to the upgrade!
added at 4:58 pm
UPGRADE UP AND RUNNING.
I'm going to test 13.10 for awhile before I commit. The next step in this adventure will be booting back into 12.10 using only the snapshot. Here's the new df report:
So you can see about 7GB has been added by the release-upgrade. Obviously, the subvolume is still named 13_04 but my OCD can put up with that for a bit longer.
OK - A few days later...
01/23 at 4:50pm
The version upgrade has gone well.
I've run several updates and installed a couple things so my drive space now looks like:
Time to test, so this afternoon I added the snapshot to my grub menu and booted to it.
It booted up fine without problems! The only thing I noticed immediately was it did not load the nvidia driver. It didn't take me long to surmise that when I did the update, the process removed the nvidia driver from the kernel in use and does not install dkms or the driver during the upgrade. When the upgrade was finished, it left me the old 3.8 kernel from 13.04 and the new 3.11 kernel from 13.10. Apparently, the snapshot function does not protect the presence of the nvidia taint in the kernel within the snapshot. This is not a deal breaker, but it is worth noting. I've kept the snapshot for now for further testing. I may attempt re-installing the nvidia driver from within the snapshot just to see if anything breaks.
Defensive upgrading using btrfs subvolume snapshots
As I have noted before: I usually don't upgrade, rather, I do a full install of the new version of Kubuntu in parallel (along side) my current install. In my view, this prevents me from leaving my computer un-bootable in case of a total failure of the upgrade and it ensures I don't drag some old edits or settings along that are improper for the newest version. I have also often complained about the continual failure of Ubiquity (our installer) in many situations. Often, on my older desktop (circa 2006) and complicated setup (4 hard drives and an SSD) Ubiquity just can't get the job done.
Enter btrfs and subvolume snapshots:
I am currently running 13.04 from a 212GB btrfs filesystem. The same filesystem also holds my older 12.10 install, a Neptune 3.1 install, a dedicated install to manage grub for me, and two homes - one for 12.10 and another for 13.04. These "separate" locations are not partitions, rather they are subvolumes. I will be speaking about subvolumes throughout this text and may leave off the word subvolume in most instances for brevity, so don't let that confuse you.
Here's my current subvolume list:
Code:
root@office:/mnt/sda# btrfs subvolume list /mnt/sda ID 258 gen 654214 top level 5 path @grub ID 261 gen 658686 top level 5 path @Kubuntu_12_10_home ID 262 gen 640640 top level 5 path @Kubuntu_12_10 ID 306 gen 658923 top level 5 path @Kubuntu_13_04 ID 307 gen 658923 top level 5 path @Kubuntu_13_04_home ID 400 gen 640465 top level 5 path @Neptune_31_home ID 401 gen 640465 top level 5 path @Neptune_31
What's the point of this?
Well, you can use this in several ways. The most common way might be to "rollback." Say you want to try out a new program that requires many new libraries and compiling, but you aren't sure it's going to be safe. So you make a snapshot before installing it. Then, after installing and testing you decide it's OK: Simply delete the snapshot. If it's not OK: Delete the source, rename the snapshot to the sources name, reboot, and you're right back where you began. Also it's great for protection from oneself. You could have a cron job that makes a daily snapshot of your home and deletes snapshots more than a week old. Then you'd have a whole week to go back and recover a file you may have deleted and changed your mind about. Neat!
Enter the impending death of support for my current install!
OK, so the above title is a little over-dramatic. Support for 13.04 ends soon so I must upgrade or face the end of updates and the like. No time to do it like the present. Upgrading, rather than my usual new install, also avoids the potential Ubiquity messes. The only question is do I trust the upgrade? No need to worry: Let the snapshotting begin! PLEASE NOTE: btrfs commands, like any filesystem command, require root privileges. Rather than typing "sudo" a ba-zillion times, I opted to use "sudo -i" so I could just be root for awhile.
First, I make snapshots of my home and root directories. The btrfs filesystem I'm working on is on /dev/sda2. The "Top Level" holds all the subvolumes in the filesystem. To make things a bit easier, I mounted the "Top Level" to /mnt/sda and cd'd into it to do the snapshotting. I want the snapshots to have useful names, so I added the date and time to the name of the original subvolume in this format: yymmddhhmmss. Today is Jan. 20th, 2014 and it's 10:56 am.
Code:
root@office:/mnt/sda# btrfs subvolume snapshot /mnt/sda/@Kubuntu_13_04_home/ /mnt/sda/@Kubuntu_13_04_home_140120105600 Create a snapshot of '/mnt/sda/@Kubuntu_13_04_home/' in '/mnt/sda/@Kubuntu_13_04_home_140120105600' root@office:/mnt/sda# btrfs subvolume snapshot /mnt/sda/@Kubuntu_13_04/ /mnt/sda/@Kubuntu_13_04_140120105600 Create a snapshot of '/mnt/sda/@Kubuntu_13_04/' in '/mnt/sda/@Kubuntu_13_04_140120105600'
Code:
root@office:/mnt/sda# btrfs subvolume list /mnt/sda ID 258 gen 654214 top level 5 path @grub ID 261 gen 658686 top level 5 path @Kubuntu_12_10_home ID 262 gen 640640 top level 5 path @Kubuntu_12_10 ID 306 gen 658923 top level 5 path @Kubuntu_13_04 ID 307 gen 658923 top level 5 path @Kubuntu_13_04_home ID 400 gen 640465 top level 5 path @Neptune_31_home ID 401 gen 640465 top level 5 path @Neptune_31 ID 484 gen 658922 top level 5 path @Kubuntu_13_04_home_140120105600 ID 485 gen 658923 top level 5 path @Kubuntu_13_04_140120105600
Before snapshots:
Code:
root@office:~# btrfs filesystem df /mnt/sda Data: total=212.45GB, used=162.51GB System, DUP: total=8.00MB, used=28.00KB System: total=4.00MB, used=0.00 Metadata, DUP: total=5.00GB, used=1.86GB Metadata: total=8.00MB, used=0.00
Code:
root@office:/mnt/sda# btrfs filesystem df /mnt/sda/ Data: total=212.45GB, used=162.56GB System, DUP: total=8.00MB, used=28.00KB System: total=4.00MB, used=0.00 Metadata, DUP: total=5.00GB, used=1.87GB Metadata: total=8.00MB, used=0.00
Code:
stuart@office:~$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 13.04 Release: 13.04 Codename: raring
added at 4:58 pm
UPGRADE UP AND RUNNING.
I'm going to test 13.10 for awhile before I commit. The next step in this adventure will be booting back into 12.10 using only the snapshot. Here's the new df report:
Code:
root@office:~# btrfs filesystem df /mnt/sda Data: total=212.45GB, used=169.76GB System, DUP: total=8.00MB, used=28.00KB System: total=4.00MB, used=0.00 Metadata, DUP: total=5.00GB, used=2.33GB Metadata: total=8.00MB, used=0.00
OK - A few days later...
01/23 at 4:50pm
The version upgrade has gone well.
Code:
root@office:~# lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 13.10 Release: 13.10 Codename: saucy
Code:
root@office:~# btrfs filesystem df /mnt/sda Data: total=212.45GB, used=173.97GB System, DUP: total=8.00MB, used=28.00KB System: total=4.00MB, used=0.00 Metadata, DUP: total=5.00GB, used=2.38GB Metadata: total=8.00MB, used=0.00
It booted up fine without problems! The only thing I noticed immediately was it did not load the nvidia driver. It didn't take me long to surmise that when I did the update, the process removed the nvidia driver from the kernel in use and does not install dkms or the driver during the upgrade. When the upgrade was finished, it left me the old 3.8 kernel from 13.04 and the new 3.11 kernel from 13.10. Apparently, the snapshot function does not protect the presence of the nvidia taint in the kernel within the snapshot. This is not a deal breaker, but it is worth noting. I've kept the snapshot for now for further testing. I may attempt re-installing the nvidia driver from within the snapshot just to see if anything breaks.
(Anyone remember Gene Autry, the "Singing Cowboy"?)
Duh!
Comment