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

[Kenneth Loafman]

Peter Schuller wrote:
> 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

This would have to be done for all the backends.  Not a real problem,
just a note.

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

Simpler would be a file like '/path/duplicity-halted' which could be
removed in order to restart.  You could also put the error reason in
the file itself.  Or, if you do use a socket, you could actually post
progress messages to the socket... just a thought.

> 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 could be handy.  Command line is getting long!

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

Go for it.  Sounds like a good plan.

...Ken

signature.asc
Description: OpenPGP digital signature