[SOLVED] Backup / on whole btrfs device excl subvols on same device

bpont · 2015-07-19 17:24:23

Recently, I've migrated from ext4 to btrfs and am trying to learn how to efficiently backup my root filesystem before applying system updates. I'd rather learn how to use the tools available in btrfs-progs first before possibly switching to a third-party tool like snapper.

I wrote the file system to a whole, unpartitioned disk, which is mounted at /. Then I created a subvolume for personal data mounted at a different mountpoint under /. What I want to do is create a backup (snapshot) of the system files under / without including the personal files of the subvolume. When I check the mounted filesystems, I can see that it reports the same device for both the root and the subvolume mountpoints even though they are mounted seperately. e.g.

/dev/sda on / type btrfs (rw,relatime,compress=lzo,space_cache,autodefrag,recovery)

/dev/sda on /home/user/data type btrfs (rw,nosuid,nodev,relatime,compress=lzo,space_cache,autodefrag,recovery)

Here's a snippet from my /etc/fstab

# root filesystem
UUID=0976216b-53be-4bce-a878-fb5b28d55184	/	btrfs	relatime,autodefrag,recovery,compress=lzo	0 0

# subvolume 'data' on root filesystem       
UUID=0976216b-53be-4bce-a878-fb5b28d55184	/home/user/data	btrfs	subvol=data,rw,user,exec	0 0

Is it as simple as unmounting /home/user/data? I'm still somewhat confused about subvolumes and how they conceptually differ from partitions. I could have just simplified things by creating two btrfs volumes on two separate partitions, but I thought it would ultimately be easier to resize/manage everything if I used subvolumes instead.

Hope someone can help clarify what I'm trying to accomplish.

Last edited by bpont (2015-07-21 00:07:31)

Head_on_a_Stick · 2015-07-19 17:34:50

bpont wrote:

What I want to do is create a backup (snapshot)

snapshot != backup

bpont · 2015-07-19 17:48:40

Head_on_a_Stick wrote:

bpont wrote:
What I want to do is create a backup (snapshot)
snapshot != backup

Fair enough. I'm trying to backup my system files before an update. Under ext4 I was using fsarchiver which isn't compatible with btrfs and only operates on partitions.

ratcheer · 2015-07-19 21:20:31

Actually, a btrfs snapshot does exactly what you are asking with no extra trouble. It will contain the content of the subvolume you are snapshotting, and will not copy any subvolumes of that subvolume. It will, however, contain empty directories for the subvolumes of the subvolume, so if you copy it back, the entire structure needed will exist. Try it and see.

Tim

PS - If you need further advice, I will be happy to try to help.

Last edited by ratcheer (2015-07-19 21:21:35)

nstgc · 2015-07-19 23:48:08

I have never used FSArchiver, however on the front page it says that it works with btrfs.

bpont · 2015-07-21 00:04:45

ratcheer wrote:

Actually, a btrfs snapshot does exactly what you are asking with no extra trouble. It will contain the content of the subvolume you are snapshotting, and will not copy any subvolumes of that subvolume. It will, however, contain empty directories for the subvolumes of the subvolume, so if you copy it back, the entire structure needed will exist. Try it and see.
Tim
PS - If you need further advice, I will be happy to try to help.

I created an arch install in a virtual machine for testing purposes, created a snapshot, then recursively removed /boot on the root subvolume (ID 0). After a reboot of the virtual machine, obviously there was a fatal error. Then I booted into systemrescuecd, mounted the filesystem and changed the default subvolume to the snapshot. According to this source, that's all that should be required for a successful reboot.

Should the update go badly, instead, the snapshot can be made the default subvolume and, after a reboot, everything is as it was before.

Actually, it's not quite that simple. Rebooting simply replicated the same fatal error as before. The solution was to boot back into systemrescuecd, mount and chroot the filesystem, regenerate the grub config and then reinstall grub. Then I successfully rebooted. According to the wiki, the kernel line and fstab both need to be modified to boot into a snapshot, but I did neither and my method worked successfully. As you'd mentioned, the path of the subvolume of the subvolume showed up as an empty folder, so I could just add the relevant ID to fstab to mount it where I want.

Because of grub's failure to boot after I changed the default subvolume, which forced me to take the steps outlined, it makes me wonder what other 'gotchas' might potentially be hidden in other programs that have internal references to the root filesystem of ID 0. It shakes my confidence of using this as a reliable backup system for / but, as mentioned, I'm still very new to btrfs, so maybe I'm overstating the risks.

@nstgc
Yeah, I misspoke, fsarchiver can work with btrfs, but my filesystem is written on a partitionless whole disk, which fsarchiver cannot work with. In any case, if using btrfs as my main filesystem, I want to become proficient at using its built-in functions instead of relying on another tool. Just my preference...

I'm marking the thread as solved, though I still have some concerns, so feel free to add your thoughts or advice.

Soukyuu · 2015-07-21 22:18:32

Frankly, grub failing to boot does not surprise me. In my experience, it's a very moody piece of software.

I'm using btrfs as / myself and what I've done is creating a separate fat32 partition for syslinux, because it can't handle btrfs comression and installed syslinux on it.
On my btrfs partition, I have a subvolume named "arch_current", which is mounted as root in my syslinux boot entry:

LABEL arch-ck
    MENU LABEL Arch Linux-CK
    LINUX ../vmlinuz-linux-ck
    APPEND root=/dev/sda3 rw rootflags=subvol=arch_current,compress=lzo,ssd,noatime,autodefrag
    INITRD ../initramfs-linux-ck.img

I can then mount my btrfs partition to, say, /mnt/btrfs-root and make snapshots as needed. Then to boot into another snapshot, all I need to do is edit my boot entry and change the rootflags.

My /home is on a separate (ext4) partition, just like my /boot, so the snapshot won't include them, only reverting the system. I guess the drawback is that should I run into kernel troubles, I won't be able to restore the previous version.
Also, if you are using rootflags, make sure to include ALL mount options you like to mount it with, because btrfs won't be using the ones specified in your fstab - it only uses the options specified the first time the volume is mounted, which is during boot.

bpont · 2015-07-22 04:30:44

Well I've learned a bit more about what and what not to do and have managed to streamline and simplify things a bit.

It occurred to me that if I snapshot my / which resides on subvolid 0 and then ever needed to switch to that snapshot as my new / because of some major problem with an update, I'd have another full set of system files just sitting there taking up space on subvolid 0 because I would eventually snapshot the snapshot before the next update and new copies of the system files would be created, leaving the old ones to take up space on subvolid 0 without ever being marked as available free space. So, as an experiment in a virtual arch machine, I rm -rfv / on subvolid 0 since I had already successfully booted into the snapshot of subvolid 0 and was using that as my new default. DO NOT DO THIS. I thought rm would be a very quick operation since I'd assumed only the metadata was going to be deleted and that the data blocks which hadn't been changed since making the snapshot would still be there for the new / subvolume to use. Watching all the files scrolling by for many minutes as they were being deleting, I starting thinking maybe that was not going to be the case. A subsequent ls of the snapshot (no files) as well as a failed reboot proved that to be true.

After a bit more research, I learned:

One possible structure for managing snapshots (particularly on a root filesystem) is to leave the top level of the filesystem empty, except for subvolumes, and to set a default subvolume. The top level can then be mounted temporarily while subvolume operations are being done, and unmounted again afterwards.

This is exactly what I did when I reinstalled arch on a virtual machine. I created a subvolume named "root" on subvolid 0, set that as the default, then installed arch as usual. Afterwards, I explicitly mounted subvolid 0 without changing the default and then took a snapshot of it named, "root_snap." Then, as before, I recursively deleted /boot on subvolume "root" ( system / ). Now here's where it gets even more interesting and simplified. According to this source, only the mv command is necessary to start using a snapshot as the new /. To test it, I mv /root to /root_old, then mv /root_snap to /root and rebooted. It worked flawlessly! No need to mess around with kernel line commands, fstab or changing the btrfs subvolume default. This will make backup management very easy.

So, a possible simple set up for a new install might look like this:

subvolid 0 (empty of files, only subvolumes below)
root (arch install)
root_snap (snapshot of system before update)
data (personal files mounted at /home/user/data...this keeps personal stuff separate from the cruft ~/ can collect over time by different programs and simplifies access if you multiboot with other distros)

Then you just use the mv command as necessary to choose which subvolume to boot from without having to bother with bootloader issues and other config problems.

Lastly, if you already have your system files on subvolid 0 as I do, this source recommends a way to safely copy over the files to a subvolume before removing them. I haven't yet tested this out on a virtual machine, so use caution if you try this.

Durden · 2015-07-22 13:59:05

bpont wrote:

Well I've learned a bit more about what and what not to do and have managed to streamline and simplify things a bit.

Thanks for keeping the thread updated with your findings. I'm looking to do something similar and the info you've provided so far is very helpful. BTRFS is still new to me but I'm liking it so far, just need to learn the ins and outs of it like you.

bpont · 2015-07-23 01:26:39

More about using the mv command for booting into snapshots. If you ever try to delete an old snapshot that was previously both your system root as well as your default subvolume (which should be case if it's your system root), you'll get an "operation not permitted" error because you can't delete the default subvolume. You will need to change the default subvolume to the snapshot you are now booting from, even though, curiously enough, it's not necessary to do this when you use the mv command. In other words, snapshotting an arch install subvolume named arch_root to root_snap, then mv arch_root to root_old and mv root_snap to arch_root allows you to reboot into the new snapshot without changing the default subvolume or dealing with bootloader or config issues. You just reboot and it works. It only becomes an issue when you want to delete the previous subvolume you were booting from, which is technically still marked as the default subvolume even though this fact is somehow ignored on boot (at least with grub).

Also, if you originally installed arch to subvolid 0 like I did, and want to safely copy the files over to a subvolume for easier backup management, and then delete all the files in subvolid 0, excluding the files residing in the subvolume which will become your new /, here's how I successfully did it in a virtual machine. I haven't yet tried it on my actual system, but it should work just the same. Edit: I successfully executed the following procedure on my own system, but read my other comment at the end of this post if you have COW disabled in whole or part of your root filesystem.

Boot into a livecd (I used systemrescuecd)

Mount subvolid 0 of your btrfs device

# mount -t btrfs -o subvolid=0,(other mount options) /dev/sdXY /mnt

Create a subvolume which will become the new root filesystem

# btrfs subvolume create /mnt/arch_root

Copy over the files from /mnt to /mnt/arch_root

# cp -arv --reflink=always /mnt/* /mnt/arch_root

Use ls to make sure the root tree is present at /mnt/arch_root

# ls /mnt/arch_root

Now we can delete the files on the subvolid 0

Change directory to /mnt

# cd /mnt

Ensure you are using bash as your shell ***IMPORTANT***

# bash

Exclude arch_root from path (this command only works in bash, hence the previous step)

# export GLOBIGNORE="arch_root" (if you have other subvolumes on this device which hold data, add them or their files will be deleted in the subsequent command; e.g. export GLOBIGNORE="arch_root:sub_vol2:sub_vol3" etc...)

Remove all files from /mnt except /mnt/arch_root (which will now work due to previous step)

# rm -rfv *

Change the default subvolume to arch_root

# btrfs subvolume set-default <ID # of arch_root subvolume> /mnt

Unmount /mnt, then mount the btrfs device again which should now mount the arch_root subvolume; check with ls to ensure the / file tree is there.

Chroot into /mnt

# cd /mnt
# mount --bind /sys sys/
# mount --bind /dev dev/
# mount --bind /proc proc/
# chroot /mnt /bin/bash

Regenerate grub.cfg and reinstall grub

# grub-mkconfig -o /boot/grub/grub.cfg && grub-install --target=i386-pc --recheck /dev/sdX

Exit chroot and unmount cleanly

# exit
# cd /
# umount /mnt/sys
# umount /mnt/dev
# umount /mnt/proc
# umount /mnt

Now you should be able to reboot into your new system root.

Edit: If you have COW disabled on any files or folders, you can NOT use --reflink=always when you cp your files from subvolid 0 to another subvolume. You will get a "failed to clone, invalid argument" error from cp. You will need to simply remove the --reflink-always option from the cp command shown in the example. This modified copy procedure will take longer, since it actually copies the data blocks from source to destination, not just references to the data blocks. After removing the files on subvolid 0 and booting into your new subvolume root, you will need to reapply the nocow options on the files and folders which were copied over to the new subvolume. See more here.

Also, even though it seems possible to "trick" grub into booting into an arbitrary snapshot/subvolume using the mv command only, it seems unreliable during testing in a virtual machine. It's probably best to just go ahead and explicitly set-default to the desired subvolume in addition to using the mv command.

Last edited by bpont (2015-07-25 00:28:42)

Arch Linux

#1 2015-07-19 17:24:23

[SOLVED] Backup / on whole btrfs device excl subvols on same device

#2 2015-07-19 17:34:50

Re: [SOLVED] Backup / on whole btrfs device excl subvols on same device

#3 2015-07-19 17:48:40

Re: [SOLVED] Backup / on whole btrfs device excl subvols on same device

#4 2015-07-19 21:20:31

Re: [SOLVED] Backup / on whole btrfs device excl subvols on same device

#5 2015-07-19 23:48:08

Re: [SOLVED] Backup / on whole btrfs device excl subvols on same device

#6 2015-07-21 00:04:45

Re: [SOLVED] Backup / on whole btrfs device excl subvols on same device

#7 2015-07-21 22:18:32

Re: [SOLVED] Backup / on whole btrfs device excl subvols on same device

#8 2015-07-22 04:30:44

Re: [SOLVED] Backup / on whole btrfs device excl subvols on same device

#9 2015-07-22 13:59:05

Re: [SOLVED] Backup / on whole btrfs device excl subvols on same device

#10 2015-07-23 01:26:39

Re: [SOLVED] Backup / on whole btrfs device excl subvols on same device

Board footer