Re: [opensuse-factory] btrfs root - why so many subvolumes?
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
Hello, On Oct 18 10:05 Michael Hamilton wrote (excerpt):
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
No special filesystem can help when the underlying SSD/HD or any other crucial hardware breaks. You need a real backup plus a recovery medium to be able to do bare metal recovery. See https://en.opensuse.org/SDB:Disaster_Recovery Regarding backup on the recovery medium see http://relax-and-recover.org/documentation/getting-started As a generic starting point have a look at https://en.opensuse.org/images/8/85/Essentials_about_disaster_recovery_with_... Regarding "reasonably quick recovery": Disaster recovery with Relax-and-Recover is very fast. Basically the only thing that usually needs time is to restore the backup. On my SLE12 tests systems with only a few GB of files and fast network access to the backup.tar.gz (via NFS) the plain "rear recover" is done in about one or two minutes. But disaster recovery with Relax-and-Recover is not something for unexperienced end-users, read https://en.opensuse.org/SDB:Disaster_Recovery Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Graham Norton - HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2016-10-18 11:36, Johannes Meixner wrote:
Hello,
On Oct 18 10:05 Michael Hamilton wrote (excerpt):
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
No special filesystem can help when the underlying SSD/HD or any other crucial hardware breaks.
You need a real backup plus a recovery medium to be able to do bare metal recovery.
Yes, that's what he does, and we do, but the problem we have is that if root is btrfs in the original system we do not have a method to replicate that subvolume structure into another btrfs (external) disk. The only method that occurs to me is installation to the external disk, then erase it, to force yast to create the structure. Or dd the root, then grow partition to destination capacity. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
participants (3)
-
Carlos E. R. -
Johannes Meixner -
Michael Hamilton