Chander Ganesan <chander@otg-nc.com> wrote:
> What exactly does doing the hard link buy you here?
For some of our largest databases, 90% of the space is in files which
don't change from one week to the next. If you read through the steps
carefully, you will see that these files (and only these files) are
hard linked from one backup to the next. This results in a backup
taking only 10% of the space it otherwise would.
> Just curious... It seems that the method described in your email
> (creating a backup using 'cp -l' and then using rsync) would
> "break" your old backup (the hard link copy) since some of the files
> in it would be modified,
You have apparently missed the fact that rsync (unless you go out of
your way to defeat this) will copy to a temporary filename, and then
mv the new file in place of the old. This doesn't modify the old
file; it unlinks the copy you are replacing, leaving any other
directory entries which point at the old data unaffected.
> but it would be missing the "new" files that were added to
> the backup.
Not at all. Re-read the rsync docs.
> In essence, a "hard link" isn't a copy of any sort, it's just a
> pointer to the same inode, which is the exact same data...
Which is exactly what we want -- for those files which didn't change
from one backup to the next.
> Perhaps there is something that I am missing here?
The main thing seems to be that (unless you use a switch to tell it
otherwise) rsync never modifies a file at the target location. It
creates new files and moves them to the correct name, and if you use
the --delete switch it unlinks files not present on the source; but it
*never* modifies an existing file on the target. The prior backup,
from which we cp -l, will never be affected.
-Kevin