Резервное копирование и отказоустойчивость инфраструктуры
Как защитить бизнес от простоя и потери данных: резервное копирование, отказоустойчивость, RPO, RTO, SLA и проверка восстановления.
Содержание
Даже короткий простой инфраструктуры может остановить продажи, расчёты или обслуживание клиентов. Разберём, чем отличается резервное копирование от отказоустойчивости и как выстроить инфраструктуру, которая переживёт сбой.
Резервное копирование и отказоустойчивость — не одно и то же
Это две разные задачи, которые часто путают:
- Резервное копирование (backup) защищает от потери данных: у вас есть копия, которую можно восстановить.
- Отказоустойчивость (fault tolerance) защищает от простоя: система продолжает работать, даже если часть компонентов отказала.
Одно не заменяет другое. Backup без отказоустойчивости — это восстановление после простоя, а не его отсутствие.
Ключевые метрики: RPO и RTO
Две метрики определяют требования к надёжности:
- RPO (Recovery Point Objective) — сколько данных вы готовы потерять (например, за последний час).
- RTO (Recovery Time Objective) — как быстро система должна восстановиться.
Чем ниже допустимые RPO и RTO, тем дороже инфраструктура. Задача — найти баланс под реальные потребности бизнеса.
Принципы надёжной инфраструктуры
- Регулярные автоматические бэкапы с проверкой восстановления.
- Хранение копий отдельно от основной системы.
- Резервирование критичных компонентов (питание, каналы, серверы).
- Мониторинг и оповещения об инцидентах.
- Регламент восстановления, проверенный на практике.
Для резервных копий полезен принцип 3-2-1-1-0: минимум три экземпляра данных, два типа носителей, одна копия вне основной площадки, одна неизменяемая или изолированная копия и ноль необнаруженных ошибок после проверки. Изолированная копия особенно важна при атаке шифровальщика: если хранилище доступно из того же административного контура, вредоносное ПО может повредить и production, и backup.
Полные, инкрементальные и дифференциальные копии решают разные задачи. Их сочетание выбирают по объёму данных, окну копирования и допустимому времени восстановления. Варианты размещения и распределение ответственности рассмотрены в сравнении IaaS и собственного дата-центра.
Роль SLA
SLA (Service Level Agreement) фиксирует гарантии провайдера по доступности — например, 99,99%. Это не маркетинг, а обязательство: уточняйте, что именно покрывает SLA и какова компенсация при его нарушении.
Типичная ошибка
Самая частая ошибка — бэкапы, которые никто ни разу не восстанавливал. Копия, из которой нельзя восстановиться, бесполезна. Проверка восстановления должна быть регулярной процедурой, а не действием в момент аварии.
Вывод
Надёжность — это сочетание резервного копирования и отказоустойчивости, подкреплённое понятными RPO, RTO и SLA. Провайдер отвечает только за согласованную часть контура: резервирование приложений, права доступа и проверка восстановления нередко остаются на стороне заказчика.
Минимальный тест готовности
Проведите учебное восстановление отдельного сервиса, измерьте фактические RPO и RTO, зафиксируйте владельца каждого действия и повторяйте тест по расписанию. Для построения плана восстановления можно использовать NIST SP 800-34 Rev. 1 как структурный ориентир, адаптируя его к российским требованиям и вашей архитектуре.
Частоту тестов определяйте по критичности системы и темпу изменений. После миграции, обновления платформы, смены схемы доступа или серьёзного инцидента нужен внеплановый тест. Для регулируемых контуров дополнительно сверяйте резервирование и журналы с моделью угроз и применимыми требованиями ФСТЭК.
