Резервная копия нужна не для самого факта хранения, а для восстановления работы после удаления файлов, сбоя оборудования, шифрования или ошибки обновления. Поэтому проект начинается с допустимой потери данных и времени простоя, а не с объёма диска.
При сравнении вариантов может рассматриваться система резервного копирования российского производства, однако окончательное решение принимают после проверки совместимости, скорости восстановления, модели лицензирования и требований к защите конкретной организации.
Одна копия на подключённом диске не защищает от большинства современных инцидентов. Надёжная схема разносит данные по разным носителям и площадкам, ограничивает доступ к хранилищу и сохраняет версию, которую нельзя незаметно изменить.
Цели и состав копирования
RPO и RTO
RPO показывает, какой объём последних изменений допустимо потерять, а RTO — сколько времени может занять восстановление. Для бухгалтерской базы и общего архива значения различаются, поэтому частоту и ресурсы задают по классам систем.
Что включить
Кроме файлов, копируют базы данных, конфигурации, ключи, виртуальные машины и сведения, необходимые для запуска. Документация должна объяснять порядок восстановления зависимостей, иначе отдельные сохранённые компоненты не соберутся в работающий сервис.
Архитектура хранения
Несколько независимых уровней
Практика 3-2-1 предполагает несколько копий на разных типах носителей и одну вне основной площадки. Для критичных данных добавляют неизменяемое или изолированное хранилище. Сроки хранения согласуют с требованиями бизнеса и законодательства.
- шифровать данные при передаче и хранении;
- разделять учётные записи администраторов;
- защищать каталог копий от удаления;
- контролировать свободное место и ошибки заданий;
- вести журнал тестовых восстановлений.
Проверка восстановления
Регулярные испытания
Успешный статус задания подтверждает запись данных, но не готовность сервиса к запуску. Периодически разворачивают копию в изолированной среде, проверяют целостность базы, права доступа и время выполнения. Результаты фиксируют и сравнивают с целевыми показателями.
Действия при инциденте
План определяет ответственных, порядок отключения заражённых систем и критерии выбора точки восстановления. Нельзя подключать чистое хранилище к скомпрометированной среде до локализации причины. После возврата сервиса анализируют пропущенные данные и обновляют сценарий.
Устойчивая система состоит из технологии, регламентов и практики восстановления. Только совместная проверка этих элементов показывает, сможет ли организация вернуться к работе в требуемый срок.
Инвентаризацию резервирования проводят после каждого заметного изменения инфраструктуры. Новый сервер или база не должны оставаться вне политики только потому, что их запустили между плановыми проверками. Автоматическое обнаружение полезно, но ответственность за включение системы закрепляют за владельцем.
