On Mon, 17 Oct 2016, Matthias G. Eckermann wrote:
Hello Michael and all,
On 2016-10-17 T 21:49 +1300 Michael Hamilton wrote:
I was looking to make an exact copy of a tumbleweed root btrfs filesystem on removable media. One aspect that makes this more fiddly is the number of subvolumes that are part of the root filesystem, including /opt and many sub-directories of /var.
Is there any technical document describing the reasons behind having so many subvolumes? Someone else was asking the same question at stackexchange (with no real answers) :
http://unix.stackexchange.com/questions/285011/why-does-my-tumbleweed-opensu...
the reason is that these subdirectories/subvolumes must be excluded from being snapshotted, or more exactly from being rolled-back; a short explanation can be found in this old blog, for example:
https://www.suse.com/communities/blog/introduction-system-rollbacks-btrfs-an...
To make this better understood, just imagine /var/log/ being snapshotted and rolled back: This would destroy the continuity of log files and thus create confusion for normal use cases and break "compliance" where this is required (e.g. financial applications and environemnts).
Is there a recommended way to get a faithful offline bootable backup of a btrfs rootfs?
Can you describe your use case for an "offline bootable backup" in more detail?
Finally, I'm not determined to use btrfs. I'm moving up from 13.1. I'm evaluating Leap and Tumbleweed. It's a simple desktop, no RAID, one user. Would ext4 be a better choice?
I would use Leap with btrfs, if I would not be using SLES with btrfs already:-)
So long - MgE
From your answer and others, I can see that the existing structure of /var provides a tough problem in respect to keeping things simple for a btrfs based root. I see that /opt is similar - sometimes databases live in there. (Ideally a new simpler structure might be nice - but I guess we have standards to obey). In answer to your question about my use case: I want a copy of the root filesystem is for reasonably quick recovery from the loss of the underlying SSD/HD and for recovery from admin mistakes. So this would be for bootable backups to some other media, and with the option to rotate the media off site (I currently use USB-3 external drives). To a degree btrfs snaphots should protect me from admin mistakes, but not from big stuff-ups such as formatting the wrong device. For example, during the my initial install of tumbleweed, my SSD died (it was only 5 years old!). The SSD was also where my 13.1 root was kept. Because I had made an exact backup of 13.1 onto another drive, it only took a few minutes to replace the drive and get back in business. So I'd like to do the same kind of backup for tumbleweed. In the past I have used RAID, but that was prone to errors/mistakes that were faithfully replicated to all RAID members. Periodic backups to offline media is not as seemless for recovery, but it's very safe. Btrfs send|receive doesn't appear to make an exact replica, subfolders are created. I guess I could combine it with a bunch of shell scripts to get a bootable replica. From reading the answers so far, the closest I can get would be to create a btrfs volume and manually recreate the subvolume structure. Tedious, possibly error prone, but only needed once - maybe do a dummy install or dd to get it right. Then periodically use snapper to create a snapshot and rsync that. Also have rsync replicate any subvolumes I thing would be useful (e.g. /var/log and /opt). Regards, Michael -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org