[opensuse] brtfs system backup (again, sorry)
I have tried to understand how to perform a image system backup on openSuse 13.2 with a root btrfs file system. I have two disks on my computer, both have 13.2 systems. I would like to copy the running system with updates to the second. I do know how to backup the home xfs file system using rsync. Exactly what steps are required? My only thought is to add mount points for the second btrfs system similar to those existing in /etc/fstab? Root is a btrfs file system, with the other 14 subsystems mounted on it. 1. I originally suggested (in a previous email) backing up each of the subsystems using rsync. It was then suggested to use btrfs send/receive. 2. But what about the root file system? I believe that under rsync it will transfer data from all of the source subvolumes. How do I get that data to reside in the correct destination subvolumes. 3. If I do that, I do not see the need to individually backup the the subvolumes mounted on root as I previously had suggested. So would an approach be to add the dest volume and subvolume mount points, and then to an rsync from src root to the dest root? The reason for wanting to use rsync is that it can exclude certain files on the dest disk, such as /etc/fstab which holds the correct UUIDs for that system, /etc/hostname, the two boot subvolumes and maybe some network and other stuff TBD. I think the xfs /home would also be captured in this operation. My rsync command would look like: sudo rsync -rlpgouvtSAXHD --modify-window=60 -exclude-from=/home/.rsync_excludes / /usr11/ I have looked at the btrfs archives and can see no reference to preserving an operating system running under btrfs. Just data base type applications. I am concerned about an OS disk failure and my ability to come back to my current state in minimal time. Please have patience. As yet, I have not attempted to mount the second btrfs system similar to the first. I have searched Google etc. and thought a lot about the problem. If I am missing the obvious, please forgive. I remember back in the 80's when you could do an image copy with a single dd command:-) I am so glad we have made things so much simpler:-) Don -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/19/2015 12:30 PM, don fisher wrote:
I have tried to understand how to perform a image system backup on openSuse 13.2 with a root btrfs file system. I have two disks on my computer, both have 13.2 systems. I would like to copy the running system with updates to the second. I do know how to backup the home xfs file system using rsync.
rsync -varP /HomeYouAreCopyingFrom/ /HomeYouAreCopyingTo/ Don't forget the trailing / or you will not get a recursive copy. I do this all the time with my laptop so I can keep both machines in sync. I don't/won't use BTRFS so someone else will have to help you there. -- Ken Schneider SuSe since Version 5.2, June 1998 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
First step, I got the subvolumes of the second file system mounted. Not as easy as I though it would be. I had to do it mounting the UUID of each subvolume, rather than the path. Single line from /etc/fstab looks like: UUID=26d63d99-92f4-4a49-878b-236f5e88af69 /usr11/opt btrfs subvolid=UUID=3c46ec67-442b-a546-8396-0e34ce2cd493 0 0 Mount says it can only use paths relative to the root volume:-( output of df: Filesystem Type Size Used Avail Use% Mounted on /dev/sdc2 btrfs 21G 5.9G 14G 30% / devtmpfs devtmpfs 16G 0 16G 0% /dev tmpfs tmpfs 16G 88K 16G 1% /dev/shm tmpfs tmpfs 16G 2.4M 16G 1% /run tmpfs tmpfs 16G 0 16G 0% /sys/fs/cgroup /dev/sdc3 xfs 910G 109G 801G 12% /home /dev/sdc2 btrfs 21G 5.9G 14G 30% /var/tmp /dev/sdc2 btrfs 21G 5.9G 14G 30% /var/spool /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/pgsql /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% /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% /tmp /dev/sdc2 btrfs 21G 5.9G 14G 30% /boot/grub2/i386-pc /dev/sdb2 btrfs 21G 8.9G 11G 46% /usr11 /dev/sdb2 btrfs 21G 8.9G 11G 46% /usr11/boot/grub2/x86_64-efi /dev/sdb2 btrfs 21G 8.9G 11G 46% /usr11/boot/grub2/i386-pc /dev/sdb2 btrfs 21G 8.9G 11G 46% /usr11/opt /dev/sdb2 btrfs 21G 8.9G 11G 46% /usr11/srv /dev/sdb2 btrfs 21G 8.9G 11G 46% /usr11/tmp /dev/sdb2 btrfs 21G 8.9G 11G 46% /usr11/usr/local /dev/sdb2 btrfs 21G 8.9G 11G 46% /usr11/var/crash /dev/sdb2 btrfs 21G 8.9G 11G 46% /usr11/var/lib/mailman /dev/sdb2 btrfs 21G 8.9G 11G 46% /usr11/var/lib/named /dev/sdb2 btrfs 21G 8.9G 11G 46% /usr11/var/lib/pgsql /dev/sdb2 btrfs 21G 8.9G 11G 46% /usr11/var/log /dev/sdb2 btrfs 21G 8.9G 11G 46% /usr11/var/opt /dev/sdb2 btrfs 21G 8.9G 11G 46% /usr11/var/spool /dev/sdb2 btrfs 21G 8.9G 11G 46% /usr11/var/tmp Any comments? I would like to know if you think I am going in the correct direction, and if there is any way to avoid loading all of those damn UUIDs. Don -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, Mar 19, 2015 at 12:16 PM, don fisher <hdf3@comcast.net> wrote:
First step, I got the subvolumes of the second file system mounted. Not as easy as I though it would be. I had to do it mounting the UUID of each subvolume, rather than the path. Single line from /etc/fstab looks like:
UUID=26d63d99-92f4-4a49-878b-236f5e88af69 /usr11/opt btrfs subvolid=UUID=3c46ec67-442b-a546-8396-0e34ce2cd493 0 0
Mount says it can only use paths relative to the root volume:-(
"root volume" in this context means the volume's top level subvolume: In this case it means the btrfs top level subvolume. So you specify it as an absolute path. Any starting / is ignored. For example from /etc/fstab UUID=<uuid> /boot/grub2/x86_64-efi btrfs subvol=boot/grub2/x86_64-efi 0 0 The actual subvolume is x86_64-efi, but when using the subvol= mount option you have to specify its full path, which is boot/grub2/x86_64-efi. If I were to relocate this in either a subvolume or directory called "backup" then subvol=backup/boot/grub2/x86_64-efi so note that in this case there's no distinction of directory and subvolume except the last item in the path must be a subvolume. Another way around this is to use subvolid= You can get the subvolid with # btrfs sub list <mountpoint> mountpoint is where the Btrfs volume in question is mounted. -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 19/03/15 16:30, don fisher wrote:
I have tried to understand how to perform a image system backup on openSuse 13.2 with a root btrfs file system. I have two disks on my computer, both have 13.2 systems. I would like to copy the running system with updates to the second. I do know how to backup the home xfs file system using rsync.
Exactly what steps are required? My only thought is to add mount points for the second btrfs system similar to those existing in /etc/fstab? Root is a btrfs file system, with the other 14 subsystems mounted on it.
1. I originally suggested (in a previous email) backing up each of the subsystems using rsync. It was then suggested to use btrfs send/receive.
Don, You might get more expert help on the btrfs list. Send the line "subscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html There is a current thread there with the Subject "syntax for deleting subvolumes" which contains some useful information about btrfs subvolumes, and some comments about openSUSE's implementation. Bob - -- Bob Williams System: Linux 3.16.7-7-desktop Distro: openSUSE 13.2 (x86_64) with KDE Development Platform: 4.14.3 Uptime: 06:00am up 7:55, 3 users, load average: 0.16, 0.05, 0.06 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlULHk4ACgkQ0Sr7eZJrmU6dowCgmudf3kpkTSU9PbVZIfhNa/uH ezcAn2a9aQ7eBa9Fd4qRoAOGfXPVoZTO =+72L -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/19/2015 12:06 PM, Bob Williams wrote:
Don,
You might get more expert help on the btrfs list.
Send the line "subscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
There is a current thread there with the Subject "syntax for deleting subvolumes" which contains some useful information about btrfs subvolumes, and some comments about openSUSE's implementation.
Bob - -- Bob Williams System: Linux 3.16.7-7-desktop Distro: openSUSE 13.2 (x86_64) with KDE Development Platform: 4.14.3 Uptime: 06:00am up 7:55, 3 users, load average: 0.16, 0.05, 0.06 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2
iEYEARECAAYFAlULHk4ACgkQ0Sr7eZJrmU6dowCgmudf3kpkTSU9PbVZIfhNa/uH ezcAn2a9aQ7eBa9Fd4qRoAOGfXPVoZTO =+72L -----END PGP SIGNATURE-----
I have joined the list (just this morning), but it appears from the digests I looked at that most of the activity is with patches and large data center problems. I have not seen any comment at the level of backing up a silly laptop running openSuse 3.2. Don -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 19/03/15 19:12, don fisher wrote:
On 03/19/2015 12:06 PM, Bob Williams wrote:
Don,
You might get more expert help on the btrfs list.
Send the line "subscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
There is a current thread there with the Subject "syntax for deleting subvolumes" which contains some useful information about btrfs subvolumes, and some comments about openSUSE's implementation.
Bob - -- Bob Williams System: Linux 3.16.7-7-desktop Distro: openSUSE 13.2 (x86_64) with KDE Development Platform: 4.14.3 Uptime: 06:00am up 7:55, 3 users, load average: 0.16, 0.05, 0.06 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2
iEYEARECAAYFAlULHk4ACgkQ0Sr7eZJrmU6dowCgmudf3kpkTSU9PbVZIfhNa/uH ezcAn2a9aQ7eBa9Fd4qRoAOGfXPVoZTO =+72L -----END PGP SIGNATURE-----
I have joined the list (just this morning), but it appears from the digests I looked at that most of the activity is with patches and large data center problems. I have not seen any comment at the level of backing up a silly laptop running openSuse 3.2.
Don
Yes, you have to sift through all the [PATCH] updates to find the nuggets of useful information. Of course, you can always ask your question there, they don't bite ;-) Bob - -- Bob Williams System: Linux 3.16.7-7-desktop Distro: openSUSE 13.2 (x86_64) with KDE Development Platform: 4.14.3 Uptime: 06:00am up 7:55, 3 users, load average: 0.16, 0.05, 0.06 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlULITEACgkQ0Sr7eZJrmU6+1gCfZhFsmfVBsJGq0qq1nGSc+UDf CMwAn0bQBnBWoyR48Swcfg4N5WXUJXgc =qYUy -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
This is yet another reason why I don't like the openSUSE Btrfs layout, aside from being tedious to explain. It's fine for automated management, when the automated management is working. If the user wants to manage anything or even understand it, they have a lot to chew off. Two things about Btrfs: snapshots are subvolumes, they're just "pre-filled" with shared blocks with another subvolume; subvolumes are a means for snapshotting but nested subvolumes are immune from it. That is, snapshotting a subvolume isn't recursive for nested subvolumes. openSUSE doesn't use the many subvolumes it creates at install time in order to snapshot them, but rather the exclude them from being included in snapshotting. So what subvolume is being snapshot? The top level subvolume. This is a.k.a. subvolid=5, aliased to subvolid=0, sometimes called the default subvolume (even though the user can change the default subvolume, which is why it's not a great idea to refer to it as the default). When the top level subvolume is mounted at / it can be snapshot with: btrfs subvolume snapshot / <nameofsnapshot> This is what snapper is doing. i.e. btrfs subvolume snapshot / /.snapshots/6/snapshot This snapshots everything found in the top level subvolume, which happens to be mounted at /, into a snapshot called .snapshots/6/snapshot, but *EXCLUDES* any subvolumes in the top level subvolume. Check out /etc/fstab - it's really kindof of a mess. To replicate this *exactly* on another Btrfs fs, you'd need to do something like btrfs send /.snapshots/X/snapshot | btrfs receive /mnt/backup/ ## Where X is the largest number in the .snapshots list, this will be the most recent root read only snapshot which you can probably use rather than creating your own btrfs sub snap -r X Y ## where X is each of the 14 subvolumes yast2 created at install time; and Y is the name for the read-only version of it. I just tend to tack on .ro to the end of such things so I know at a glace it's an ro snapshot. btrfs send/receive each of those ro snapshots. Tedious to backup, and then also restore. Again, if it's automated, then the tediousness is eliminated, but if you're the sysadmin you still have to understand this tediousness to create and maintain any automation. How do you do a backup and restore of an openSUSE default Btrfs installation? Tedious. The more I think about it, the more I don't like it. Yes you can just treat this as a regular fs, and rsync it, flattening away all of these subvolumes. But then your restore is likewise flat, or you have to recreate the subvolumes and rsync into each individually, in order to arrive back at the same default layout you had with a clean install. Or you have to do a clean install, and rsync from backup to the clean install, in order to bring it up to date in one fell swoop. Last on the list is the btrfs seed device. But that has to be done entirely offline because it makes the Btrfs fs read-only. But you can then add the backup target device/partition, remount rw, and then delete the btrfs seed device which will cause pretty much an exact copy to be made to the 2nd device. And then you can remove the seed device flag from the 1st device and go back to using it. But the btrfs seed stuff is probably not yet stable. So I can't recommend it. Anyway, right now, I'd say the simplest backup and restore strategy for a default openSUSE btrfs install, is to not backup the system. Just backup /home, and plan on clean installing it if you have a failure. And that's yet another reason why I don't like this layout is that it makes stateless installs and restores more difficult. It's something like 1 step backwards and 2 steps sideways from the nearly foolproof ease of resets we can do on mobile devices already. Conversely on Fedora there isn't enough granularity with its Btrfs layout, where usr, var, etc are all unified in a single "root" named subvolume which is mounted at /, rather than the top level subvolume being mounted there. So it has it's own explanation and discoverability concerns, but using btrfs send receive is a cake walk; as is even a conventional rsync backup/restore. It's a ways from a stateless system layout but it's closer than the adaptation of the antiquated FHS that openSUSE is using. And despite that narrow criticism, openSUSE gets a lot of kudos for it's major efforts in Btrfs, and sticking its neck out for progress to benefit the user. Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Chris, I will wade through your email again in detail. I did not grasp it all on first read. My question is, one can write a file to /usr/local/ on the btrfs system and it ends up on the correct subvolume. I do not see any difference between me writing a single file, and rsync writing hundreds. Won't the data end up in the proper subvolummes, since rsync is addressing /usr/local/ etc. the same way I would on a normal user write. I cannot see why doing an rsync of source root to destination root would not preserve the btrfs system existing on the destination. I do not see where it should break, but have been afraid to try the experiment. I do not understand why it should flatted all of the subvolumes. What am I missing? Don -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, Mar 19, 2015 at 2:34 PM, don fisher <hdf3@comcast.net> wrote:
Chris,
I will wade through your email again in detail. I did not grasp it all on first read.
It's verbose and on-the-fly organized.
My question is, one can write a file to /usr/local/ on the btrfs system and it ends up on the correct subvolume.
If you precreate the subvolumes, yes. However rsync will treat subvolumes on the source as directories, and will create directories on the destination, not subvolumes. A subvolume is a separate fs tree. It's not quite a completely independent file system, because there are other trees in a Btrfs volume than just fs_tree types. But for instance, each subvolume starts inode counts over. So you can have two files on a Btrfs volume with the same inode (when they are in separate subvolumes).
I cannot see why doing an rsync of source root to destination root would not preserve the btrfs system existing on the destination. I do not see where it should break, but have been afraid to try the experiment. I do not understand why it should flatted all of the subvolumes. What am I missing?
See if the above works, if not ask again and I'll try again. -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
What tool does one user to make the correct partition (what kind is it), and what tool would be used to generate the btrfs file system? I think the latter is mkfs.btrfs, but is there a script that would create the file system and the subvolumes like those under as / under 3.2? Thanks, Don -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, Mar 19, 2015 at 4:15 PM, don fisher <hdf3@comcast.net> wrote:
What tool does one user to make the correct partition (what kind is it), and what tool would be used to generate the btrfs file system? I think the latter is mkfs.btrfs, but is there a script that would create the file system and the subvolumes like those under as / under 3.2?
mkfs.btrfs YaST2 (the installer) creates the subvolumes. I have no idea if it's scriptable, or if it leverages a scriptable backend. Of course you can script 'btrfs sub create' -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/19/2015 04:12 PM, Chris Murphy wrote:
On Thu, Mar 19, 2015 at 4:15 PM, don fisher <hdf3@comcast.net> wrote:
What tool does one user to make the correct partition (what kind is it), and what tool would be used to generate the btrfs file system? I think the latter is mkfs.btrfs, but is there a script that would create the file system and the subvolumes like those under as / under 3.2?
mkfs.btrfs
YaST2 (the installer) creates the subvolumes. I have no idea if it's scriptable, or if it leverages a scriptable backend. Of course you can script 'btrfs sub create'
But what type of partition is required? Don -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
It works, at least so far it does. A few minor glitches I assume having to do with not all of the file being updated. For instance, it only knows about one user, not the two on the source system, emacs is a little troubled, but mot things work. And both btrfs file systems are the sames size, within a few percent. I probably should try again, first deleting almost everything on the dest system so rsync will not hit any "newer files". Anyway, I am very pleased after the very slow boot of my USB backup system. Thanks for all the help:-) Don -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 21/03/2015 01:33, don fisher a écrit :
I probably should try again, first deleting almost everything on the
you may have to look at "fake-super". The problem is that it's pretty easy to make a backup, but very difficult to *test* the recovery :-( http://dodin.info/wiki/pmwiki.php?n=Doc.CompleteBackup#toc1 I make a daily backup, but is something goes wrong and unnoticed, the recovery will be bad. This is only for fast recovery after a major crash (the data is essentiallmy backed up elsewhere in addition) this is not special to btrfs (my server is 13.1) jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/21/2015 12:18 AM, jdd wrote:
Le 21/03/2015 01:33, don fisher a écrit :
I probably should try again, first deleting almost everything on the
you may have to look at "fake-super". The problem is that it's pretty easy to make a backup, but very difficult to *test* the recovery :-(
http://dodin.info/wiki/pmwiki.php?n=Doc.CompleteBackup#toc1
I make a daily backup, but is something goes wrong and unnoticed, the recovery will be bad. This is only for fast recovery after a major crash (the data is essentiallmy backed up elsewhere in addition)
this is not special to btrfs (my server is 13.1)
jdd
I backed up to a USB drive that I can boot, and have a computer running on it. Everything appears correct except emacs, and I forgot how I fixed it on the first machine. Should make notes! But I tested it by running it on another identical computer, best test I could think of. So I am happy with it. I agree that I do not know how to make a complete test, but it runs and all of the programs I load. I have to reconfigure the WIFI and then determine that firefox can actually get something online:-) Don -- ----------------------------------------------------------------- | Don Fisher hdf3@comcast.net | | 865 W. Cresta Loma Dr. VOICE: (520)888-7613 | | Tucson, AZ. 85704-3705 | ----------------------------------------------------------------- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (5)
-
Bob Williams -
Chris Murphy -
don fisher -
jdd -
Ken Schneider - openSUSE