On Fri, Mar 6, 2015 at 5:37 PM, Chris Murphy
Exactly reproducing a Btrfs volume onto another volume while retaining the deduplication of snapshots isn't possible yet, and poses some challenges.
A possible approximation is Btrfs seed device. There are some bugs in this area though so you should have backups and be prepared to depend on them. But the gist is that the volume is unmounted, made a seed, remount is forced read-only, add a new device, unmount, mount again which causes a read-write mount to be possible. You now have two devices: a read-only seed, and a read-write 2nd device. You can use 'btrfs device delete' on the seed and everything on the source is migrated to the read-write volume. Also, at the time the additional device is added and mounted, the volume gets a new volume UUID. So the seed device and its derivatives have separate UUIDs. However, subvolumes do not get new UUIDs so it's possible for there to be subvolume confusion if a workflow depends on subvolumes actually having unique UUIDs with no duplicates. *shrug* Like I said, challenges.
You can still rsync the current tree(s) excluding snapshots. There couldn't possibly be a law that requires you to use the same filesystem for the backup, as for the source. Certainly you could rsync the current tree to e.g. XFS using rsync and meet backup requirements.
In fact I advise a backup on something other than Btrfs, meaning exclusively depending on only Btrfs for backups is probably not a good idea. The development is just too active and there are still edge cases being found. So if the data is valuable, chances are only one backup isn't good enough, so it's find for one or more backups to be on Btrfs, even primary backups, but one of the backups should be on something else. -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org