View previous topic :: View next topic |
Author |
Message |
Kethreveris n00b
Joined: 16 Feb 2009 Posts: 16 Location: Rethwallen
|
Posted: Sat Jul 21, 2012 2:35 am Post subject: [SOLVED] Using BTRFS root snapshots for updates & roll-b |
|
|
Here is a How-To I am writing on BTRFS root snapshots. I'd appreciate some constructive
comments and verification. Later I'll see about publishing it with kernel.org under BTRFS.
Editted: To include putting the ROOT FS into a BTRFS sub-volume directly. Then naming
the ROOT FS sub-volumes with the creation date. Further, make the snapshot sub-volumes
in the BTRFS root not as children of the ROOT FS being snapshotted.
How to install, snapshot and update root FS using BTRFS
Doing updates on Linux can be problematic. If the update does not go well, a full restore
may be needed. In the past, I have performed full backups before updates in just this case.
These full backups include all the necessary information and data to bring the workstation
or server back to it's state at the time of the backup.
However, on occasion it's been anoying to perform the full backup. At other times, performing
the full restore takes too much time. In some cases I would have to boot CD-ROM, perform
>60 minutes of initialization before I could start the restore. Then the restore would add more
time, hours in some cases.
Since Solaris 10, (both SPARC and x64), has both alternate boot environments and ability to
roll back updates, I looked into the possiblity of doing the same with Linux. My solution was
to have 2 separate root FSes, "/", for each Linux box I maintain. All had enough room on the
built in hard drives for that purpose, except my netbook. That EeePC 900 had 16GB flash
card, which I upgraded to 64GB. More than enough for an alternate boot environment.
All that has worked well for more than a year. Before updates, I copy over the primary boot
environment to the alternate boot environment. Update the new boot environment's "/etc/fstab"
for it's root FS. Add a new Grub entry for the new boot environment, using the kernel line option
"root=/dev/sdaX" to point to the proper disk partition. Last, re-boot to that new root environment,
test and update as needed. The exact procedure is not relevant for this document.
Recently I looked into performing something similar with reduced disk space requirements.
Having 2 dedicated partitions for this upgrade is quite acceptable in all but 1 of my uses. In that
case, it would be a new build on x64. Based on my experience with Solaris 11 and ZFS root, it
seemed like BTRFS would be worth checking out. After performing some tests using BTRFS
with writable snapshots, it seems promising. So here is how I did it.
First, lets begin with the following assumptions:
- Testing was on a x86, (32 bit), environment with local disk
- Production would be on a x64, (64 bit), virtual environment with SAN disk
- All testing and production was with Gentoo Linux distro
- Latest kernel available with Gentoo Linux, in the "gentoo-sources" tree, on 2012/07/15 was used, 3.4.4.
- Latest "btrfs-progs" package was used, (un-masked with accept keyword ~x86).
- A separate boot partition was used.
- A separate swap partition was used.
- Grub 0.97.x was used
- Simple kernel entry in "/boot" was used, not initial RAM disk.
- The Kernel was compiled with both EXT4, (used in "/boot"), and BTRFS included, (not as modules).
- Ability to create a writable snapshot, boot from it, update as needed and roll back if required is the goal.
- Further, the ability to destroy the original source boot environment to save space, (promote clone in
Solaris ZFS terminology). This does not mean you have to do so right away, just going back more than
say 4 updates seems like over-kill.
- Management of the boot environments is needed as well. For example, say you are in the middle of
an update, and need to test something out. You can create a parallel boot environment, (from same
source), boot to it and perform your test. Then destroy if desired.
The setup assumes knowledge of Linux installs and Gentoo in specific. It's possible and likely
other Linux distros could be used, but that is not covered here. Further, this document
concentrates on what I needed solved now.
Others seem to have figured out how to have "/boot" as a sub-volume of the BTRFS root partition
using Grub 2.x. Some Linux distros require an initial RAM disk to be created and used in "/boot".
Again, such variations are not covered.
Basically start out with a bootable environment, with enough free disk space for the BTRFS partition.
Here are the general steps;
- Have enough disk space for the BTRFS partition
- Boot Linux
- Get recent kernel sources, (3.4.4 or later)
- Compile BTRFS into the kernel along with EXT4, (not as modules)
- Get and load recent "btrfs-progs" package
- Update "/boot/grub/grub.conf" to allow booting new kernel
- Reboot to new kernel, (still on existing EXT root file system)
That should get to the point that BTRFS is now available.
Perform the following;
- Create BTRFS file system using something like;
Code: | mkfs.btrfs --data single --label root_sda3_0 --metadata single --sectorsize 4096 /dev/sda3 |
Run simple check;
Add in alternate boot environment and mount it;
Code: | mkdir /abe
cp /etc/fstab /etc/fstab.`date +%Y%m%d`
echo "/dev/sda3 /abe btrfs noauto,async,relatime,nodiratime,subvolid=0 1 0" >>/etc/fstab
mount /abe |
Make the root FS sub-volume, then make it the default FS for the partition;
Code: | btrfs subvolume create /abe/root_`date +%Y%m%d`
btrfs subvolume list /abe
{Get SUB_VOL_ID, probably 256}
btrfs subvolume set-default ${SUB_VOL_ID} /abe/root_`date +%Y%m%d` |
Now comes the copy part of the process. In my test case, I copied over an EXT4 root file
system to the BTRFS alternate root file system. No other partitions were needed in my
case, meaning no separate "/var", "/var/tmp", etc... I use "rsync" as the copy program but
other methods could be used. This is what I did;
Code: | rsync -aHx --sparse --stats / /abe/root_`date +%Y%m%d`/
rsync -aHx --sparse --stats /dev/ /abe/root_`date +%Y%m%d`/dev/
touch /abe/root_`date +%Y%m%d`/root_0 |
After the copy was complete, we need to update that new root FS's copy of "/etc/fstab"
to reflect the new root file system;
Code: | cd /abe/root_`date +%Y%m%d`/etc
cp fstab fstab.`date +%Y%m%d`
vi fstab
{Change root FS mounting as below}
/dev/sda3 / btrfs async,relatime,nodiratime 1 1
cd /
sync
umount /abe |
Update Grub as needed;
Code: | cd /boot/grub
cp grub.conf grub.conf.`date +%Y%m%d`
vi grub.conf
{Copy current boot environment, then edit boot disk.}
{Update new boot environment comments if needed.}
|
Save it.
Reboot and test. Whence everything seems to be working, continue.
Here are some tests you can perform;
Code: | grep btrfs /proc/filesystems
grep /dev/root /etc/mtab
df -kh / |
Code: | mount /abe
btrfs scrub start /abe/root_`date +%Y%m%d`
btrfs scrub status /abe/root_`date +%Y%m%d`
|
Should show "/root_0" as zero length file.
Create snapshot of root FS, make active and reboot;
Code: | mount /abe
btrfs subvolume snapshot /abe/root_`date +%Y%m%d` /abe/root_`date +%Y%m%d`_1
rm /abe/root_`date +%Y%m%d`_1/root_0
touch /abe/root_`date +%Y%m%d`_1/root_1
ls -l /root_* /abe/root_`date +%Y%m%d`_1/root_*
{should show "/root_0" and "/abe/root_`date +%Y%m%d`_1/root_1"}
btrfs subvolume list /abe
{Select subvolume ID}
btrfs subvolume set-default ${SUB_VOL_ID} /
shutdown -r now
|
After reboot, check out new boot environment;
Code: | ls -l /root_*
{should show "/root_1"}
|
Perform any desired or needed updates.
When it's time to remove an old ROOT FS snapshot, here are the steps.
This assumes it's not in use as the booted ROOT FS.
Code: | mount /abe
btrfs subvolume list /abe
{Select the ROOT FS to remove}
btrfs subvolume delete /abe/root_`date +%Y%m%d` |
If it's needed to back out a new boot environment, here are the steps;
Code: | mount /abe
btrfs subvolume list /abe
{select snapshot to become current}
btrfs subvolume set-default ${SNAPSHOT_ID} /
{Reboot to new boot environment, freeing up the sub-volume snapshot}
btrfs subvolume list /
{select snapshot to remove}
btrfs subvolume delete ${SNAPSHOT_NAME}
|
For above, those could be 257 for SNAPSHOT_ID and "/abe/root_`date +%Y%m%d`" for SNAPSHOT_NAME.
Using the date as part of the sub-volume name allows some management of the snapshots. Any
scheme can be used, including simple numeric progression, (like "root_0", "root_1", etc..).
One thing that is useful, is to setup clear, precise procedures for performing updates. Whether it's
backups, updates, tests, or new boot environment as outlined here, clear procedures mean regular
results. _________________ Kethreveris, (aka Kethrery)
Last edited by Kethreveris on Wed Sep 26, 2012 1:30 am; edited 4 times in total |
|
Back to top |
|
|
d2_racing Bodhisattva
Joined: 25 Apr 2005 Posts: 13047 Location: Ste-Foy,Canada
|
Posted: Sat Jul 21, 2012 4:01 pm Post subject: |
|
|
Hi, one of my friend is using a subvolume to install his Gentoo box instead of using the root 0 inside his btrfs.
Because of that, he can backup what ever he wants.
/dev/sda1 is his /boot and /dev/sda2 is /: with 2 subvolume @root @home
/dev/sdb1 is an external HDD with a btrfs partition that has a subvolume @backup
So when he is running his box, he can run that :
Code: |
# mkdir /mnt/disklayout
# mount /dev/sda2 /mnt/disklayout -o subvolid=0
# cd /mnt/disklayout
# btrfs subvolume snapshot @root snapshot-@root-live
# btrfs subvolume snapshot @home snapshot-@home-live
# mount /dev/sdb1 /mnt/backup -o subvol=@backup
# time rsync -aHA --del --force --stats --progress snapshot-@root-live/ /mnt/backup/gentoo
# time rsync -aHA --del --force --stats --progress snapshot-@home-live/ /mnt/backup/gentoo/home
# time rsync -aHA --del --force --stats --progress /boot/ /mnt/backup/gentoo/boot
# cd /mnt/disklayout
# btrfs subvolume delete snapshot-@root-live
# btrfs subvolume delete snapshot-@home-live
# cd /
# umount /mnt/disklayout
# umount /mnt/backup
# mount /dev/sdb1 /mnt/backup -o subvolid=0
# cd /mnt/backup
# btrfs subvolume snapshot @backup @snap-20120721
# btrfs subvolume list .
# cd /mnt/backup
# ls -la
# cd @snap-20120721
# ls -la
# cd /
# umount /mnt/backup
|
|
|
Back to top |
|
|
d2_racing Bodhisattva
Joined: 25 Apr 2005 Posts: 13047 Location: Ste-Foy,Canada
|
Posted: Sat Jul 21, 2012 6:42 pm Post subject: |
|
|
So what do you think Kethreveris ?
Also, I read somewhere that we never use the subvolid=0 to install a distro but you need to create a subvolume and then install your stuff inside.
Ubuntu does that when you install 12.04 with BTRFS.
I saw good article about BTRFS here : http://www.funtoo.org/wiki/BTRFS_Fun |
|
Back to top |
|
|
Kethreveris n00b
Joined: 16 Feb 2009 Posts: 16 Location: Rethwallen
|
Posted: Sun Jul 22, 2012 3:03 am Post subject: |
|
|
Yes, that method of installing root FS into a sub-volume directly sounds better than my original.
I'll give that Funtoo article a read.
Thanks.
And it seems like I can remove the "rm" command, (gee isn't that redundant , and use the
following instead. Much cleaner.
Code: | btrfs subvolume delete ... |
Using the method to install the OS into a sub-volume directly allows it to be named from the
beginning. Plus snapshotting from the subvol ID 0 seems better than from inside the root FS
sub-volume. I'll see about changing the original procedure to have these refinements.
Maybe even change the new root FS sub-volume snapshots to include date, since they won't
be visible under normal conditions. This would assist in management of the various snapshots.
Code: | # btrfs subvolume list /
ID 267 top level 5 path root_20120601
ID 268 top level 5 path root_20120701
ID 269 top level 5 path root_20120715 |
_________________ Kethreveris, (aka Kethrery) |
|
Back to top |
|
|
d2_racing Bodhisattva
Joined: 25 Apr 2005 Posts: 13047 Location: Ste-Foy,Canada
|
|
Back to top |
|
|
Kethreveris n00b
Joined: 16 Feb 2009 Posts: 16 Location: Rethwallen
|
Posted: Wed Jul 25, 2012 5:03 am Post subject: |
|
|
Thanks for the new link, I'll check it out soon.
I've also editted the original post's procedure to include the following enhancements;
- Used a sub-volume for the original ROOT FS, which makes management cleaner
- Showed example of naming the ROOT FS sub-volumes with creation date, also helps management
- Made the snapshot sub-volumes as items in the BTRFS root, not as a child of the ROOT FS being snapshotted
Anyone reading this, post a comment if you find ways to improve or correct the procedure. _________________ Kethreveris, (aka Kethrery) |
|
Back to top |
|
|
lyzkov n00b
Joined: 26 Mar 2007 Posts: 6 Location: Częstochowa
|
|
Back to top |
|
|
Kethreveris n00b
Joined: 16 Feb 2009 Posts: 16 Location: Rethwallen
|
Posted: Wed Sep 26, 2012 1:27 am Post subject: |
|
|
Thanks, that looks interesting. _________________ Kethreveris, (aka Kethrery) |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|