Re: PostgreSQL Backup Strategies

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: PostgreSQL Backup Strategies
Дата
Msg-id 20180222115940.GE2416@tamriel.snowman.net
обсуждение исходный текст
Ответ на RE: PostgreSQL Backup Strategies  (Alvaro Aguayo Garcia-Rada <aaguayo@opensysperu.com>)
Список pgsql-admin
Greetings,

* Alvaro Aguayo Garcia-Rada (aaguayo@opensysperu.com) wrote:
> Sorry I have no book to recommend, but my recommendation will always pass through pg_basebackup, which will perform a
fullbackup of you running database without needing to stop anything, and will also(with adequate args) add all
transactiinscommitted zuring the backup to the backup itself.
 

Note that you *must* ensure that the write-ahead-log / xlog is captured
for the duration of the backup, regardless of how you do the backup.
The above seems to imply that you only need to if you want the
transactions committed during the backup- that is *not* the case, you
need the WAL to have a *consistent* backup.  Without the WAL, the backup
isn't consistent and isn't valid and therefore can't be used.

> I do myself use pg_basebackup and a simple shellscript to do automated backups of a production system.

pg_basebackup with the --xlog or --wal option is a good way to get a
snapshot of a running database.  You can also use archive_command or
pg_receivexlog / pg_receivewal to collect the WAL but then you have to
verify that you have all of the WAL generated during the backup.

> I've also heard about pgbarman, but have no knowledge on it.

For doing file-based backups of PG, you should definitely be using an
existing well maintained PG backup implementation, such as pgBackRest,
barman, or perhaps WAL-E/WAL-G.  These have, literally, years of
development resources put into them to make sure that the backups taken
are consistent and valid (though you should also, always, be testing
your backups).  Unless you're planning to invest serious time
understanding all of the details involved in taking a backup of PG, I'd
strongly recommend you use an existing solution.

If you're looking for logical backups, there's also pg_dump, of course,
but you can't do point-in-time-recovery with pg_dump in the same way you
can with a file-based backup, and restore time is longer as indexes have
to be rebuilt and constraints re-checked with pg_dump.

Thanks!

Stephen

Вложения

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

Предыдущее
От: Joan Luc Labòrda
Дата:
Сообщение: Re: Postgres user password
Следующее
От: Evan Rempel
Дата:
Сообщение: Re: PostgreSQL Backup Strategies