I'm in agreement. That is a recipe for a failed recovery.
If you must use some file system / volume trickery to get an initial backup then I would suggest looking into LVM or some similar volume manager. For beginners, take a look at the link below.
http://tldp.org/HOWTO/LVM-HOWTO/snapshots_backup.htmlThe technique does work however if you're using the PostgreSQL PITR backup method, which is what I am guessing at, then you're only adding overhead and complexity to the process.
Greg
On Tue, Jul 14, 2009 at 3:03 PM, Chander Ganesan
<chander@otg-nc.com> wrote:
Kevin,
Kevin Grittner wrote:
As a follow-up to this:
http://archives.postgresql.org/pgsql-admin/2009-03/msg00233.php
I just read this post. What exactly does doing the hard link buy you here? Since it's just another inode pointer to the same file, I fail to see what the purpose of it is... For example, take a look at the code below :
chander@bender:~$ echo "apple" > a
chander@bender:~$ cat a
apple
chander@bender:~$ cp -l a b
chander@bender:~$ cat b
apple
chander@bender:~$ echo "pear" > a
chander@bender:~$ cat b
pear
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, but it would be missing the "new" files that were added to the backup. Essentially making your "old" backup an incomplete backup of your new cluster.
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...
Perhaps there is something that I am missing here?
Thanks
--
Chander Ganesan
Open Technology Group, Inc.
One Copley Parkway, Suite 210
Morrisville, NC 27560
919-463-0999/877-258-8987
http://www.otg-nc.com
Expert PostgreSQL, PostGIS, and other Open Source training delivered world-wide.
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin