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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Apr 2, 2013 at 7:37 PM, Harald Glatt <mail@hachre.de> 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! > HaraldI 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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Apr 3, 2013 at 1:29 AM, Harald Glatt <mail@hachre.de> wrote:> On Tue, Apr 2, 2013 at 7:37 PM, Harald Glatt <mail@hachre.de> 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 > HaraldHi 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Apr 3, 2013 at 4:23 AM, Harald Glatt <mail@hachre.de> wrote:> On Wed, Apr 3, 2013 at 1:29 AM, Harald Glatt <mail@hachre.de> wrote: >> On Tue, Apr 2, 2013 at 7:37 PM, Harald Glatt <mail@hachre.de> 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 > HaraldOnce I had sent the previous mail I noticed that had accidentially lied about the command on the receiver side: # nc -l -p 4444 | btrfs receive /mnt/restore However what I actually did was: # cd /mnt/restore # nc -l -p 4444 | btrfs receive . After noticing this difference I had to try it again as described in my mail and - oh wonder - it works now!! Giving ''btrfs receive'' a dot as a parameter seems to fail in this case. Is this expected behavior or a bug? Anyway I fixed my own problem and I''ll continue trying the send / receive out. Sorry for the trouble :) Thanks! Harald -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Apr 03, 2013 at 04:33:22AM +0200, Harald Glatt wrote:> However what I actually did was: > # cd /mnt/restore > # nc -l -p 4444 | btrfs receive . > > After noticing this difference I had to try it again as described in > my mail and - oh wonder - it works now!! Giving ''btrfs receive'' a dot > as a parameter seems to fail in this case. Is this expected behavior > or a bug?Bug. Relative paths do not work on the receive side. david -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi David, maybe my old patch http://www.spinics.net/lists/linux-btrfs/msg19739.html can help this issue? Thanks, Alex. On Wed, Apr 3, 2013 at 8:23 PM, David Sterba <dsterba@suse.cz> wrote:> On Wed, Apr 03, 2013 at 04:33:22AM +0200, Harald Glatt wrote: >> However what I actually did was: >> # cd /mnt/restore >> # nc -l -p 4444 | btrfs receive . >> >> After noticing this difference I had to try it again as described in >> my mail and - oh wonder - it works now!! Giving ''btrfs receive'' a dot >> as a parameter seems to fail in this case. Is this expected behavior >> or a bug? > > Bug. Relative paths do not work on the receive side. > > david > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 9 Apr 2013 16:13:22 +0300, Alex Lyakas wrote:> Hi David, > maybe my old patch > http://www.spinics.net/lists/linux-btrfs/msg19739.html > can help this issue? >The utimensat() call in process_utimes() needs the AT_FDCWD parameter to be able to receive to relative directories. I''m currently assembling a set of btrfs send/receive btrfs-progs related fixes (including the "[PATCH] btrfs-progs: Fix the receive code pathing" from you). A patch for AT_FDCWC is also included.> On Wed, Apr 3, 2013 at 8:23 PM, David Sterba <dsterba@suse.cz> wrote: >> On Wed, Apr 03, 2013 at 04:33:22AM +0200, Harald Glatt wrote: >>> However what I actually did was: >>> # cd /mnt/restore >>> # nc -l -p 4444 | btrfs receive . >>> >>> After noticing this difference I had to try it again as described in >>> my mail and - oh wonder - it works now!! Giving ''btrfs receive'' a dot >>> as a parameter seems to fail in this case. Is this expected behavior >>> or a bug? >> >> Bug. Relative paths do not work on the receive side.-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html