DBA настраивает backup-стратегию. Разработчику обычно достаточно понимать: какие типы backup'ов бывают, как восстановить локальный дамп для дебага, что говорить, когда нужен restore прода. Эта статья — этот минимум.
Правила пронумерованы кодами PG-BK-NNN.
1. Два класса backup
PG-BK-001 — Логический backup
— SQL-дамп через pg_dump. Данные как INSERT/COPY-команды, читаемо.
PG-BK-002 — Физический backup
— копия файлов кластера через pg_basebackup. Бинарный snapshot.
Логический (pg_dump) | Физический (pg_basebackup) | |
|---|---|---|
| Гранулярность | таблицы, схемы, БД | весь кластер |
| Размер | компактно (без bloat) | как на диске (с bloat) |
| Скорость backup | медленно | быстро (просто copy) |
| Скорость restore | медленно (parsing SQL) | быстро (просто copy) |
| Кросс-версия PG | да (есть совместимость) | нет (только same major) |
| PITR | нет | да + WAL archive |
| Подходит для | дебаг, миграция между версиями, cherry-pick данных | прод-backup, replica setup |
PG-BK-003 — Прод обычно использует физический + WAL archive (для PITR)
Логические дампы — для разработчика и одноразовых задач.
2. pg_dump — логический backup
PG-BK-010 — Базовый дамп БД:
pg_dump -U user -h host -p 5432 mydb > mydb.sql
Создаст файл с DDL + INSERT'ами. Восстановление:
psql -U user -h host -p 5432 mydb_new < mydb.sql
PG-BK-011 — Custom format (рекомендуется) — компактнее, парallel restore:
pg_dump -Fc -U user -h host mydb > mydb.dump
# restore
pg_restore -j 4 -d mydb_new mydb.dump # 4 параллельных worker'а
PG-BK-012 — Полезные флаги:
pg_dump --schema=public # только одна схема
pg_dump --table=order_doc # только одна таблица (с внешними FK — осторожно)
pg_dump --schema-only # только структура без данных
pg_dump --data-only # только данные без структуры
pg_dump --exclude-table=audit_log # исключить таблицу
pg_dump --no-owner --no-acl # без владельца и прав (для restore в другой кластер)
PG-BK-013 — pg_dumpall — для глобальных объектов
(роли, tablespaces, настройки). Дополняет pg_dump:
pg_dumpall --globals-only > globals.sql
pg_dump mydb > mydb.sql
3. Восстановить локально для дебага
PG-BK-020 — Типичный сценарий: «у клиента баг, нужен дамп для отладки»
DBA отдаёт customer-prod-2026-05-01.dump. Разработчик:
# создать пустую локальную БД
createdb -U postgres customer_debug
# восстановить
pg_restore -d customer_debug -j 4 customer-prod-2026-05-01.dump
# подключиться
psql customer_debug
PG-BK-021 — Анонимизация перед передачей дампа разработчику
— обязательна для PII. См. отдельную статью Анонимизация дампов.
4. pg_basebackup — физический backup
PG-BK-030 — Базовая команда:
pg_basebackup -U replicator -h master-host -D /backup/2026-05-07 -Ft -z -P
# -Ft — tar формат
# -z — gzip сжатие
# -P — progress
Создаёт snapshot всего кластера. Используется для:
- Бэкапа прода (вместе с WAL archive — PITR).
- Создания новой реплики.
- Полного restore кластера.
PG-BK-031 — Restore — распаковать архив в data_directory и стартовать PG
Версия PG должна совпадать.
5. PITR — Point-In-Time Recovery
PG-BK-040 — PITR = базовый physical backup + непрерывный WAL archive
Можно восстановить кластер на любой момент времени между backup и текущим.
Конфигурация на мастере:
# postgresql.conf
archive_mode = on
archive_command = 'rsync %p backup-host:/wal-archive/%f'
PG-BK-041 — Restore на конкретный момент
(restore.signal + recovery_target_time):
# 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 до указанного момента.
PG-BK-042 — PITR — то, что нужно после катастрофы
: «откатились в 14:23, до удаления заказов». DBA-операция, разработчик обычно лишь ставит запрос.
6. Стратегия retention на проде
PG-BK-050 — Типичная стратегия (DBA-зона):
- Daily full backup, retention 7 дней.
- Weekly full backup, retention 4 недели.
- Monthly full backup, retention 12 месяцев.
- Continuous WAL archive — всегда последние 7 дней.
PG-BK-051 — Все backup'ы хранятся в отдельном (от прода) хранилище
— S3, NAS, Glacier. Локальный backup на той же машине — не backup.
PG-BK-052 — Backup тестируется restore'ом раз в N дней
«Backup, который не проверяли — ничей не backup.» DBA организует test-restore процедуру, разработчик может быть втянут для валидации содержимого.
7. Backup для multi-tenant
PG-BK-060 — Row-per-tenant — backup всей БД, restore тоже всей
Чтобы вытащить данные одного тенанта — фильтр в pg_dump --table или COPY ... TO ... WHERE tenant_id = ?.
PG-BK-061 — Schema-per-tenant — pg_dump --schema=tenant_X
, гранулярность лучше.
PG-BK-062 — DB-per-tenant — каждая БД свой backup-расписание
Удобно, но операционно дороже.
8. Что делать когда «всё сломалось»
PG-BK-070 — Алгоритм:
- STOP — не делай больше изменений. Каждый INSERT после катастрофы усложняет восстановление.
- Зови DBA. Если ты разработчик и нет DBA — позови владельца проекта.
- Backup current state, прежде чем восстанавливать. Catastrophe recovery должна быть обратимой.
- PITR на момент ДО проблемы, если есть архив WAL.
- Если PITR нет — последний нормальный backup + ручное восстановление потерянных данных.
PG-BK-071 — «Удалили таблицу» != «потеряли данные»
Сначала останови все приложения, проверь, не висит ли DDL в транзакции (pg_stat_activity). Если транзакция ещё открыта — ROLLBACK восстановит. Только после этого переходи к restore.
9. Антипаттерны
PG-BK-080 pg_dump плана А, без WAL archive — нет PITR, потеряешь всё между ночными backup'ами.
PG-BK-081 Backup на той же машине — не backup. Диск помрёт — backup умрёт с ним.
PG-BK-082 Backup без проверки restore — обнаружишь, что backup битый, в момент когда нужен.
PG-BK-083 Дамп прода передан разработчику без анонимизации PII — нарушение GDPR / 152-ФЗ.
PG-BK-084 pg_dump --inserts для big DB — INSERT работает в 10x медленнее COPY (default).
Чек-лист (что разработчик должен иметь)
- [ ] Понимает, как восстановить дамп локально (
pg_restore -j 4 -d ... file.dump). - [ ] Знает, у кого/где запросить дамп прода (DBA / runbook).
- [ ] Понимает, что дамп прода нужно анонимизировать (или брать из staging).
- [ ] При сбое — не делает rollback/изменения, зовёт DBA.
Чек-лист (что DBA должен обеспечить)
- [ ] Daily/weekly/monthly backup со разной retention.
- [ ] WAL archive для PITR.
- [ ] Backup в отдельном от прода хранилище (S3 / NAS).
- [ ] Test-restore раз в N дней с подтверждением.
- [ ] Анонимизация для дампов разработчикам.
- [ ] Документированный runbook на restore catastrophe.
Связанные
- Анонимизация дампов — обязательная подготовка для разработчика.
- WAL — основа PITR.
- Multi-tenancy — backup стратегия per-tenant.