Backup и restore — что должен знать разработчик

Два класса: логический (pg_dump SQL-дамп, гранулярность) и физический (pg_basebackup, весь кластер, PITR). pg_dump -Fc + pg_restore -j 4 parallel. Прод физический + WAL archive для PITR (recovery_target_time). Retention: daily 7d + weekly 4w + monthly 12m. Backup всегда в отдельном хранилище. Тестировать restore. При катастрофе: STOP → DBA → current state → PITR. Раскрытие PG-BK-001..PG-BK-084.

Опубликовано 9 мая 2026 обновлено 9 июня 2026 ~3 мин чтения Автор: Вадим Викулин

Опирается на правила: PG-BK-001 … PG-BK-084 из PostgreSQL Style Guide → раздел Backup и restore.

Важно знать

DBA настраивает стратегию, разработчику достаточно базы.

Два класса: логический (pg_dump) и физический (pg_basebackup).

pg_dump -Fc — custom format, parallel restore через pg_restore -j 4.

Прод обычно физический + WAL archive (для PITR).

pg_dumpall --globals-only для ролей и tablespaces.

PITR — base backup + WAL archive + recovery_target_time.

Backup ВСЕГДА в отдельном хранилище — локальный не backup.

Backup тестируется restore-ом регулярно.

При катастрофе: STOP → DBA → current state backup → PITR.

Дамп прода разработчику обязательно с анонимизацией PII.

DBA настраивает backup-стратегию. Разработчику достаточно понимать минимум.

Два класса backup

PG-BK-001..003:

	Логический (`pg_dump`)	Физический (`pg_basebackup`)
Гранулярность	таблицы, схемы, БД	весь кластер
Размер	компактно (без bloat)	как на диске
Скорость backup	медленно	быстро (copy)
Скорость restore	медленно (parsing SQL)	быстро (copy)
Кросс-версия PG	да (совместимость)	нет (only same major)
PITR	нет	да + WAL archive
Для	дебаг, миграция между версиями	прод-backup, replica setup

Прод обычно использует физический + WAL archive (для PITR). Логические дампы — для разработчика и одноразовых задач.

pg_dump

PG-BK-010..013:

Базовый

pg_dump -U user -h host mydb > mydb.sql
psql -U user -h host mydb_new < mydb.sql

Custom format (рекомендуется)

pg_dump -Fc -U user -h host mydb > mydb.dump
pg_restore -j 4 -d mydb_new mydb.dump   # 4 параллельных worker'а

Компактнее, parallel restore.

Полезные флаги

pg_dump --schema=public
pg_dump --table=order_doc           # только одна таблица
pg_dump --schema-only               # только структура
pg_dump --data-only                 # только данные
pg_dump --exclude-table=audit_log
pg_dump --no-owner --no-acl         # для restore в другой кластер

pg_dumpall

pg_dumpall --globals-only > globals.sql   # роли, tablespaces, settings
pg_dump mydb > mydb.sql

Восстановить локально

PG-BK-020..021: типичный сценарий «у клиента баг, нужен дамп для отладки».

createdb -U postgres customer_debug
pg_restore -d customer_debug -j 4 customer-prod-2026-05-01.dump
psql customer_debug

Анонимизация перед передачей разработчику — обязательна для PII. См. Дамп прода для разработчика — анонимизация.

pg_basebackup

PG-BK-030..031: физический.

pg_basebackup -U replicator -h master -D /backup/2026-05-07 -Ft -z -P

-Ft — tar.
-z — gzip.
-P — progress.

Создаёт snapshot всего кластера. Для прода, replica setup, restore.

Restore — распаковать в data_directory + старт PG. Версия PG должна совпадать.

PITR

PG-BK-040..042: Point-In-Time Recovery.

= базовый physical backup + непрерывный WAL archive.

На мастере:

archive_mode = on
archive_command = 'rsync %p backup-host:/wal-archive/%f'

Restore на конкретный момент:

# recovery.signal в data_directory + postgresql.conf:
restore_command = 'rsync backup-host:/wal-archive/%f %p'
recovery_target_time = '2026-05-07 14:23:00 MSK'

PG восстановит base backup, проиграет WAL до момента.

То, что нужно после катастрофы («откатились в 14:23, до удаления заказов»). DBA-операция.

Стратегия retention

PG-BK-050..052: типичная DBA-зона.

Daily — 7 дней.
Weekly — 4 недели.
Monthly — 12 месяцев.
Continuous WAL — всегда последние 7 дней.

Все backup в отдельном (от прода) хранилище — S3, NAS, Glacier. Локальный backup на той же машине — не backup.

Backup тестируется restore-ом раз в N дней. «Backup, который не проверяли — ничей не backup.»

Backup для multi-tenant

PG-BK-060..062:

Row-per-tenant — backup всей БД, фильтр в pg_dump --table или COPY ... WHERE tenant_id.
Schema-per-tenant — pg_dump --schema=tenant_X, гранулярность лучше.
DB-per-tenant — каждая БД свой backup-расписание.

Когда «всё сломалось»

PG-BK-070..071: алгоритм.

STOP — не делай изменений. Каждый INSERT после катастрофы усложняет.
Зови DBA (или владельца проекта).
Backup current state перед восстановлением.
PITR на момент ДО проблемы — если есть архив WAL.
Если PITR нет — последний нормальный backup + ручное восстановление.

«Удалили таблицу» != «потеряли данные». Сначала проверь pg_stat_activity — не висит ли DDL в открытой TX. Если транзакция ещё открыта — ROLLBACK восстановит.

Что запрещено

Антипаттерн	Правило	Что взамен
`pg_dump` без WAL archive	`PG-BK-080`	PITR через WAL archive
Backup на той же машине	`PG-BK-081`	отдельное хранилище (S3, NAS)
Backup без проверки restore	`PG-BK-082`	regular test-restore
Дамп прода без анонимизации	`PG-BK-083`	GDPR / 152-ФЗ
`pg_dump --inserts` для big DB	`PG-BK-084`	default COPY (10x быстрее)
Restore в другую major-версию	`PG-BK-031`	pg_dump для cross-version
Хранение только daily без monthly	`PG-BK-050`	retention 7d + 4w + 12m

Куда дальше

PG → Backup и restore — нормативные формулировки.
WAL — WAL archive для PITR.
Репликация — pg_basebackup для replica.
Дамп прода — анонимизация — PII перед передачей.
Расширения — postgresql_anonymizer.
Multi-tenancy — backup per-tenant.