All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Greenslade <sean@seangreenslade.com>
To: Hans van Kranenburg <hans.van.kranenburg@mendix.com>
Cc: Btrfs List <linux-btrfs@vger.kernel.org>
Subject: Re: Incremental send robustness question
Date: Wed, 12 Oct 2016 19:47:43 -0400	[thread overview]
Message-ID: <20161012234743.GA5000@fox.home> (raw)
In-Reply-To: <1bfe5018-3540-319d-813f-32a0571b57d1@mendix.com>

On Thu, Oct 13, 2016 at 01:14:51AM +0200, Hans van Kranenburg wrote:
> On 10/13/2016 12:29 AM, 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.
> 
> You can't resume an interrupted send. You'll have to remove the target
> subvolume on the destination and start again.
> 
> Pipe the send into a local file, and then use any tool that can reliably
> resume interrupted transfers to get it to the other side.
> 
> Or, if faster, put in on a disk and drive there with your car. :)

I may just end up doing that. Hugo's responce gave me some crazy ideas
involving a custom build of split that waits for a command after each
output file fills, which would of course require an equally weird build
of cat that would stall the pipe indefinitely until all the files showed
up. Driving the HDD over would probably be a little simpler. =P

> > 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?
> 
> Create a list of possibilities, create some test filesystems, try it.

I may just do that, presuming I can find the spare time. Given that I'm
building a backup solution around this tech, it would definitely bolster
my confidence in it if I knew what its failure modes looked like.

Thanks to everyone for your fast responses.

--Sean


  reply	other threads:[~2016-10-12 23:56 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-12 22:29 Incremental send robustness question Sean Greenslade
2016-10-12 22:43 ` Hugo Mills
2016-10-12 22:45 ` Chris Murphy
2016-10-12 23:14 ` Hans van Kranenburg
2016-10-12 23:47   ` Sean Greenslade [this message]
2016-10-12 23:58     ` Hans van Kranenburg
2016-10-13 10:07     ` Graham Cobb
2016-10-14  4:43 ` Duncan
2016-10-16 15:57   ` Sean Greenslade

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=20161012234743.GA5000@fox.home \
    --to=sean@seangreenslade.com \
    --cc=hans.van.kranenburg@mendix.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.