Chander Ganesan <chander@xxxxxxxxxx> 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 -- Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
