rdiff-backup-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: listserv . traffic
Subject: [rdiff-backup-users] snap-shots every 10 diffs...
Date: Mon, 23 Mar 2009 13:51:46 -0700

> On Mar 23, 2009, at 3:51 PM, address@hidden wrote:
>> So, I really simply don't know what to believe. I don't have a case
>> first-hand I can examine to see for myself. (And the cases where
>> someone has gone and looked, there are NO snapshots, only rdiffs.)
>>
>> That's exactly why I asked this question again.
>>
>> It sounds like a myth that's widely believed, but no-one is certain
>> which way is the way it actually happens...


> Hi Greg,

> Sorry for the confusion. I know I am the source of some of it, because
> I did not realize until recently that there are two different behaviors.

> For the *metadata* files, the snapshots occur exactly as Simon just  
> described.  The metadata files are the ones in the top level of rdiff-
> backup-data, and have names like: mirror_metadata.* ,  
> extended_attributes.* , etc.

> For regular files, only reverse deltas are saved. You are correct that
> this introduces fragility in teh system. The tradeoff is that if you  
> want snapshots (like for the metadata), then your repository will grow
> much, much faster, so no snapshots are kept.


> hope this clears things up,
> Andrew

Oh, that's perfectly fine...it's simply a design decision - and
really, if the repository isn't damaged it shouldn't cause any
problems...

However, I want to have a clear idea of exactly what and where the
"weak points" are and take steps to mitigate them.

< as an aside >
I plan to stage backup to a second hard-drive on-line in the system,
and then rsync a copy to a second disk.

But for most of my client's data sets, this is really pretty trivial
in terms of cost. I can't imagine a client I have that won't be able
to fit their *data* and a year of week-day rdiffs on a 1.5TB drive.
(Usually a LOT less...)
< /as an aside >

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

The result being:
(to go back to my original example)
A restore with 200 applicable rdiffs will require:
Last RDiff mirror (snapshot) of the source file.
200 rdiffs from each of the applicable rdiff sessions.

The snap-shots above might help with file-rights or other attributes,
but for the data inside the file we rely solely on the last source
mirror and each individual rdiff.

Thus: A single missing rdiff in the chain will yield, at minimum, a failed
regular rdiff restore.

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

Right?!

Thanks for the follow-up!!!
-Greg





reply via email to

[Prev in Thread] Current Thread [Next in Thread]