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

[listserv . traffic]

[I'm not sure what the culture is about follow-ups on top, so pardon
me in advance if I violate the culture.]

The discussion about this on  prior thread appeared to negate that
as the actual behavior...

I'll quote.

From this thread:
http://lists.gnu.org/archive/html/rdiff-backup-users/2009-03/msg00114.html

---
On Mar 20, 2009, at 8:30 PM, Maarten Bezemer wrote:
> I had a question about this before, but didn't see any answer. In  
> the mean time, I've been looking at the code to see how this is  
> organised.
> In short, I only found the 10th increment being a snapshot code in  
> the metadata related python file. So, either rdiff-backup uses this  
> technique only for metadata, or I'm looking at the wrong places...


Hmm, I think that could be true. Can someone check their repository?  
(I don't keep that many increments on the servers which are handy  
right now.)

I guess it would be annoying if you had a 1gb file which had small,  
semi-regular changes. Every 10 backups ... whoops, there's another 1gb  
file.


Andrew
---

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

-Greg


>>So, if I understand this correctly...
>>
>>The "snapshot" referred to by Andrew is a "snapshot" of all the
>>rdiffs?
>>
>>So, rdiff-backup creates a "roll-up" of all the rdiffs every 10
>>rdiffs. (I'm assuming it's a "roll-up" since there's no facility to
>>merge the rdiffs.)

> Not quite. The rdiffs allow you to get from the latest version 
> (always stored in full) to a previous version. All that needs to 
> happen to store an intermediate snapshot is to save the current 
> version (which is the whole file at the time of the last backup) and 
> write a new file to be the new current version.

> Eg, over time, the repository for a single file would contain (as I 
> understand it) :

> 1 C

> 2 ra C

> 3 ra rb C

> ...

> 9 ra rb rc rd re rf rg rh C

> 10 ra rb rc rd re rf rg rh ri C

> 11 ra rb rc rd re rf rg rh ri j C

> 12 ra rb rc rd re rf rg rh ri j rk C

> Where 'C' is the current version of the file, a, b, c, ... are 
> previous versions, and ra, rb, rc, ... are the rdiffs required to 
> create a, b,c, ... from the next version. Ie, at line 3, to get 'a' 
> you would start with C, apply rb to get b, then apply ra to get a.

> Going to step 11, C is simply renamed as j, and a complete new 
> version of C is written. There are no diffs required to get from C in 
> step 9 to j in step 10.

>  From step 11 onwards, you can get to any version a..i by starting 
> with j and applying the diffs back - you don't need any later file.

>>I ask this because this issue of "snap-shots" has caused me and
>>others some confusion. I think this is especially acute from the
>>terms used in the discussion. (i.e. snapshot: which I think most of
>>us would think of as a mirror of the source file at some point in time.)

> Took me a while as well - so few "sensible" words, so many meanings :-(




-- 
Best regards,
 listserv                            mailto:address@hidden