linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "René Bühlmann" <rene@buehlmann.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: Send/receive snapshot from/between backup
Date: Wed, 16 Nov 2016 21:32:42 +0100	[thread overview]
Message-ID: <b7fae3c7-848e-f09b-4acd-1b9ce824ce99@buehlmann.net> (raw)
In-Reply-To: <7bc4c937-fbe6-2e0f-8f2c-471d6b9481ad@siedziba.pl>

On 11/02/2016 05:13 PM, Piotr Pawłow wrote:
> On 02.11.2016 15:23, René Bühlmann wrote:
>> Origin: S2 S3
>>
>> USB: S1 S2
>>
>> SSH: S1
>>
>> Transferring S3 to USB is no problem as S2 is on both btrfs drives. But
>> how can I transfer S3 to SSH?
> If I understand correctly how send / receive works, for the incremental
> receive to work there must be a subvolume on the destination which has
> "received uuid" equal to the uuid of parent choosen for the incremental
> send.
>
>> I tried to transfer...
>>
>> 1. S3 from Origin to SSH -> does not work as there is no common snapshot.
>>
>> 2. S2 from USB to SSH -> did not work.
> The "received uuid" of S1 on SSH is the uuid S1 had on Origin. The uuid
> of S1 on USB is different, so when choosen as parent for the incremental
> send it doesn't match.
>
>> 3. S1 from USB to Origin (such that there is a common snapshot with SSH)
>> -> did not work.
> There are no previously received subvolumes on Origin at all, so it
> isn't going to work.
>
>> Is it correct that 1. would work if a common snapshot is present on
>> Origin and SSH?
> If there was a snapshot received from Origin that still exists on
> Origin, then yes, you could use it as a clone source for incremental send.
>
>> Is it expected that 2. and 3. do not work?
>>
>> Is there some other way to achieve it?
> I doubt you can do it without some "hacking" to fool btrfs receive.
>
> You would need a tool that can issue BTRFS_IOC_SET_RECEIVED_SUBVOL ioctl
> to change the received uuid. Then you could:
>
> 1. Change received uuid of S1 on SSH to match S1 uuid on USB.
> 2. Send incremental S1-S2 from USB to SSH.
> 3. Change received uuid of S2 on SSH to match S2 on Origin.
> 4. Send incremental S2-S3 from Origin to SSH.
>
> Regards
>
Thanks for all the input,

I did successfully try this approach, could change the "received uuid"
and then transfer a snapshot from a different source. So far so good.

But:

Due to a lot of errors during btrfs check on SSH, I decided to recreate
the BTRFS filesystem on SSH still with the goal to not transfer all the
data over the network.

These were the steps:

1. Create a new btrfs (calling it SSH')

2. Full transfer S1 from SSH to SSH'

3. Incremental transfer S2 from USB to SSH' (S1 as parent)

4. Incremental transfer S3 from Origin to SSH' (S2 as parent)

5. Btrfs check SSH'

6. Used rsync (with checksum-diff) to verify that S3 on Origin and SSH'
contain the same files.


Step 2 did work and beside of a single checksum error on SSH the
transfer completed without errors.

Step 3 and 4 did work as well and surprisingly, I did not even had to
update the "received uuid". They cant be full transfers as that would
have taken months with my bandwidth. How can this be?

Step 5 did not return any errors

Step 6 did find a single file differing which is due to the checksum
error on step 2.


So, everything seems to be fine now, I just do not understand why this
did work without any updating of the UUID.
Do you have an explanation for that?

In any case, thanks for your help.
René



  reply	other threads:[~2016-11-16 20:32 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-02 14:23 Send/receive snapshot from/between backup René Bühlmann
2016-11-02 14:49 ` Hans van Kranenburg
2016-11-02 15:14   ` René Bühlmann
2016-11-02 18:22     ` Send/receive snapshot from/between backup (also restore example) Hans van Kranenburg
2016-11-02 16:13 ` Send/receive snapshot from/between backup Piotr Pawłow
2016-11-16 20:32   ` René Bühlmann [this message]
2016-11-18  7:23     ` Piotr Pawłow

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b7fae3c7-848e-f09b-4acd-1b9ce824ce99@buehlmann.net \
    --to=rene@buehlmann.net \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).