On Sat, 2015-04-18 at 04:24 +0000, Russell Coker wrote: > dd works. ;)
> There are patches to rsync that make it work on block devices. Of course > that > will copy space occupied by deleted files too. I think both are not quite the solutions I was looking for. Guess for dd this is obvious, but for rsync I'd also loose all btrfs features like checksum verifications,... and even if these patches you mention would make it work on block devices, I'd guess it would at least need to read everything, it would not longer be a merge into another filesystem (perhaps I shouldn't have written "clone")... and the target block device would need to have at least the size of the origin. 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?). In the future, when an incremental backup should be made: 2) as above 3) Send/receive the each of the ro snapshots to the target fs, with using the exact matching ro snapshot on the other side as parent. (Would I need to give anything as clone-src??) 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.) 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? Thanks, Chris
smime.p7s
Description: S/MIME cryptographic signature
