[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Duplicity-talk] Continuing an interrupted backup.
From: |
Kenneth Loafman |
Subject: |
Re: [Duplicity-talk] Continuing an interrupted backup. |
Date: |
Thu, 01 Nov 2007 09:14:23 -0500 |
User-agent: |
Thunderbird 1.5.0.14pre (X11/20071023) |
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