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

[listserv . traffic]

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

Yes, thanks for the distinction. That's what I intended. (Changes in
the source file.)

> 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? ;-)

For the purposes I'm planning on using RDiff-Backup for, where...
I backup every week-day (or business day), once per day.
I'll keep about 1 year of history (200 business days) behind us.

Thus, a file could have approx, 200 rdiffs maximum to apply to get to the
maximal age-limit of the system (1 year, with 200 business days.)

As per "usual" usage pattens go.

1) Most often we'll go to the mirrored destination file, with no rdiffs applied.

2) Next, we'll go to recent versions, which will require only a few
diffs, perhaps 10-15.

3) Finally, but I know they are certain to happen occasionally...you'll get
a file that's months old, and have to apply many, many rdiff's to get
it to the version you want.

Think outlook.

Client: "I purged my inbox folder 'cause I didn't think I needed
it any more, but now I have a contract dispute with a vendor, and I
have that email in the inbox. Could you restore it from 10 months
ago, and get that message back for me?"

Me: "Certainly, Ms. Nice Paying Client. I'll be sure to do that for you!"

---
What I don't want here, is to over-sell the system. So I need to know
the risks and potential pit-falls, as well as ways to help verify the
system as best possible while in use...

---
And I certainly mirror your observations about forward increments vs.
backwards ones.

And I will be backing up the rdiff archive to a different drive as a
precaution. (And depending on the criticality, perhaps spreading the
backups of the archive between several different disks in a rotation...)

---
Thanks,
Greg

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



-- 
Best regards,
 listserv                            mailto:address@hidden