Re: Incremental send robustness question

[Hugo Mills <hugo@carfax.org.uk>]

[-- Attachment #1: Type: text/plain, Size: 2374 bytes --]

On Wed, Oct 12, 2016 at 06:29:55PM -0400, Sean Greenslade wrote:
> Hi, all. I have a question about a backup plan I have involving
> send/receive. As far as I can tell, there's no way to to resume a send
> that has been interrupted. In this case, my interruption comes from an
> overbearing firewall that doesn't like long-lived connections. I'm
> trying to do the initial (non-incremental) sync of the first snapshot
> from my main server to my backup endpoint. The snapshot is ~900 GiB, and
> the internet link is 25 Mbps, so this'll be going for quite a long time.
> 
> What I would like to do is "fake" the first snapshot transfer by
> rsync-ing the files over. So my question is this: if I rsync a subvolume
> (with the -a option to make all file times, permissions, ownerships,
> etc. the same), is that good enough to then be used as a parent for
> future incremental sends?

   No, it needs some additional subvol metadata to be set so that the
receiver can detect which subvol to snapshot when restoring an
incremental.

   Depending on how much local storage you have, you could do
something like write the send stream to disk (split into pieces), and
then copy each piece to the receiver, and cat those all together to
replay them. It'd be a bit hairy to get the timing right, though,
without emptying or filling the various pipes.

> And while we're at it, what are the failure modes for incremental sends?
> Will it throw an error if the parents don't match, or will there just be
> silent failures?

   It'll throw an error, as far as I know.

> I would imagine receive would barf if it was told to
> reference a file that didn't exist, but what if the referenced file is
> there but contains different data? Are there checks for this sort of
> thing, or is it always assumed that the parent subvols are identical and
> if they're not, you're in undefined behavior land?

   The parent subvols have UUIDs in them which should act as a
sufficient check for any accidental errors. (See the received-subvol
option for btrfs sub list). It's not robust against an attacker that
can control the UUIDs... but then, if they can do that, there's a
whole load more problems you've got.

   Hugo.

-- 
Hugo Mills             | Great oxymorons of the world, no. 8:
hugo@... carfax.org.uk | The Latest In Proven Technology
http://carfax.org.uk/  |
PGP: E2AB1DE4          |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]