On Jan 17, 2009, at 6:18 PM, Chris Wilson wrote:
On Sat, 17 Jan 2009, Andrew Ferguson wrote:
The reason it hasn't been implemented is that it would require
either figuring out how much space is needed beforehand (which
requires scanning the whole source repository in advance, something
which rdiff-backup is currently not setup for; however implementing
that functionality would allow various other requested features to
be developed), or rdiff-backup would have to detect that out-of-
disk-space event, reverse the current session, delete an increment,
and start over (that, of course, hits a horrible case when the
current backup wants to add a, say, 40GB file, and deleting each
increment only frees a few MB or so).
Surely it's possible to delete an old increment without reversing
the entire backup in progress? As I understand it, a backup creates
a new increment, it doesn't touch any of the existing ones,
therefore it should be perfectly safe to delete any increment except
the one currently being created, while the backup is running. At
worst, we'd have to restart the backup of the current file, if the
out of space error left the binary diff
file hopelessly corrupted.
Oh, sure. I didn't mean to imply it wasn't possible, just that was how
it would work if you implemented it naively or with a script.
You could implement it by having rdiff-backup suspend on out-of-disk,
then start a new rdiff-backup with --delete-older-than, then wake the
original process. Currently, the second rdiff-backup process would
refuse to run (I think) due to the first one working on the
repository. It would also detect a partial backup, and then try to
reverse the partial backup.
Andrew
_______________________________________________
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
