Как спроектировать стратегию бэкапов для базы данных с требованием RPO = 5 минут при объёме 2 ТБ?

Короткий ответ

Полные бэкапы 2 ТБ каждые 5 минут нереалистичны; нужна комбинация редких полных бэкапов (например, ежедневных), инкрементальных/дифференциальных бэкапов и непрерывного журналирования транзакций (WAL/binlog) с архивированием, что позволяет сделать point-in-time recovery с точностью до нескольких минут.

Как это работает подробнее

полный бэкап фиксирует состояние на момент снятия и занимает много времени/места при 2 ТБ; журнал транзакций (write-ahead log) непрерывно записывает каждое изменение и может архивироваться каждые несколько минут или потоково передаваться. Восстановление происходит так: разворачивается последний полный бэкап, затем поверх накатываются инкременты и журнал транзакций до нужной точки времени.

Пример / кейс

Ожидаемое поведение: `archive_timeout = 300` гарантирует, что даже при низкой нагрузке WAL-файл будет заархивирован не реже чем раз в 5 минут, что совместно с ежедневным полным бэкапом даёт RPO около 5 минут; проверяется через `pg_stat_archiver` и метрику lag архивирования.

Пример кода

example.shКопировать

# Пример архивации WAL в PostgreSQL для PITR (упрощённо, postgresql.conf)
archive_mode = on
archive_command = 'aws s3 cp %p s3://backups/wal/%f'
archive_timeout = 300  # форсировать переключение WAL-файла не реже раза в 5 минут

Что использовать на практике

• Практический подход. Нужно тестировать реальное время восстановления полного бэкапа 2 ТБ (это часто больше часа) — это RTO, и оно может не укладываться в бизнес-требования, даже если RPO соблюдён. Также важно архивировать журнал транзакций в отдельное хранилище с низкой задержкой и проверять, что архивирование не отстаёт от генерации журнала (lag).

Подводные камни

• Частые ошибки. Считать, что ежедневный полный бэкап даёт RPO 5 минут — это не так, пропадут все изменения с момента последнего бэкапа; не мониторить lag архивирования журнала транзакций, из-за чего во время сбоя выясняется, что последние 2 часа изменений не заархивированы; не учитывать стоимость хранения большого объёма бэкапов и журналов при ретенции.