[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Duplicity-talk] Checkpoints during backup
From: |
Peter Schuller |
Subject: |
Re: [Duplicity-talk] Checkpoints during backup |
Date: |
Tue, 5 Aug 2008 23:49:33 +0200 |
User-agent: |
Mutt/1.5.18 (2008-05-17) |
> 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