On Sun, 13 Jan 2008 [EMAIL PROTECTED] wrote: > when rdiff-backup is really cancelled while running there is no return > and rdiff-backup will need to recover first on the next run......
Although I can understand why it is done this way, I'm not entirely convinced that it can't be done differently. I mean: resume isn't considered the Right Thing because rdiff-backup is supposed to be a 'snapshot' at 1 point in time. But in practice, if you have slow links or a lot of stuff to back up, the data backed up at the end of the run may be from a much later time than the data backup up at the beginning of that run. This wouldn't be much different from starting a backup, network link breaking, and resuming 5 minutes later. Yet, this isn't supported... :-( Not knowing the python code very well, I'm not sure if saving checkpoint data in the exception handler is feasible. Same goes for reading checkpoint data and continuing from that point. Would be nice to have, but I'm not expecting anything like this to happen before we get increment-merging ;-) -- Maarten _______________________________________________ rdiff-backup-users mailing list at [email protected] http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
