Что проверить в резервных копиях

Фраза «резервные копии есть» может означать очень разные вещи: настроено задание, вчера создался файл, копия хранится рядом с сервером или команда действительно восстановила нужную систему и зафиксировала результат проверки.

Наличие копии и возможность восстановить работу — не одно и то же. Проверка начинается не с программы резервного копирования, а с вопроса: что именно компания должна вернуть и в каком порядке.

1. Состав: что должно попасть в копию

Составьте перечень по системам, а не по носителям. Для каждой системы укажите:

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

Копия виртуальной машины не всегда включает данные внешнего хранилища. Копия базы не всегда включает конфигурацию приложения. Экспорт настроек не заменяет данные пользователей. Эти границы нужно записать явно.

2. Время и допустимая потеря данных

Два практических вопроса:

• сколько данных компания готова потерять между последней пригодной копией и сбоем;
• сколько времени допустимо до восстановления выбранного процесса.

Это не готовые обещания подрядчика. Ответ зависит от работы бизнеса, последовательности запуска систем, доступности людей, объёма данных и технической схемы. Сначала фиксируют ожидание и ограничения, затем проверяют, достижимо ли оно текущими средствами.

3. Изоляция: переживёт ли копия тот же инцидент

Если копии постоянно доступны с тех же учётных записей и из той же сети, ошибка, атака или неверное действие может затронуть и рабочие данные, и резерв. CISA рекомендует хранить критичные резервные копии изолированно, защищать их и регулярно проверять доступность и целостность в сценарии восстановления.

Проверьте:

• есть ли отдельная копия вне основной площадки;
• можно ли удалить или переписать её с обычной административной учётной записи;
• защищены ли хранилище, ключи и консоль резервирования многофакторной аутентификацией;
• отслеживаются ли неуспешные задания, неожиданное уменьшение объёма и удаление точек восстановления;
• достаточно ли срока хранения, чтобы обнаружить проблему до исчезновения пригодной версии.

Схема «3-2-1» может быть полезной памяткой, но число копий само по себе не доказывает восстановимость. Важны независимость, актуальность и проверка.

4. Наблюдение: кто увидит ошибку

Для каждого задания должны быть понятны:

• расписание;
• ожидаемый объём;
• получатель уведомления;
• срок реакции на ошибку;
• порядок повторного запуска;
• случаи, когда ошибка требует не повторения, а расследования.

Ежедневное письмо «успешно» недостаточно, если его никто не просматривает или система перестала включать новый каталог. Полезно сравнивать не только статус, но и состав, размер, длительность и возраст последней пригодной копии.

5. Восстановление: что именно тестировать

Начните с ограниченного теста. Выберите одну важную систему или набор данных и заранее определите:

1. Какую точку восстановления используем.
2. Куда восстанавливаем, чтобы не повредить рабочую среду.
3. Кто выполняет технические действия.
4. Кто проверяет содержимое и работоспособность со стороны бизнеса.
5. Какие зависимости нужны для запуска.
6. Что будет считаться успешной проверкой.
7. Какие фактические времена и проблемы фиксируем.

Успешно извлечённый файл — это результат одного теста. Он не доказывает, что вся информационная система восстановится в другом сценарии. Поэтому проверки выбирают по риску и повторяют после значимых изменений.

6. Документы и доступы

Во время аварии особенно заметны простые пробелы:

• инструкция доступна только на неработающем сервере;
• контакт поставщика хранится в почте, к которой нет доступа;
• ключ шифрования знает один человек;
• срок лицензии истёк;
• порядок запуска систем не записан;
• никто не уполномочен принять решение о переключении.

Храните краткую инструкцию и контакты отдельно от восстанавливаемой среды. Не публикуйте в ней пароли; укажите способ получить контролируемый доступ.

Минимальная карточка проверки

Для каждой критичной системы достаточно одной страницы:

• система и процесс, который от неё зависит;
• владелец со стороны бизнеса и технический ответственный;
• данные и конфигурации в составе копии;
• расписание и срок хранения;
• место хранения и граница доступа;
• последняя успешная копия;
• последняя проверка восстановления: дата, объём, среда, фактическое время;
• что проверено, что не проверено;
• найденные ограничения и следующий шаг.

Когда нужен отдельный проект

Регулярная поддержка может наблюдать задания и выполнять согласованные проверки. Но изменение архитектуры хранения, перенос больших объёмов, построение резервной площадки или согласование нового порядка аварийного восстановления часто являются отдельной работой. Это стоит обозначить до начала, чтобы текущая эксплуатация и проект не смешались.

Короткий вывод

Зрелый вопрос звучит не «есть ли бэкап», а «какую систему, из какой точки, кто и в каком порядке уже пробовал восстановить». Если такого свидетельства нет, корректный статус — «копирование настроено, восстановление требует проверки».

Источники и границы материала

• CISA #StopRansomware Guide — изолированные и зашифрованные копии, регулярная проверка доступности и целостности, приоритет восстановления критичных сервисов.
• NIST SP 800-34 Rev. 1 — анализ влияния, требования к плану восстановления, тестирование и поддержание плана.
• NIST Cybersecurity Framework 2.0 — управление активами, устойчивость инфраструктуры и выполнение восстановления.

Источники проверены 30 августа 2026 года. Материал не является планом аварийного восстановления конкретной компании и не подтверждает пригодность её резервных копий.