Re: [rdiff-backup-users] Old versions of files with lots of RDiff-slices

[Marcel (Felix) Giannelia]

On 20/03/09 15:40, address@hidden wrote:
> To get to the year old version, you take the current file, and apply
> 200 reverse diffs to get the old one?
> (And if any of the 200 rdiffs fail, you're stuck...)
Probably stuck, but not necessarily -- rdiff is pretty tolerant about 
applying patches, and the original file doesn't have to match exactly. 
You'll very likely get a corrupted file if you miss a patch or two, but 
depending on what you're trying to recover and how important it is, you 
could probably piece it together. This is especially true in cases where 
rdiff-backup didn't detect a file move -- a .diff for a rotated log file 
will contain the whole file (or almost all of it). You can even apply 
such a patch to a 0-byte file and have a chance of getting something 
useful back.

Another case where rdiff might be able to iron out missing files is if 
you have a file where several diffs describe the same section of the 
file -- only the last diff is really needed then.

Also, for files that don't change very often there will be a lot fewer 
than 200 diffs, which lessens your chance of this happening.

If you want some kind of insurance against this, you can try storing a 
complete copy of your mirror periodically on cheaper media (thinking of 
DVD's) -- then you can use those as starting points for restores that go 
back a long way, and you can bypass any corruption in more recent diffs.


If you want to compact/consolidate your archive of the distant past and 
you have lots of temp space (and lots of free time),  you can do this:
- restore as of a year ago to temp directory A
- run rdiff-backup to make a backup copy of temp A into temp B
- clear out temp A and restore as of 6 months ago to temp A
- run rdiff-backup from temp A to temp B again

Temp B now contains* an rdiff-backup repository of only two points in 
time -- a complete mirror of six months ago, and diffs to turn that into 
a year ago. If you're sure it worked, you can remove-older-than six 
months ago from your main repository, and have a lot fewer increment 
files. The size difference between temp B and the sum total of all the 
increments you just replaced shouldn't be all that much -- but it will 
exclude all the files that were created and removed in the space between 
the intervals (e.g. there will be no trace of log files that were 
created 51 weeks ago and rotated out of existence 50 weeks ago in this 
example), so temp B will be a bit smaller.

*: Note: I haven't actually tried this yet, so I might've overlooked 
something :)

~Felix.