Резервное копирование и восстановление в PostgreSQL

[@seriyPS]

Тема очень интересная, но статья явно не полная. Добавили бы побольше примеров. Возможно, ссылки на документацию или какие-то похожие статьи.
По одному вашему описанию не разобраться, а вектор для дальнейшего изучения как то плохо задали.
Код мельком посмотрел — на своей базе без тщательного изучения не стал бы запускать.

[@lesovsky]

Наоборот старался сократить объем, в развернутом виде, как мне показалось, получилось слишком много текста и выглядит нудно (более подробно расписал пункты реализации).
скрипты да, требуют тщательного изучения т.к. при работе могут создать определенную нагрузку

[@DmitryKoterov]

Я вот в репликации постгреса никак не могу принять одну вещь: то, что на мастере в команде архивирования надо указывать путь к папке на реплике, чтобы мастер туда складывал wal-файлы на время активного pg_base_backup при первоначальной «наливке» реплики (когда идет rsync с мастера, например). Это ломает всю концепцию — мастер должен что-то знать о реплике (репликах).

Можно, конечно, и не настраивать архивирование; а просто увеличить кол-во хранимых «живых» wal-файлов и rsync-ать их уже после выполнения pg_stop_backup, но в этом случае увеличивается риск того, wal-файлы отротируются раньше, чем закончится rsync наливки реплики. Да и последующий rsync wal-файлов после pg_stop_backup будет лишнее время занимать, ведь начнут копироваться уже устаревшие wal-файлы (коих большинство).

Ну почему, почему они не сделали так, что после выполнения pg_start_backup можно было спокойно rsync-ать файлы базы без единого wal-файла, а wal-файлы сами бы потом подтягивались через протокол репликации? Это бы значительно упростило наливку реплики (которую приходится делать каждый раз, когда падает мастер, при условии, что реплик несколько, а не одна).

[@lesovsky]

>> на мастере в команде архивирования надо указывать путь к папке на реплике, чтобы мастер туда складывал wal-файлы на время активного pg_base_backup при первоначальной «наливке» реплики
Необязательно складывать архивы на реплику. Можно складывать локально, а потом на слейве указать restore_command = 'scp user@master:/path/to/archive/%f "%p"'. Пусть берет их по сети.

[@DmitryKoterov]

Но все равно получается, что от реплики к мастеру 2 способа передачи данных идет: через replication protocol и через ssh. Некрасиво это…

[@Imbolc]

> Однако этот вариант не предлагает восстановить каталог базы данных на момент предшествующий сбою, алишь на момент выполнения бэкапа.

Если речь о некорректных миграциях, то достаточно делать бэкапы непосредственно перед ними, а не (только) по крону.

[@AnnInDark]

Потери производительности большие, если перед каждой миграцией делать бэкап.

[@lesovsky]

то достаточно делать бэкапы непосредственно перед ними

да, можно дергать DBA «эй, сделай-ка нам дамп», но я за автоматизацию)))

[@440hz]

эх… мне бы ваш оптимизм…

на базах размером в несколько тер, с тысячами схем и миллионами файлов в каталогах, под нагрузкой, все не так уж и радужно.

[@440hz]

кто-то мне в аську стукнулся, но антиспам заблокировал.

[@lesovsky]

это я))) мы пару лет назад общались по аське на тему постгреса… у меня контакт до сих пор сохранился)))

[@sergeyfast]

Для фанатов — вышла недавно книжкаhow-to на 40 страниц Instant PostgreSQL Backup and Restore How-to. В ней подробно описываются все возможные способы бэкапа и восстановления из него со всеми плюсами и минусами.

[@le0pard]

postgresql.leopard.in.ua/ — 10 глава. На проектах я использую часто wal-e, при этом настроены slave сервера, что читают не с мастера, а с s3 бекапов.