Re: [rdiff-backup-users] snap-shots every 10 diffs...

[Maarten Bezemer]

Hi,

On Mon, 23 Mar 2009, address@hidden wrote:

> So, just so we're clear - a summary of what I think you said...
>
> The every-10-diff's snapshot is for META data only.
>
> ** The source files DO NOT get a snap-shot every 10 days.
> ** The RDiffs DO NOT get a snap-shot every 10 days.

I think you're (almost*) right, except that I don't understand what you 
define as source files and RDiffs. As far as the the backed-up files go, 
they are out of rdiff-backup's scope.
The backup tree always stores the current version in full ("snapshot" if 
you insist).
*almost: you don't need to save snap-shots every X days, only every X 
times a file changed. For most files, this is a notable difference.


> (One might be able to work around this with overlapping rdiff slices,
> data repair, partial data recovery etc...but RDiff-backup won't be
> able to do a "regular" restore. This would require hand tweaking to
> perform, and would involve a fair bit of luck, depending...)

A "regular" restore usually means the data from _now_, or some point in 
time fairly recent. In normal circumstances, I wouldn't want to have 200 
increments of my files in the rdiff-backup tree. If you backup daily, AND 
your files change daily, restoring to a state of 200 days ago seems a bit 
pointless. (Same goes for hourly of course.) Could be nice for forensics, 
but then labour wouldn't be a problem, would it? ;-)

I understand that loosing (or having corrupted) increments screws up the 
entire idea of having incremental backups, although the way rdiff-backup 
works makes me a lot happier than other incremental backup tools (forward 
diffs versus reverse diffs). You could of course always backup the backup 
tree, just to be sure :-)

Regards,
 Maarten