Бэкапы PostgreSQL и восстановление

ОБЯЗАТЕЛЬНО

Инженеру

Раздел 8.11, шаг 10 из 12. Дальше — профилирование.

---

Стратегия 3-2-1

• 3 копии данных;
• 2 разных носителя/среды;
• 1 offsite (другой ДЦ/регион).

Бэкап в том же S3-bucket без versioning и без другого региона не offsite. Урок инцидентов — когда snapshot и primary сгорели в одном здании (раздел 8 — о инфраструктуре).

---

Логический бэкап — pg_dump

pg_dump -U app -Fc -f app_$(date +%F).dump appdb
pg_restore -U app -d appdb_restored -j 4 app_2025-05-31.dump

Формат	Плюсы
Custom -Fc	Параллельный restore, сжатие
Directory -Fd	Параллельный dump/restore
Plain SQL	Читаемость, медленнее

Подходит для миграций, отдельных схем, downgrade/upgrade с тестом. На multi-TB — долго; для больших объёмов — physical + WAL.

Базовый уровень — 3.07/106.

---

Физический бэкап и PITR

Physical backup — копия каталога данных + непрерывный архив WAL.

archive_mode = on
archive_command = 'test ! -f /wal_archive/%f && cp %p /wal_archive/%f'
# production — wal-g wal-push или pgBackRest

Point-in-Time Recovery (PITR) — восстановление на момент до ошибочного DROP TABLE:

1. restore base backup;
2. создать recovery.signal (PG 12+);
3. указать recovery_target_time в postgresql.conf;
4. Postgres проигрывает WAL до target и останавливается.

restore_command = 'cp /wal_archive/%f %p'
recovery_target_time = '2025-05-30 14:32:00+03'
recovery_target_action = 'promote'

---

pg_probackup

pg_probackup (Postgres Professional) — physical backup с incremental, catalog, validate.

pg_probackup init -B /backups
pg_probackup add-instance -B /backups --instance=main -D /var/lib/postgresql/data
pg_probackup backup -B /backups --instance=main -b FULL
pg_probackup backup -B /backups --instance=main -b DELTA
pg_probackup restore -B /backups --instance=main -D /pgdata_restored

Плюсы — знакомый стек в РФ, интеграция с Postgres Pro. Минусы — отдельный инструмент, обучение команды.

---

Wal-G

Wal-G — open-source, cloud-native backup в S3, GCS, Azure Blob.

export WALG_S3_PREFIX=s3://mybucket/pg-backups
export AWS_REGION=eu-central-1

wal-g backup-push /var/lib/postgresql/data
wal-g backup-list
wal-g backup-fetch /var/lib/postgresql/data LATEST

Continuous archiving:

archive_command = 'wal-g wal-push %p'

Restore в новый инстанс + recovery_target_timeline — типовой DR runbook в Kubernetes (CloudNativePG + Barman/Wal-G).

	pg_probackup	Wal-G
Хранилище	FS, локально	Object storage
Incremental	Да	Да (delta)
Экосистема K8s	Средняя	Сильная

---

Тестирование восстановления

Бэкап без проверенного restore — надежда, не стратегия.

Частота	Действие
Еженедельно	Restore на staging, pg_checksum verify
Ежеквартально	PITR drill на случайное время
После major upgrade	Full restore test

Checklist restore:

1. RTO/RPO — сколько downtime и сколько WAL допустимо потерять?
2. Документированные команды и роли.
3. Отдельная сеть/secrets для restore env.

---

Бэкап в Kubernetes

• Volume snapshot (CSI) — быстро, но crash-consistent без freeze; лучше с preStop hook или operator backup.
• Operator backup — logical/physical через sidecar, upload S3.
• Не полагайтесь только на kubectl cp running pod.

---

После failover

Новый primary продолжает WAL chain. Старые base backup привязаны к timeline — после promote проверьте pg_controldata и timeline history.

---

Практика

1. pg_dump -Fc учебной БД, restore в новую БД, сравните row counts.
2. Настройте Wal-G в MinIO (S3-compatible), full backup + delete random table + PITR.
3. Запишите runbook restore на 1 страницу для команды.

---

Связанные материалы

• Восстановление данных — sysadmin
• Резервное копирование SQL
• phpPgAdmin — дампы и импорт
• Забота о данных — Git
• Справочник PostgreSQL

---