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

[Marcel (Felix) Giannelia]

(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...

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.

~Felix.



Andrew Ferguson wrote:
> On Mar 9, 2009, at 9:21 PM, Marcel (Felix) Giannelia wrote:
> > But when you're storing something that you *know* is going to be 
> > read-only and will never need to be modified again, then it makes 
> > more sense to store a nice index at the front (which is why CD's do 
> > that). Aside from unrecommended fiddling, people generally don't 
> > modify rdiff-backup's increment files so I think that would be a good 
> > application of a nice indexed archive.
>
>
> Except for --remote-older-than ...
>
>
> Also, let's consider the case where rdiff-backup fails partway through 
> a backup operation, due to say, network-link drop. In the current 
> setup, on the next run, rdiff-backup will use each of the written 
> increment files to roll-back the repository to how it looked before 
> the failed backup operation. It can do this because the increment 
> files were written individually and completely (atomicly even!) to 
> disk, before changes were made to the repository.
>
> However, with the change you propose, how could rdiff-backup always 
> recover? Would the TOC of the increment file be corrupt? Without using 
> *file* primitives like rename(), it would be hard to guarantee 
> atomicity of the pieces inside the increment file, so how would you do 
> that?
>
>
> Andrew