Каковы стратегии резервного копирования и восстановления БД?

Что важно понять в первую очередь

Резервное копирование имеет смысл только вместе со сценарием восстановления. Можно бесконечно хранить бэкапы, но если вы никогда не проверяли restore, то в критический момент это может оказаться просто архивом с надеждой.

Базовые виды резервного копирования

• Full backup — полная копия базы или кластера на момент времени;

• Incremental backup — сохраняются только изменения с прошлого бэкапа;

• Differential backup — сохраняются изменения с момента последнего полного бэкапа;

• Logical backup — выгрузка на уровне объектов и данных, например через pg_dump или mysqldump;

• Physical backup — копирование файлов данных и WAL/redo‑логов на уровне файловой системы или storage.

Что обычно используют в PostgreSQL

Для PostgreSQL часто строят схему из:

• полных физических бэкапов;

• архивации WAL журналов, чтобы можно было восстановиться до конкретного момента времени (PITR — point-in-time recovery);

• периодических проверок восстановления на отдельном стенде.

RPO и RTO

• RPO (Recovery Point Objective) — сколько данных можно потерять максимум;

• RTO (Recovery Time Objective) — сколько времени можно восстанавливаться.

Чем ниже RPO и RTO, тем сложнее и дороже стратегия.

Практические варианты

• для небольших систем — ежедневный full backup + проверка восстановления;

• для важных OLTP-систем — full backup + WAL archiving + PITR;

• для больших объёмов — backup на уровне storage, репликация, snapshot‑подходы и отдельная схема проверки восстановления;

• для особо критичных систем — несколько независимых копий, в том числе offsite/air‑gapped.

Что обязательно проверять

• что бэкапы действительно создаются и не битые;

• что restore можно выполнить за целевое время;

• что восстановление работает на реальной версии СУБД и со всеми нужными расширениями;

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

Как ответить на собеседовании

Стратегия резервного копирования должна определяться целевыми RPO и RTO. На практике я бы сочетал полный бэкап, журналирование изменений вроде WAL и регулярные проверки восстановления, потому что backup без проверенного restore не считается надёжной стратегией. Для критичных систем ещё важно иметь несколько независимых копий и документированный runbook на случай аварии.