Hard links

[Donovan Baarda]

On Wed, Mar 13, 2002 at 02:34:42AM -0800, Ben Escoto wrote:
> >>>>> "ND" == Nick Duffek <nick@duffek.com>
> >>>>> wrote the following on Tue, 12 Mar 2002 21:31:21 -0500 (EST)
> 
>   ND> My point was that if you planned to save space by using hard
>   ND> links in rdiff-backup-data, then you'd be just one step along a
>   ND> continuum of compression.  Each step on that continuum is a
>   ND> superset of its predecessors, so if you opted for a later one,
>   ND> then you wouldn't need to implement the earlier ones.
> 
> Ok, I get it.  I would add to your discussion that in general there is
> a tradeoff between transparency and compression, and rdiff-backup
> tries to pick a reasonable compromise.  Something like the extreme
> compression point can be achieved (in theory) now by making a tar of
> the entire filesystem, and then compressing that.  Filesystem wide
> diffs could be made by using something like xdelta on two tars of the
> filesystem (representing different times), and then those diffs could
> be compressed.  In theory, this would catch all the redundancy you
> mention.
> 
>     Conversely, you could pick a point of even more transparency at
> the expense of disk space just by creating a new directory every time
> you wanted a backup, and copying the whole source directory over.

Just leaping in to this discussion blindly...

My main concern with hardlinks is preserving them on a "restore". The space
savings might be minor, but it is critical that when a filesystem is
"restored" from an older backup, it is restored with hardlinks preserved.

I'm not sure that rdiff-backup can do this currently. It _might_ be able to
do it when recovering the "latest" backup, but not when recovering an older
backup.


-- 
----------------------------------------------------------------------
ABO: finger abo@minkirri.apana.org.au for more info, including pgp key
----------------------------------------------------------------------