Developer

Бэкапы и восстановление: pg_dump, PITR, RPO и RTO

↑ 6.1 Масштабирование и надёжность данных · ← Предыдущая · → Следующая

Желательно~4 мин чтенияУровень: senior

Зачем это на собесе

Бэкап, который не восстанавливали, — не бэкап. Спрашивают виды, PITR и целевые показатели восстановления.

RPO и RTO

  • RPO (Recovery Point Objective) — допустимая потеря данных (сколько времени данных можем потерять): «не более 5 минут»;
  • RTO (Recovery Time Objective) — допустимое время восстановления сервиса: «не более 1 часа».

От них зависят стратегия бэкапов, репликация и бюджет. RPO ≈ 0 требует синхронной репликации/непрерывной архивации WAL; малый RTO — горячий резерв (реплика), автоматический failover.

Виды бэкапов PostgreSQL

ТипИнструментОсобенности
Логическийpg_dump / pg_dumpall / pg_restoreSQL или custom-формат; переносим между версиями; медленный на больших БД; снимок на момент начала
Физическийpg_basebackup, pgBackRest, Barman, WAL-Gкопия файлов кластера; быстрое восстановление; только та же major-версия
Непрерывная архивация WALarchive_command, pgBackRest, WAL-Gоснова PITR
Снимки ФС/дискаLVM, ZFS, облачные snapshotбыстро; нужно согласование (pg_backup_start/stop, атомарные снимки)
Репликаstreaming replicationне бэкап (см. ниже), но можно делать бэкап с реплики
# логический
pg_dump -Fc -j 4 -d app -f app_$(date +%F).dump          # custom format, параллельно
pg_restore -d app_restore -j 4 --clean --if-exists app_2026-09-30.dump
 
# физический
pg_basebackup -h primary -U replicator -D /backup/base -Fp -Xs -P -c fast

PITR (Point-In-Time Recovery)

Восстановление на любой момент времени: базовая копия + архив WAL → проигрываем журнал до нужной точки (например, за секунду до ошибочного DROP TABLE).

base backup (воскресенье) + WAL segments (непрерывно) ─▶ recovery_target_time = '2026-09-30 14:59:30'

Настройка:

# postgresql.conf
wal_level = replica
archive_mode = on
archive_command = 'pgbackrest --stanza=main archive-push %p'
 
# восстановление
restore_command = 'pgbackrest --stanza=main archive-get %f %p'
recovery_target_time = '2026-09-30 14:59:30'
recovery_target_action = 'promote'

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

Возможности pgBackRest: полные, дифференциальные, инкрементальные бэкапы, параллельность, сжатие, шифрование, хранение в S3, проверка целостности, restore --type=time.

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

3 копии данных, на 2 разных типах носителей, 1 вне площадки (другой регион/облако). Плюс неизменяемое хранилище (Object Lock) от шифровальщиков.

Политика

ПараметрПример
Полный бэкапраз в неделю
Инкрементальный/дифференциальныйежедневно
Архив WALнепрерывно (RPO = минуты/секунды)
Хранение7 дневных, 4 недельных, 12 месячных (по требованиям)
Шифрованиеда, ключи отдельно
Мониторингалерты на отсутствие бэкапа, архивации WAL, рост pg_stat_archiver.failed_count

Проверка восстановления

  • регулярные тесты восстановления (автоматически: поднять, проверить размер, выполнить контрольные запросы, сравнить счётчики) — и время восстановления как факт RTO;
  • документированный runbook: кто, что, в каком порядке;
  • учения (DR-drills);
  • проверка pg_verifybackup, контрольных сумм, pg_checksums (страницы данных).

Особенности

  • логический бэкап не содержит WAL, PITR невозможен;
  • бэкап большой БД с pg_dump держит снимок и долгую транзакцию (мешает VACUUM);
  • глобальные объекты (роли) не входят в pg_dump одной БД: pg_dumpall --globals-only;
  • восстановление с реплики возможно, но требует контроля лага;
  • консистентность между БД и объектным хранилищем/очередями — отдельная задача (см. связь метаданных).

Другие системы

БДБэкап
MySQLxtrabackup, binlog для PITR
MongoDBmongodump, снимки, oplog, Ops Manager / Atlas
ClickHouseBACKUP ... TO S3, clickhouse-backup, FREEZE
RedisRDB/AOF копии

Вопросы с ответами

Вид графа

Обратные ссылки