nube trying to backup my systems

I am new to btrfs, being introduced under openSuse 3.2 as the root file system. In the past I always made backups of my disks using rsync. I now have two versions of the OS on the same system. I was trying to mount the second btrfs system as well as the first. I edited my /etc/fstab (attached) to add a similar set of mounts as the existing system. Man mount said I needed to use the subvolume ID rather than paths. So I mounted the root of the dest file system at /usr11, and then executed:

btrfs subvolume list -u /usr11

to obtain the UUID for each subvolume. After some time in emacs I edited my fstab to include IDs. It appeared successful as the output of df -a which follows demonstrates:

/dev/sdc2      btrfs       21G  5.9G   14G  30% /
/dev/sdc2      btrfs       21G  5.9G   14G  30% /var/tmp
/dev/sdc2      btrfs       21G  5.9G   14G  30% /var/spool
/dev/sdc3      xfs        910G  109G  801G  12% /home
/dev/sdc2      btrfs       21G  5.9G   14G  30% /var/lib/pgsql
/dev/sdc2      btrfs       21G  5.9G   14G  30% /var/opt
/dev/sdc2      btrfs       21G  5.9G   14G  30% /var/log
/dev/sdc2      btrfs       21G  5.9G   14G  30% /var/lib/named
/dev/sdc2      btrfs       21G  5.9G   14G  30% /var/lib/mailman
/dev/sdc2      btrfs       21G  5.9G   14G  30% /tmp
/dev/sdc2      btrfs       21G  5.9G   14G  30% /srv
/dev/sdc2      btrfs       21G  5.9G   14G  30% /opt
/dev/sdc2      btrfs       21G  5.9G   14G  30% /boot/grub2/x86_64-efi
/dev/sdc2      btrfs       21G  5.9G   14G  30% /var/crash
/dev/sdc2      btrfs       21G  5.9G   14G  30% /usr/local
/dev/sdc2      btrfs       21G  5.9G   14G  30% /boot/grub2/i386-pc
/dev/sdb2      btrfs       21G  9.1G   11G  47% /usr11
/dev/sdb2      btrfs       21G  9.1G   11G  47% /usr11/var/tmp
/dev/sdb2      btrfs       21G  9.1G   11G  47% /usr11/var/spool
/dev/sdb2      btrfs       21G  9.1G   11G  47% /usr11/var/opt
/dev/sdb2      btrfs       21G  9.1G   11G  47% /usr11/var/log
/dev/sdb2      btrfs       21G  9.1G   11G  47% /usr11/var/lib/pgsql
/dev/sdb2      btrfs       21G  9.1G   11G  47% /usr11/var/lib/named
/dev/sdb2      btrfs       21G  9.1G   11G  47% /usr11/var/lib/mailman
/dev/sdb2      btrfs       21G  9.1G   11G  47% /usr11/var/crash
/dev/sdb2      btrfs       21G  9.1G   11G  47% /usr11/usr/local
/dev/sdb2      btrfs       21G  9.1G   11G  47% /usr11/tmp
/dev/sdb2      btrfs       21G  9.1G   11G  47% /usr11/srv
/dev/sdb2      btrfs       21G  9.1G   11G  47% /usr11/opt
/dev/sdb2      btrfs       21G  9.1G   11G  47% /usr11/boot/grub2/x86_64-efi
/dev/sdb2      btrfs       21G  9.1G   11G  47% /usr11/boot/grub2/i386-pc

I was happy until I tried to perform an ls on /usr11/tmp and found that it contained the root file system, all the /usr11 files present. My plan had been to rsync these two systems, from / to /usr11. If I umount /usr1/tmp subvolume and ls on /usr1/tmp, I obtain the expected results. Why when I mount the subvolume do I see all of the root files? I have attached my fstab for reference. I hope this is an easy one.

Thanks,
Don

UUID=094b906f-2cbe-4241-8adc-0938266023ad swap                 swap       defaults              0 0
UUID=5232a076-1062-4b49-a1c3-484a9e785bae /                    btrfs      defaults              0 0
UUID=5232a076-1062-4b49-a1c3-484a9e785bae /boot/grub2/i386-pc  btrfs      subvol=boot/grub2/i386-pc 0 0
UUID=5232a076-1062-4b49-a1c3-484a9e785bae /boot/grub2/x86_64-efi btrfs    subvol=boot/grub2/x86_64-efi 0 0
UUID=5232a076-1062-4b49-a1c3-484a9e785bae /opt                 btrfs      subvol=opt            0 0
UUID=5232a076-1062-4b49-a1c3-484a9e785bae /srv                 btrfs      subvol=srv            0 0
UUID=5232a076-1062-4b49-a1c3-484a9e785bae /tmp                 btrfs      subvol=tmp            0 0
UUID=5232a076-1062-4b49-a1c3-484a9e785bae /usr/local           btrfs      subvol=usr/local      0 0
UUID=5232a076-1062-4b49-a1c3-484a9e785bae /var/crash           btrfs      subvol=var/crash      0 0
UUID=5232a076-1062-4b49-a1c3-484a9e785bae /var/lib/mailman     btrfs      subvol=var/lib/mailman 0 0
UUID=5232a076-1062-4b49-a1c3-484a9e785bae /var/lib/named       btrfs      subvol=var/lib/named  0 0
UUID=5232a076-1062-4b49-a1c3-484a9e785bae /var/lib/pgsql       btrfs      subvol=var/lib/pgsql  0 0
UUID=5232a076-1062-4b49-a1c3-484a9e785bae /var/log             btrfs      subvol=var/log        0 0
UUID=5232a076-1062-4b49-a1c3-484a9e785bae /var/opt             btrfs      subvol=var/opt        0 0
UUID=5232a076-1062-4b49-a1c3-484a9e785bae /var/spool           btrfs      subvol=var/spool      0 0
UUID=5232a076-1062-4b49-a1c3-484a9e785bae /var/tmp             btrfs      subvol=var/tmp        0 0
UUID=ce7d48a9-c3f6-4a23-8004-5208b8276f85 /home                xfs        defaults              1 2

# UUID for subvolumes came from btrfs subvolume list -u /usr11 use df -a
#UUID=0af968c4-fbb5-4cde-b5b8-181763170a34 swap swap defaults 0 0
UUID=26d63d99-92f4-4a49-878b-236f5e88af69 /usr11 btrfs defaults 0 0
UUID=26d63d99-92f4-4a49-878b-236f5e88af69 /usr11/boot/grub2/i386-pc btrfs subvolid=UUID=b62cffe5-32dc-a44f-9117-ed1558feac83 0 0
UUID=26d63d99-92f4-4a49-878b-236f5e88af69 /usr11/boot/grub2/x86_64-efi btrfs subvolid=UUID=df44b847-81ae-a447-9cb1-2e015262125f 0 0
UUID=26d63d99-92f4-4a49-878b-236f5e88af69 /usr11/opt btrfs subvolid=UUID=3c46ec67-442b-a546-8396-0e34ce2cd493 0 0
UUID=26d63d99-92f4-4a49-878b-236f5e88af69 /usr11/srv btrfs subvolid=UUID=dc710aed-4731-ba4f-acc0-8f43e710228a 0 0
UUID=26d63d99-92f4-4a49-878b-236f5e88af69 /usr11/tmp btrfs subvolid=UUID=d3080a7a-b74c-b145-a5dc-fcf80aebda8d 0 0
UUID=26d63d99-92f4-4a49-878b-236f5e88af69 /usr11/usr/local btrfs subvolid=UUID=cab6bc25-db7c-5046-8285-7fb4e17886c9 0 0
UUID=26d63d99-92f4-4a49-878b-236f5e88af69 /usr11/var/crash btrfs subvolid=UUID=850146e1-8cc8-d84a-8895-26e4bdbf6d63 0 0
UUID=26d63d99-92f4-4a49-878b-236f5e88af69 /usr11/var/lib/mailman btrfs subvolid=UUID=44e4e9f1-030d-c846-83cb-4897bfb3c77f 0 0
UUID=26d63d99-92f4-4a49-878b-236f5e88af69 /usr11/var/lib/named btrfs subvolid=UUID=818ed2e9-24f8-3d45-bc75-f356a37167fe 0 0
UUID=26d63d99-92f4-4a49-878b-236f5e88af69 /usr11/var/lib/pgsql btrfs subvolid=UUID=f25de053-f268-1141-9131-605fde0b9d0d 0 0
UUID=26d63d99-92f4-4a49-878b-236f5e88af69 /usr11/var/log btrfs subvolid=UUID=33910c4a-88f5-4644-a67a-7e21f3b1ef67 0 0
UUID=26d63d99-92f4-4a49-878b-236f5e88af69 /usr11/var/opt btrfs subvolid=UUID=9d2dacbd-88ae-b249-a2c6-c6545d107a68 0 0
UUID=26d63d99-92f4-4a49-878b-236f5e88af69 /usr11/var/spool btrfs subvolid=UUID=5c996dfd-bc3a-314a-a69e-a43f53bde948 0 0
UUID=26d63d99-92f4-4a49-878b-236f5e88af69 /usr11/var/tmp btrfs subvolid=UUID=21190cdf-9736-ea4b-abf0-d5e93911891b 0 0
#UUID=7f2bc28a-1c69-49fb-b4a8-d4eec79d2fa5 /home xfs defaults 1 2
#UUID=26d63d99-92f4-4a49-878b-236f5e88af69 /.snapshots btrfs s ubvol=.snapshots 0 0

#/dev/sr0                                  /cdrom        auto    users,exec,dev,suid,rw,async,noauto     0       0
#/dev/sdd1                                 /usr11        auto    users,exec,dev,suid,rw,async,noauto     0       0

I'm fairly certain that subvol mount option doesn't accept UUID, it only accepts a path. This is consistent with the man 8 mount page description for Btrfs subvol anyway. If you want to use subvolume ID, use subvolid=

# btrfs sub list /
ID 257 gen 1703 top level 5 path root
ID 258 gen 1662 top level 5 path home
ID 259 gen 1681 top level 5 path boot
ID 262 gen 1629 top level 257 path var/lib/machines

To mount machines, either
subvol=root/var/lib/machines
OR
subvolid=262

Why root/var/lib/machines? Because var/lib/machines is created inside subvol 257, a.k.a. root, therefore the path relative to the top level 5 subvolume is root/var/lib/machines. It might be easier to figure this out for a while to use -a switch.

# btrfs sub list -a /mnt/btraid0/
ID 257 gen 1705 top level 5 path <FS_TREE>/root
ID 258 gen 1662 top level 5 path <FS_TREE>/home
ID 259 gen 1681 top level 5 path <FS_TREE>/boot
ID 262 gen 1705 top level 257 path root/var/lib/machines

Chris Murphy

The use of the IDs worked. I did not know where they came from, or if they would be repeatable across boots. So I assumed ID => UUID. My bad:-( My rot is mounted at /usr11. I tried:

UUID=26d63d99-92f4-4a49-878b-236f5e88af69 /usr11/srv btrfs subvol=usr11/srv 0 0

but /usr11/srv did not mount. I replaced the number and it did mount. Would like to use string like you suggested since they are more understandable. Do you see what I did wrong? Any thoughts on stability of the IDs across boots?

Thanks,
Don

Use 'btrfs subvolume list -a' like I suggested and use that path minus any leading /. Chances are the path to the subvolume srv is just srv, in which case it should be subvol=srv

They're completely reliable between reboots and renames. They're assigned at creation, and either btrfs sub create or btfs sub snap creates subvolumes.

Chris Murphy

Thanks. I will try that. How does the mount distinguish between /srv and /usr11/srv if the subvol=srv is the same for both? It appears to work, for when I do a df the sizes are different. I guess it can tell from the UUID of / as opposed to that of /usr11. I missed that one completely.

/dev/sdc2       20972544   6117628  14641012  30% /srv
/dev/sdb2       20972544   9492892  11112580  47% /usr11/srv

I would still like to know why we need to mount the subvolumes at all. I tried to dismount one of the subvolumes mounted on / and got a:

umount: /var/log: target is busy

message, so could not test to /var/log access without a mount. It is easy to access /usr11/var/log without it being mounted. Again, why mount it? I understood mounting partitions, because that was the only access. But the appears to be two access channels here.

I made another openSuse system on a 2.5" USB drive. I will use it for the test tomorrow when more of my neurons are firing.

Thanks
Don

Yes, by fs volume UUID, it can differentiate between two subvolumes with the same name. But also by /dev/ if you use mount directly. A given volume can only have on srv subvolume. It could also have srv/srv and srv/srv/srv but it'll only have one of each of those.

I missed that one completely.

That's openSUSE's design for snapshots and rollbacks with snapper. For your backup purpose, you can just mount the top level and not mount the subvolumes individually, and your rsync will work fine. It will copy the right files to the right subvolumes by virtue of them being treated like directories. It's just that rsync can't create subvolumes (yet) so if you want an exact duplicate of an openSUSE install, you have to create the subvolumes in advance of rsync.

Can't tell you what's going on. Reproduce this error and provide the current output from df and mount at the time.

Because the snapshots of root have an empty /var/log. To facilitate rollback, the static /etc/fstab always mounts these subvolumes in case the root is a rolled back snapshot.

I

Yes they are effectively bind mounts. You don't need to do this with your backup.

Chris Murphy

don fisher posted on Thu, 19 Mar 2015 18:49:32 -0700 as excerpted:

Btrfs subvolIDs are a property of the btrfs and thus stable across boots.

(They're actually the root-tree ID, with ID=5 the main root tree for the entire filesystem, various other low-digit IDs being the root trees for various sets of filesystem metadata like the chunk tree and the free- space tree, and IDs above 256 being subvolumes, with snapshots being a particular type of subvolume and thus having IDs above 256 as well. Were these numbers to randomly change, therefore, btrfs would be in a world of hurt as it couldn't find various critical root trees it needs to parse in ordered to function! So rest assured, if those numbers start changing and it's not because you deliberately decided to put a different subvolume there and forgot to change your fstab, it's a serious bug in btrfs!)

Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman