Резервное копирование 3-2-1: как построить

Коротко. Резервное копирование 3-2-1 — правило: три копии данных (рабочая и две резервные), на двух разных типах носителей, одна из них — вне основной площадки. Сегодня его обычно дополняют до 3-2-1-1-0: ещё одна копия офлайн или неизменяемая, и ноль ошибок при проверке восстановления. Строить схему нужно не от носителей, а от двух чисел: сколько данных бизнес может потерять (RPO) и за сколько систему нужно вернуть (RTO). А проверять — не по зелёным галочкам в консоли, а тестовым восстановлением по расписанию. Ниже — пошаговая схема, сравнение вариантов хранения и порядок проверки.

Для ИТ-специалистов и руководителей, у которых резервные копии «вроде бы есть».

Что такое правило 3-2-1

Правило 3-2-1 — простой способ не зависеть от одной точки отказа:

• 3 копии данных. Рабочие данные плюс две резервные копии. Одна копия — не копия: сломается она ровно тогда, когда понадобится.
• 2 разных типа носителей. Например, дисковое хранилище и лента или облачное хранилище. Одна причина отказа — ошибка контроллера, прошивки, сбой массива — не должна уничтожить обе копии.
• 1 копия вне основной площадки. Пожар, затопление, кража или отключение электричества в серверной не должны затронуть все копии сразу.

Правило описывает минимум устойчивости к сбоям и авариям. Против атаки его недостаточно, поэтому появилось расширение.

3-2-1-1-0: отраслевое расширение правила

Вариант 3-2-1-1-0 — распространённая отраслевая практика, ответ на шифровальщики, которые сначала ищут и удаляют резервные копии:

• +1 копия офлайн или неизменяемая. Физически отключённый носитель (лента, диск в сейфе) или хранилище с блокировкой удаления на заданный срок (immutable storage, WORM). Даже с правами администратора атакующий не сможет её стереть.
• 0 ошибок. Копии регулярно проверяются восстановлением, а ошибки проверки разбираются, а не игнорируются.

CISA в руководстве #StopRansomware рекомендует держать офлайн-копии критичных данных, шифровать их и регулярно проверять восстановление — это та же логика. Как резервные копии вписываются в общую защиту от шифровальщиков, описано в статье защита от шифровальщиков; здесь — как построить саму систему копирования.

Сначала RPO и RTO

Прежде чем выбирать носители, ответьте на два вопроса для каждой важной системы:

• RPO (Recovery Point Objective) — сколько данных допустимо потерять. Если RPO — 24 часа, достаточно ежесуточной копии. Если потеря часа заказов недопустима, нужна копия каждый час или репликация.
• RTO (Recovery Time Objective) — за сколько система должна снова работать. Восстановить терабайт из облака по офисному каналу может занять больше суток; если RTO — 4 часа, нужна локальная копия.

Числа устанавливает бизнес, а не ИТ: владелец процесса знает, во что обходится час простоя. ИТ отвечает, что эти числа стоят. Методика планирования непрерывности подробно описана в NIST SP 800-34 Rev. 1.

Как построить резервное копирование 3-2-1: пошагово

Шаг 1. Составьте список того, что копируется. Не только файловые серверы: базы данных учётных систем, почта, контроллеры домена, конфигурации сетевого оборудования, облачные сервисы (данные в SaaS тоже нужно копировать — провайдер отвечает за доступность сервиса, но не всегда за восстановление ваших удалённых данных), исходный код, ключи и сертификаты.

Шаг 2. Разделите системы на классы. Критичные (бизнес стоит без них), важные, остальные. Для каждого класса — RPO, RTO и срок хранения копий.

Шаг 3. Выберите схему хранения. Типичная для небольшой компании: локальное хранилище для быстрого восстановления, копия во внешнем хранилище или облаке с неизменяемостью, периодическая офлайн-копия критичных данных.

Шаг 4. Изолируйте систему копирования. Отдельные учётные записи, не входящие в основной домен; двухфакторная аутентификация на консоли; хранилище копий в отдельном сегменте сети; доступ с рабочих станций пользователей закрыт.

Шаг 5. Шифруйте копии и храните ключи шифрования отдельно от копий — и так, чтобы они были доступны при потере основной инфраструктуры. Копия, которую нельзя расшифровать, бесполезна.

Шаг 6. Настройте оповещения о неудачных заданиях, удалении копий и изменении политик хранения — и направьте их туда, где их увидят. Удаление копий — один из ранних признаков подготовки к шифрованию.

Шаг 7. Опишите восстановление. Порядок подъёма систем (обычно сначала домен и сеть, потом базы, потом приложения), где лежат инструкции и ключи. Этот документ — приложение к плану реагирования на инциденты.

Где хранить копии: сравнение вариантов

Главная мысль таблицы: репликация и синхронизация — не резервное копирование. Всё, что удалено или зашифровано в оригинале, тут же удаляется или шифруется в копии.

Как проверить резервные копии

Проверка идёт по уровням — от простого к полному:

1. Контроль заданий — ежедневно. Все ли задания прошли, нет ли пропущенных систем. Зелёная галочка означает, что задание завершилось, а не что из копии можно восстановиться.
2. Проверка целостности — автоматически. Встроенная проверка контрольных сумм и читаемости копий.
3. Восстановление файлов — ежемесячно. Случайные файлы из разных систем в отдельное место, сверка содержимого.
4. Восстановление системы — ежеквартально. Критичная система целиком в изолированной среде: запускается ли, открываются ли данные, сколько заняло времени. Это время сравнивается с RTO.
5. Учение по полному восстановлению — раз в год. Сценарий «основная площадка недоступна»: восстановление из офлайн- или неизменяемой копии, по документу, силами тех, кто будет делать это в реальности.

Результат каждой проверки фиксируется: дата, что восстанавливали, время, проблемы. Если фактическое время больше RTO — схему меняют сейчас, а не во время инцидента.

Типичные ошибки

• Копия лежит на том же хранилище, что и оригинал, или доступна по сети с тех же учётных записей.
• Консоль системы копирования входит в основной домен, пароль администратора общий.
• Облачные сервисы (почта, документы) не копируются, «потому что это облако».
• Копии зашифрованы, а ключ хранится только на сервере, который тоже зашифрован.
• Никто не знает, сколько на самом деле длится восстановление.
• Копии содержат персональные данные, а доступ к ним не ограничен: меры защиты по закону № 99-З распространяются и на резервные копии. Подробнее — в статье закон 99-З: что обязан сделать владелец сайта.

Проверку копий на реальное восстановление, план действий и дежурную команду кибербезопасности Viviar предлагает в пакете «Защита от шифровальщиков» — от 17 400 BYN и от 7 300 BYN в месяц.

Чек-лист: резервное копирование 3-2-1 построено и проверено

• Для каждой критичной системы определены RPO и RTO
• Есть не менее трёх копий данных на двух типах носителей
• Одна копия хранится вне основной площадки
• Одна копия офлайн или неизменяемая
• Облачные сервисы тоже копируются
• Система копирования изолирована, вход с двухфакторной аутентификацией
• Ключи шифрования копий доступны при потере основной инфраструктуры
• Настроены оповещения о сбоях и удалении копий
• Ежеквартально выполняется тестовое восстановление критичной системы с замером времени
• Порядок восстановления описан и приложен к плану реагирования

Частые вопросы

Что такое правило резервного копирования 3-2-1?

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

Чем 3-2-1-1-0 отличается от 3-2-1?

Вариант 3-2-1-1-0 добавляет к классическому правилу два условия: ещё одна копия должна быть офлайн или неизменяемой, чтобы её нельзя было удалить даже с правами администратора, и проверки восстановления должны проходить без ошибок. Это отраслевая практика, появившаяся как ответ на атаки, при которых сначала уничтожают резервные копии.

Как часто проверять резервные копии?

Контроль заданий — ежедневно, автоматическую проверку целостности — после каждого задания, выборочное восстановление файлов — ежемесячно, полное восстановление критичной системы с замером времени — ежеквартально, учение по восстановлению после потери площадки — раз в год. Конкретную частоту закрепляют во внутренней политике с учётом RPO и RTO.

Можно ли считать облачную синхронизацию резервной копией?

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

Сколько стоит построить и проверить резервное копирование?

Зависит от объёма данных, числа систем и требований к RPO и RTO. У Viviar проверка резервных копий на реальное восстановление входит в пакет «Защита от шифровальщиков» от 17 400 BYN, дежурная команда — от 7 300 BYN в месяц. Точную смету дают после короткого разговора.

Вывод

Резервное копирование 3-2-1 — это минимум, 3-2-1-1-0 — практика, которая выдерживает шифровальщика. Строить схему нужно от RPO и RTO, копии — изолировать и защищать от удаления, а надёжность подтверждать только тестовым восстановлением с замером времени. Если хотите проверить, восстановятся ли ваши системы на самом деле, — напишите нам.

Источники: CISA и MS-ISAC — #StopRansomware Guide (cisa.gov); NIST SP 800-34 Rev. 1 «Contingency Planning Guide for Federal Information Systems» (nist.gov); CIS Critical Security Controls v8, контроль 11 «Восстановление данных» (cisecurity.org); Закон Республики Беларусь от 07.05.2021 № 99-З «О защите персональных данных» (pravo.by); цены — публичные пакеты Viviar, действуют с 01.09.2026.