Backup Options

Backup Options

[Harald Glatt]

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

Re: Backup Options

[Harald Glatt]

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

Re: Backup Options

[Harald Glatt]

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
Harald

Re: Backup Options

[Harald Glatt]

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
> Harald

Once 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

Re: Backup Options

[David Sterba]

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

Re: Backup Options

[Alex Lyakas]

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

Re: Backup Options

[Stefan Behrens]

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.