nube trying to backup my systems

nube trying to backup my systems

[don fisher]

[-- Attachment #1: Type: text/plain, Size: 3058 bytes --]

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

[-- Attachment #2: fstab --]
[-- Type: text/plain, Size: 4096 bytes --]

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

Re: nube trying to backup my systems

[Chris Murphy]

On Thu, Mar 19, 2015 at 5:31 PM, don fisher <hdf3@comcast.net> wrote:

> 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.

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

Re: nube trying to backup my systems

[don fisher]

>
> # 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

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

Re: nube trying to backup my systems

[Chris Murphy]

On Thu, Mar 19, 2015 at 7:49 PM, don fisher <hdf3@comcast.net> wrote:
> 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?

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

>Any thoughts on stability of the IDs across boots?

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

Re: nube trying to backup my systems

[don fisher]

On 03/19/2015 07:15 PM, Chris Murphy wrote:
> On Thu, Mar 19, 2015 at 7:49 PM, don fisher <hdf3@comcast.net> wrote:
>> 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?
>
> 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
>
>> Any thoughts on stability of the IDs across boots?
>
> They're completely reliable between reboots and renames. They're
> assigned at creation, and either btrfs sub create or btfs sub snap
> creates subvolumes.

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

Re: nube trying to backup my systems

[Chris Murphy]

On Thu, Mar 19, 2015 at 8:34 PM, don fisher <hdf3@comcast.net> wrote:

> 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.

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.
>
> /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.

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.

> tried to dismount one of the subvolumes mounted on / and got a:
>
> umount: /var/log: target is busy

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

>
> 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?

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
> understood mounting partitions, because that was the only access. But the
> appears to be two access channels here.

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

-- 
Chris Murphy

Re: nube trying to backup my systems

[Duncan]

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

> Any thoughts on stability of the IDs across boots?

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