Using pg_start_backup() and pg_stop_backup()

From: David B Harris <dbharris(at)eelf(dot)ddts(dot)net>
To: pgsql-general(at)postgresql(dot)org
Subject: Using pg_start_backup() and pg_stop_backup()
Date: 2013-07-16 14:10:28
Message-ID: 20130716141028.GG15448@valiant.tachsys.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Good afternoon all,

I'm trying to use pg_start_backup() and pg_stop_backup() to create
point-in-time backups. More specifically, I'm trying to use filesystem
tools (notably rsync or an rsync-like tool) since the production machine
is on the other end of a (narrow, expensive) pipe. pg_dump is too
expensive (both in time and bandwidth); the gzip-compressed database
dump is about 30GB.

These backups might be maintained/used by others who are only somewhat
familiar with Linux and PostgreSQL, so I'm trying to keep them as simple
as possible.

Now if I read it right (and I'm concerned I'm not), then according to
section 24.3 of the documentation (Continuous Archiving and
Point-in-Time Recovery (PITR)), the backup procedure needs to be as
follows:

1. Issue pg_start_backup('label')
2. Perform rsync of cluster directory
3. Issue pg_stop_backup()
4. Copy all logs from start of pg_start_backup() through to when
pg_stop_backup() finished (using the backup history file, I
guess, which I haven't actually been able to find yet :)

So far enough. Before I really grasped that, though, I was testing with
just steps #1 through #3. And everything always seemed to work fine.
Ultimately I tested it dozens of times. With various loads on the
production server (certainly at times with more than enough writes to
max out the number of allowed log segments). And the restore never
failed (no errors at least, and spot-checking the data indicated that
everything appeared to be in place).

Am I on drugs? Just crazy lucky? Is #4 actually necessary? (I can
imagine ways of writing to the cluster files which might make it
unnecessary, maybe somebody implemented that and didn't update the
documentation?)

Thanks very much in advance,

David

--
Arguing with an engineer is like wrestling with a pig in mud.
After a while, you realise the pig is enjoying it.

OpenPGP v4 key ID: 4096R/59DDCB9F
Fingerprint: CC53 F124 35C0 7BC2 58FE 7A3C 157D DFD9 59DD CB9F
Retrieve from subkeys.pgp.net

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Muhammad Bashir Al-Noimi 2013-07-16 15:08:03 Upgrading from Pg 9.1 to 9.2
Previous Message AI Rumman 2013-07-16 13:22:05 Re: last_vacuum field is not updating