Backup Question, Preserving Hard Links

[jrvz at comcast.net (James R. Van Zandt)]

Kent Borg <kentborg at borg.org> wrote:
>   On Sun, May 28, 2006 at 03:49:00PM -0400, James R. Van Zandt wrote:
>   > I'm somewhat curious about how much "excessive" is.  Anyway, I'd be
>   > tempted to try adding even more swap space (e.g. 10 GB total?)
>
>   Is 3 GB physical RAM plus 10 GB swap excessive enough?  One grand
>   rsync swallowed nearly all of that, for hours.
>
>   I think I have a solution.  I don't just have a mass of random hard
>   links, there is structure there that I didn't describe: I have a
>   series of daily backup trees, each made using the wonderful link-dest
>   feature of rsync (check the rsync man page if you haven't used
>   link-dest, it is cool).  I should be able to match up which of these
>   trees are obsolete from the previous backup (delete them) and which
>   are new (have rsync make them each in turn just as it made the daily
>   originals, but with link-dest pointing at the previous version on the
>   backup disk).

This sounds similar to what I am doing on several machines, as
described at http://jrv.oddones.org/x300.html#backup.  So, I think you
are saying that you have a parent filesystem and an on-line set of
linked backups which you update incrementally (e.g. delete day 0, add
day N).  Given an on-line set of linked backups for days 1 through N
and a removable drive with linked backups for days 0 through N-1, it
is easier to update the removable drive incrementally than it is to
delete everything and copy the current on-line backups.

Sounds reasonable.  Shrinks rsync's tables by a factor of N.  It also
gives you some flexibility - e.g. to maintain daily backups on-line,
but geometrically spaced backups on the removable drive.  If your
parent filesystem has hard links you want to preserve in the backups,
I think you need --hard-links for the *first* backup but not
thereafter (unless you add some more hard-linked files to the parent
filesystem.)

              - Jim Van Zandt