Re: [Duplicity-talk] Checkpoints during backup

[Peter Schuller]

> Is this kind of thing incredibly complicated to implement with the 
> current codebase?

I am not sure about true resumeability (someone else may have more to
say) because I still don't have a good feel for the tarfile/rdiff part
of the duplicity codebase, and what issues we may run into trying to
persist the needed state. I believe a lot of state is kept implicity
on the stack right now. I could be wrong, but I suspect significant
changes are required to keep things in a way that is easily persisted.

However, something that has been discussed before is to at least
support a more proper in-process resume whereby you would have
duplicity halt waiting for some kind of operator intervention before
proceeding. So e.h., after N failures, instead of bailing, wait for
the operator to give the word to resume trying.

That would help in a number of cases, but of course not the case of
the backup client itself having to restart due to external factors.

The recommendation thus far has been, I believe, to try to split your
backups into multiple smaller ones by backuping up individual sub
directories if possible. Of course, that is a nuisance to have to do.

I'd be interested in this myself, but I think I have some other things
further up the duplicity wishlist/todo list that is also lower hanging
fruit ;)

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

pgpeIXtI9x26O.pgp
Description: PGP signature