On Wed, Apr 3, 2013 at 1:29 AM, Harald Glatt <mail@xxxxxxxxx> wrote: > On Tue, Apr 2, 2013 at 7:37 PM, Harald Glatt <mail@xxxxxxxxx> wrote: >> Hi list, >> >> what are currently the backup options for btrfs? >> >> Is it possible to somehow duplicate the entire filesystem including >> all snapshots without using the real space for each snapshot onto a >> remote server? (Maybe given the remote server uses btrfs too?) Are >> these features planned? >> >> Right now the only solution I know of is dd if=eachDevice, netcat and >> xz or something combined. But that is not exactly a great solution. >> >> The other thing is rsyncing a single snapshot, but if I rsync several >> they occupy the full space on the remote machine each which is also >> less than optimal... >> >> Any other suggestions? >> >> Thanks! >> Harald > > I was informed (via private mail) of the existance of btrfs send / > receive. I'm looking into that now to see how many of the things I'd > like to see are (or will be) covered by it! > > Thanks > Harald Hi all, I've attempted to try out the send/receive functionality but I can't get it to work. I've taken a random snapshot of my laptops drive and wanted to replicate it into a brand new btrfs volume in a VM. On the laptop (source): # btrfs send /snapshot | nc 10.10.10.108 4444 On the VM (receiver): # nc -l -p 4444 | btrfs receive /mnt/restore I'm getting the following messages on the receiving end, and an immediate cancellation: At subvol snapshot receiving subvol snapshot uuid=f6c01679-a373-d74e-b0ab-2074330239bc, stransid=3991 chown - uid=0, gid=0 chmod - mode=0755 utimes ERROR: utimes failed. Bad file descriptor I'm running on kernel 3.8.5 on the sending side and kernel 3.8.0 on the receiving side. btrfs-progs are from the end of January in both cases. I saw the code hasn't been maintained since August last year. Is it broken or am I making some mistake?? Thanks Harald -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
