Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
[SOLVED] Using BTRFS root snapshots for updates & roll-backs
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Installing Gentoo
View previous topic :: View next topic  
Author Message
Kethreveris
n00b
n00b


Joined: 16 Feb 2009
Posts: 16
Location: Rethwallen

PostPosted: Sat Jul 21, 2012 2:35 am    Post subject: [SOLVED] Using BTRFS root snapshots for updates & roll-b Reply with quote

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;
    Code:
    btrfsck /dev/sda3

  • 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`

Code:
ls -ld /root_*

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
View user's profile Send private message
d2_racing
Bodhisattva
Bodhisattva


Joined: 25 Apr 2005
Posts: 13047
Location: Ste-Foy,Canada

PostPosted: Sat Jul 21, 2012 4:01 pm    Post subject: Reply with quote

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
View user's profile Send private message
d2_racing
Bodhisattva
Bodhisattva


Joined: 25 Apr 2005
Posts: 13047
Location: Ste-Foy,Canada

PostPosted: Sat Jul 21, 2012 6:42 pm    Post subject: Reply with quote

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
View user's profile Send private message
Kethreveris
n00b
n00b


Joined: 16 Feb 2009
Posts: 16
Location: Rethwallen

PostPosted: Sun Jul 22, 2012 3:03 am    Post subject: Reply with quote

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
View user's profile Send private message
d2_racing
Bodhisattva
Bodhisattva


Joined: 25 Apr 2005
Posts: 13047
Location: Ste-Foy,Canada

PostPosted: Mon Jul 23, 2012 10:12 pm    Post subject: Reply with quote

I updated my method with a Live backup.

You can take a look here : https://www.funtoo-quebec.org/wiki/index.php/Discussion:Sauvegarde_Rsync_avec_Btrfs_et_SystemRescueCD
Back to top
View user's profile Send private message
Kethreveris
n00b
n00b


Joined: 16 Feb 2009
Posts: 16
Location: Rethwallen

PostPosted: Wed Jul 25, 2012 5:03 am    Post subject: Reply with quote

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
View user's profile Send private message
lyzkov
n00b
n00b


Joined: 26 Mar 2007
Posts: 6
Location: Częstochowa

PostPosted: Mon Sep 17, 2012 7:25 pm    Post subject: Reply with quote

It seems that in near future btrfs-progs would have new nice feature called autosnap. It will be possible to automatically maintain N last snapshots based on time or event with specified quota in percents of total volume space usage.
Some more info: https://btrfs.wiki.kernel.org/index.php/Autosnap and http://lwn.net/Articles/484470/
Back to top
View user's profile Send private message
Kethreveris
n00b
n00b


Joined: 16 Feb 2009
Posts: 16
Location: Rethwallen

PostPosted: Wed Sep 26, 2012 1:27 am    Post subject: Reply with quote

lyzkov wrote:
It seems that in near future btrfs-progs would have new nice feature called autosnap. It will be possible to automatically maintain N last snapshots based on time or event with specified quota in percents of total volume space usage.
Some more info: https://btrfs.wiki.kernel.org/index.php/Autosnap and http://lwn.net/Articles/484470/


Thanks, that looks interesting.
_________________
Kethreveris, (aka Kethrery)
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Installing Gentoo All times are GMT
Page 1 of 1

 
Jump to:  
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