Как делать инкрементное резервное копирование каждый час в Postgres?

Попытка сделать почасовое инкрементное резервное копирование одного сервера Postgres (Win7 64).

У меня есть следующие настройки в postgresql.conf:

max_wal_senders = 2
wal_level       = archive
archive_mode    = on
archive_command = 'copy "%p" "c:\\postgres\\foo\\%f"'

(начать сначала)

Я сделал базовое резервное копирование с pg_basebackup -U postgres -D ..\foo -F t -x

Это сделало большой base.tarфайл в fooпапке и добавило около 16384 КБ файлов, которые, я полагаю, являются WAL.

Чего я не понимаю, так это почему WAL fooне меняются . WALS в data/pg_xlogизменении. Разве pg не должен копировать их? Как он решает это сделать?

Возможно, мне нужно установить archive_timeout=3600?

Я видел несколько сайтов (списки рассылки pg, страница postgres bacula), на которых написано, что вам нужно вызывать pg_start_backup () и pg_stop_backup (), но я считаю, что они не обязательны. Это правда?

Дополнительные вопросы:

Как часто data/pg_xlogзаписываются WAL ? Что вызывает запись?

Кажется, чтобы обновить WAL, если я делаю некоторые DML, то \qв psql. Или отредактируйте таблицу в pgAdmin, затем закройте окно. Я полагал, что это напишет на коммите.
Лучшие практики? pg_basebackup раз в неделю? Архивировать WAL на той же машине, что и PG, или на удаленной машине?

— Нил Макгиган
источник

Ответы:

Вы хотите сделать инкрементное резервное копирование архивной папки в удаленное хранилище.

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

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

— Даниэль Верите
источник

Благодарю. Несколько вопросов: 1. Должен ли я сделать pg_start_backup (), скопировать данные, затем запустить pg_stop_backup () или pg_start_backup (); pg_stop_backup (), затем скопировать?

— Нил Макгиган

@Neil: 1. и 2. не применяются, когда вы используете pg_basebackup, это уже позаботится об этом. 3. postgres автоматически удалит файлы WAL, pg_logкогда они больше не нужны. Вы не должны ничего делать вручную pg_log. В противном случае смотрите wal_keep_segmentsпараметр

— Даниэль Vérité

под папкой «архив» вы подразумеваете pg_xlog, да?

— Нил Макгиган

@NeilMcGuigan: совсем нет. Папка архива является папкой назначения вашей команды архива, например, здесь "c: \ postgres \ foo". pg_xlogполностью управляется автоматически postgres, тогда как папка архива полностью управляется администратором базы данных.

— Даниэль Верите

Я думаю, я запутался, потому что WALs в foo никогда не меняются после первоначального pg_basebackup

— Нил МакГиган,

Существует существующий инструмент, который вам очень поможет, WAL-E . Это обеспечивает archive_commandи restore_commandдля PITR к S3.

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

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

Кроме того, PgBarman поддерживает интеграцию с S3 через подключаемые скрипты и автоматизирует большую часть ротации и управления резервными копиями для вас. Опять же, это может быть не вариант на Windows.

— Крейг Рингер
источник