Задание резервного копирования целый год каждую ночь завершалось зелёной галочкой. Потом выходит из строя СХД — или шифровальщик (ransomware) шифрует файловый сервер — и начинается восстановление. Выясняется, что копии хранились на NAS, который тоже зашифрован; последняя чистая копия — трёхнедельной давности; бухгалтерская база восстанавливается, но не запускается; а пароль от ключа шифрования резервных копий никто не записал.
Ни одна из этих проблем не экзотична. У них одна причина: резервное копирование настроили, а восстановление ни разу не проверяли. В статье — принципы, которые делают резервные копии устойчивыми, и практичный способ доказать, что они работают.
Резервная копия хороша настолько, насколько хорошо её последнее проверенное восстановление
Успешное задание резервного копирования доказывает, что данные куда-то скопированы. Оно не доказывает, что копия полная, согласованная, читаемая, доступна при отказе основных систем и восстанавливается за приемлемое для бизнеса время. Всё это доказывается только восстановлением — регулярным и в условиях, близких к реальному инциденту.
Правило 3-2-1 — и почему это минимум
Правило 3-2-1 — простая и широко принятая отправная точка:
- 3 копии данных: рабочие данные и как минимум две резервные копии.
- 2 разных типа хранения, чтобы один вид отказа — неисправный массив, ошибка прошивки — не повредил все копии.
- 1 копия вне объекта, чтобы пожар, затопление или кража в офисе не уничтожили всё.
- Всё чаще — ещё одна: как минимум одна копия офлайн или неизменяемая (immutable), чтобы шифровальщик с правами администратора не смог её удалить или зашифровать.
- И ноль непроверенных копий: целостность копий контролируется, восстановление тестируется.
Начинайте с RPO и RTO, а не с программного обеспечения
Все решения определяют два показателя. RPO (recovery point objective, целевая точка восстановления) — сколько данных бизнес может позволить себе потерять, в единицах времени: если копирование идёт раз в сутки, можно потерять до дня работы. RTO (recovery time objective, целевое время восстановления) — как долго система может быть недоступна, прежде чем ущерб станет неприемлемым.
Согласуйте их для каждой системы с теми, кто ею пользуется. Например, в гипотетическом офисе на 60 человек для общих документов может быть допустима потеря нескольких часов работы и день простоя, а бухгалтерской системе в конце месяца могут понадобиться ежечасные копии и восстановление за несколько часов. Именно эти цели — а не возможности конкретного продукта — определяют частоту копирования, места хранения копий и стоимость решения.
Что обычно не попадает в резервную копию
- Облачные и SaaS-данные: по условиям многих провайдеров резервное копирование почты и файлов в облачных сервисах — ответственность клиента.
- Базы данных, которые копируются как открытые файлы, а не методами, согласованными с приложением.
- Конфигурации межсетевых экранов, коммутаторов, контроллеров Wi-Fi и системы видеонаблюдения.
- Ноутбуки сотрудников, которые хранят файлы локально.
- То, что нужно для восстановления: ключи шифрования, пароли, файлы лицензий, установочные носители и документация о том, как собраны системы.
Как резервные копии подводят на практике
- Копии хранятся в той же сети и под теми же учётными записями, что и защищаемые системы, — и шифруются вместе с ними.
- Задания молча пропускают заблокированные или новые папки.
- Срок хранения слишком короткий, чтобы вернуться к моменту до заражения, которое неделями оставалось незамеченным.
- Копии вне объекта скачиваются по офисному интернету несколько дней.
- Восстановление зависит от одного человека — который как раз в отпуске.
Проверка восстановления: практичный график
Чтобы тестирование было полезным, оно не обязано быть тяжёлым. Хорошо работает многоуровневый подход — например:
- Регулярно, например ежемесячно: восстановите несколько случайных файлов и папок за разные даты и проверьте, что они открываются.
- Ежеквартально: восстановите целый сервер или виртуальную машину в изолированной среде и проверьте, что приложение действительно запускается, а данные актуальны.
- Не реже раза в год: полноценные учения по сценарию — основной объект или основное хранилище утрачены — по письменному плану восстановления и с теми людьми, которые будут делать это в реальности.
- После каждого крупного изменения: новая система, новое хранилище, новое ПО резервного копирования или изменения в сети.
Фиксируйте каждый тест: что восстанавливали, сколько времени это заняло в сравнении с RTO, какие проблемы возникли и что исправили. Со временем эти записи становятся честным ответом на вопрос: «Сколько мы на самом деле простоим?»
Ответственность должна быть явной
Резервные копии чаще всего теряются в промежутке между людьми: IT считает, что этим занимается поставщик ПО, поставщик — что клиент, а условия облачного провайдера говорят совсем другое. Запишите, кто отвечает за резервное копирование каждой системы, кто его контролирует и кто проверяет восстановление. Если копированием занимается внешний подрядчик в рамках IT-сопровождения, в объёме работ должно быть точно указано, какие системы охвачены и как отчитываются о тестах. Изоляция систем резервного копирования в отдельном сегменте сети — часть того же решения.
Хотите знать, восстановятся ли ваши резервные копии на самом деле? Свяжитесь с нами — поможем разобрать текущую схему и спланировать первую проверку восстановления.