You should implement filesystem or volume level snapshots. LVM, Veritas and the like all have the functionality and it gets the database out of "backup" mode quickly.
Before the lvcreate -s command issue the pg_start_backup() and after pg_stop_backup(). Then do what you will with the snapshot volume. Just in case a fsck may be necessary I'd recommend mounting read-only.
Caveat emptor, I believe certain filesystems take issue with this, like xfs, however we have not seen anything unusual with ext3. Also note that you must have some space unallocated in the proper LVM disk group for the snapshot volume.
Greg
From: pgsql-admin-owner@postgresql.org on behalf of Tom Lane
Sent: Mon 4/10/2006 7:19 PM
To: Bruce Momjian
Cc: andy.shellam@mailnetwork.co.uk; 'Rajesh Kumar Mallah'; pgsql-admin@postgresql.org
Subject: Re: FW: [ADMIN] Setting up of PITR system.
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> It definitely is a pain in the neck that GNU tar complains about files
>> changing underneath it --- I've looked for a way to disable that, or at
>> least reduce it to a warning instead of an error condition, but gtar
>> doesn't seem to have such a switch. You should try alternative backup
>> tools such as cpio or rsync.
> You mean the tar exits or that it just returns an error code on
> completion?
I don't recall whether it finishes making the tarball, but it definitely
returns nonzero exit status, which makes it effectively unusable in any
automated script (you certainly don't want to ignore exit status in a
backup script ...)
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly