Re: [rdiff-backup-users] atomic increment files?

[Andrew Ferguson]

On Mar 9, 2009, at 10:25 PM, Marcel (Felix) Giannelia wrote:
> (Sorry about the blank message; I just learned that ctrl+enter =  
> send in Mozilla Thunderbird :) )
>
> Anyway -- re: failure handling, I don't know exactly how I'd deal  
> with it, but I might do something like write the archive header to a  
> separate file initially, and stick it onto  the archive only when  
> the run is complete. In its intermediate form, the archive header  
> could even mimic a filesystem journal, since that process is fairly  
> well known now. True, this is an overly complicated solution...

Yup, and you'd have to guarantee that the journal is written to disk  
on the remote side, and you'd have to work out how to back-out the  
journal/archive if they were ever out of sync.

Basically, you'd turn rdiff-backup into (rdiff-backup + journaling  
filesystem).... so why not just use the existing journaling  
filesystem? :-)

That's my real argument against your proposal: it makes rdiff-backup  
much more complicated in order to make a few operations faster (and I  
don't feel the tradeoff is worth it). Operations which better tools  
(ie, "not du") can do better.

> The obvious simple solution would be to use more temp space, but  
> that would probably mean a lot more temp space. One might as well do  
> the archiving after the fact, then. (Which is probably want I'm  
> going to be doing to these backups that I have to move to DVD.)
>
> --remove-older-than would actually be a great deal faster, since if  
> it's deleting, say, 100 increments, it has to delete exactly 100  
> files as opposed to (possibly) many thousands.


Unfortunately, --remove-older-than is more complicated than that. It  
also has to transform the last remaining increment into snapshots, as  
opposed to reverse-deltas. That would be a nasty operation if all of  
the increments were in archives. (remember, rdiff-backup mostly stores  
the increments as reverse-deltas.)


Andrew