Решение: какая стратегия бэкапа?
Стратегия бэкапа выбирается балансом трёх факторов: какую потерю данных вы можете допустить (RPO), объёма данных и того, как быстро нужно восстановиться (RTO). Ни один метод не подходит для всех сценариев. Исходя из цели RPO, это дерево ведёт к выбору между логическими дампами, физическими бэкапами + PITR и снимками и напоминает, что 3-2-1 и проверка не обсуждаются.
Какова цель по потере данных (RPO)?
Начните с самого определяющего ограничения: данные за сколько минут/часов вы можете позволить себе потерять при аварии? Если требуется потеря, близкая к нулю, непрерывное архивирование журналов (PITR) обязательно; если допустимы ежедневные/еженедельные бэкапы, достаточно более простых методов. RPO задаёт рамки стратегии.
- Почти ноль — нужно иметь возможность вернуться к любому моменту времени
- Ежедневные/периодические бэкапы (потеря нескольких часов) допустимы
- Сначала напомните общие лучшие практики (3-2-1 / проверка)
Каковы объём данных и требования к переносимости?
Если периодических бэкапов достаточно, следующий вопрос — масштаб и назначение: база данных небольшая/средняя и вы хотите, чтобы бэкап переносился в другую среду/версию, или данные большие и главное — вернуться в строй за минуты? Это определяет выбор между логическим дампом и снимком.
- Небольшой/средний объём, переносимость и совместимость между версиями
- Большие данные, восстановление должно быть очень быстрым (низкий RTO)
Рекомендация: логический дамп
Выгружает данные на логическом уровне (определения схемы + строки); результат — SQL/текст (pg_dump plain format, mysqldump) или специфичный для инструмента двоичный дамп (pg_dump -Fc, Oracle Data Pump). Гибкий и переносимый метод для небольших и средних БД, миграций, обновлений версий и восстановления выбранных таблиц/объектов.
Рекомендация: физический бэкап + WAL/архивные журналы (PITR)
Вы регулярно делаете физические базовые бэкапы и непрерывно архивируете журналы транзакций (WAL/redo/binlog). Это позволяет выполнить восстановление на момент времени (Point-in-Time Recovery) к любой точке и свести потерю данных почти к нулю.
Рекомендация: снимок (snapshot)
Создаёт снимок данных на уровне блоков на уровне хранения или виртуализации. Бэкап и восстановление очень быстры даже для очень больших БД; однако метод зависит от инфраструктуры и требует аккуратного использования.
Рекомендация: правило 3-2-1 + внешняя площадка + обязательная проверка
Какой бы метод вы ни выбрали, эти принципы должны стоять поверх стратегии. Самого наличия бэкапа недостаточно: он должен быть на разных носителях, в другом месте и регулярно проверяться. Это рамка, дополняющая все варианты выше.