On Sun, 2015-04-19 at 01:02 +1000, Russell Coker wrote: > An rsync on block devices wouldn't lose BTRFS checksums, you could run a > scrub > on the target at any time to verify them. For a dd or anything based on that > the target needs to be at least as big as the source. But typical use of > BTRFS for backup devices tends to result in keeping as many snapshots as > possible without running out of space which means that no matter how you were > to copy it the target would need to be as big. Hmm all not really satisfying.
> > Can't one do something like the following: > > 1) The source fs has several snapshots and subvols. > > The target fs is empty (the first time). > > > > > > For the first time populating the target fs: > > > > 2) Make ro snapshots of all non-ro snapshots and subvols on the > > source-fs. > > > > 3) Send/receive the first of the ro snapshots to the target fs, with no > > parent and no clone-src. > > > > 4) Send/receive all further ro snapshots to the target fs, with no > > parents, but each time specifying one further clone-src (i.e. all that > > have already been sent/received) so that they're used for reflinks and > > so on > > > > 5) At the end somehow make rw-subvols from the snapshots/subvols that > > have been previously rw (how?). > > Sure, for 5 I believe you can make a rw snapshot of a ro subvol. So, is clone-src really what I think it is? Or better, what exactly are the parent and clone-srcs and how do they work? AFAIU the clone-src is a ro snapshot on the SOURCE(!) fs, that has previously sent to the target fs (thus it's there as well). So for the snapshot that is sent "now" it looks for any blocks that are also in the SOURCE fs version of clone-src and for those it only sends reflinks... and on the target fs these are again used. So I'd guess each of these blocks has some kind of ID that is sent? But that already sounds quite similar to what I'd expect parent to be: When I send a ro snapshot the first time, e.g. $ btrfs subvolume create /src-btrfs/foo # do stuff in foo # first time backup of foo: $ btrfs subvolume snapshot -r /src-btrfs/snapshots/foo-2015-01 $ btrfs send /src-btrfs/snapshots/foo-2015-01 | btrfs receive /trgt-btrfs/ # do more stuff in foo # secondary backup of foo: $ btrfs subvolume snapshot -r /src-btrfs/snapshots/foo-2015-04 $ btrfs send -p /src-btrfs/snapshots/foo-2015-01 /src-btrfs/snapshots/foo-2015-04 | btrfs receive /trgt-btrfs/ # then it would know that foo-2015-01 is already on /trgt-btrfs/ and # only send the differences between those two? # I guess the UUID and gen of foo-2015-01 would be the same on both # sides? And foo-2015-04 would then have the UUID of foo-2015-01 as # parent on the target side? Now if I make another subvolume on the source, which shares *some* refs with foo, e.g. $ btrfs subvolume create /src-btrfs/bar # do stuff in bar, or e.g let bar be another ro or rw snapshot of # foo that has been modified # Then I'd use clone sources to transfer this data efficiently? $ btrfs send -c /src-btrfs/snapshots/foo-* /src-btrfs/bar | btrfs receive /trgt-btrfs/ My actual situation is this: I have a btrfs-fs, with one non-snapshot subvolume (i.e. the root subvolume) and a number of snapshots, e.g. 2015-01 2015-02 2015-03 All being ro-snapshots from the root subvol. And I want to get all these snapshots copied over to the target fs (i.e. I want the snapshot history preserved). ATM, I do I send receive on the first snapshot I've made like: $ btrfs send /src-btrfs/snapshots/2015-03-10/ | btrfs receive /trgt-btrfs/ Afterwards I'd expect 2015-01 to be "copied" over. How would I continue with -02 and -03? Using -01 as parent? Or as clone-src? (Did I mention before, that the overall documentation seems to be really in a... "suboptimal" state? :-( ) > > Does that sound as if it would somehow work like that? Especially would > > it preserve all the reflink statuses and everything else (sparse files, > > etc.) > Yes, but it would take a bit of scripting work. What do you mean? To automate if for arbitrary number of subvols? > > Some additional questions: > > a) Can btrfs send change anything(!) on the source fs? > > b) Can one abort (Ctrl-C) a send and/or receive... and make it continue > > at the same place were it was stopped? > > A yes Mhh than it's really weird that it's allowed to work on a ro-mounted fs?! Doesn't look that trustworthy :-( > , B I don't know. Yeah, as posted somewhere above, I found out myself in the meantime that one cannot even temporarily stop such process without having it failing. > Also I'm not personally inclined to trust send/recv at this time. I don't > think it's had a lot of testing. Moreover, it seems to have rather bad performance (though I haven't done any thorough testing/measuring). Right now I send/receive a first subvolume from a HDD to another, the 2nd being a fresh btrfs, both fs with -o compress. Both filesystems are on top of dm-crypt on a SATA 8TiB HDD connected via USB (the source 3, the target 2). The system is rather powerful, 8 cores, 16 TiB RAM. Most of the time, only one of the two disks shows activity, while the other is reading respectively writing. The CPU isn't really under full load either (not even a single core),... it's rather in the 5-10% utilisation. The resulting transferspeed is about 21,5 MB/s (not MiB). Seems to be pretty low... Also, the system freezes up all the time for some seconds... so there is probably some IO scheduling issue. Further, when I run e.g. btrfs filesystem show, it actually prints the info for both, but afterwards it seems to hang forever. Thanks, Chris.
smime.p7s
Description: S/MIME cryptographic signature
