Using pg_start_backup() and pg_stop_backup()

Поиск
Список
Период
Сортировка
От David B Harris
Тема Using pg_start_backup() and pg_stop_backup()
Дата
Msg-id 20130716141028.GG15448@valiant.tachsys.net
обсуждение исходный текст
Ответы Re: Using pg_start_backup() and pg_stop_backup()  (Michael Paquier <michael.paquier@gmail.com>)
Список 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



В списке pgsql-general по дате отправления:

Предыдущее
От: AI Rumman
Дата:
Сообщение: Re: last_vacuum field is not updating
Следующее
От: Muhammad Bashir Al-Noimi
Дата:
Сообщение: Upgrading from Pg 9.1 to 9.2