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