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 :-)