Re: [Duplicity-talk] Continuing an interrupted backup.

[Peter Schuller]

> I've now resorted to NOT using duplicity, in favor of regular rsync, just 
> so I can get the servers backed up, but now I'm not using encryption on the 
> remote storage. Obviously, duplicity is the favored solution, but until we 
> can resume interrupted backups, I'm not certain I can use it :(

I was going to look into patching for the following feature, but since
it has been brought up:

How about:

(1) Possibly implementing expoential backoff for re-tries to make it a
bit more general, but in particular

(2) Allow the use of a mode where duplicity will NEVER give up, but
instead, after some number of retries, sit there waiting for the
operator to explicitly ask it to resume. This could be done by
touching some file, or by an interactive prompt (touching a file,
previously specified on the command line, is something I like due to
scriptability). Alternatively it could wait for a command on a socket.

The idea is that you run your long-running backup with something like:

  --interactive-resume=/path/to/socket

Perhaps even with:

  address@hidden

And when things crap out, a human being can intelligently tell
duplicity to resume when whatever problem is happening is finished.

This should be pretty easy to implement compared to "real" resumption
by re-starting duplicity, since no additional state mangament is
needed - the current retry loop just has to be modified slightly.

Thoughts? If people like it I'll have a stab at it.

-- 
/ Peter Schuller

PGP userID: 0xE9758B7D or 'Peter Schuller <address@hidden>'
Key retrieval: Send an E-Mail to address@hidden
E-Mail: address@hidden Web: http://www.scode.org

pgpovm0bKzm7I.pgp
Description: PGP signature