Шифровальщик не ищет базу — он шифрует всё, до чего дотягивается с заражённой машины под правами вошедшего пользователя. Поэтому копия, лежащая на соседнем диске того же сервера, в той же сетевой папке или в том же облачном аккаунте, шифруется в том же проходе, что и боевая база. Компания в этот момент обнаруживает, что резервное копирование у неё было настроено, работало каждую ночь и не помогло вообще.
Правило 3-2-1 закрывает ровно эту дыру: три копии данных, на двух разных типах носителя, одна из них вне площадки. Правило старое, придумано задолго до шифровальщиков и изначально защищало от пожара и отказа диска. Против шифровальщика оно работает по другой причине: третья копия физически недостижима из заражённой сети, а значит, её нечем испортить.
Ниже — конфигурация 3-2-1 для компании на сорок человек с 1С и CRM, четыре ситуации, в которых копия копией не является, вопрос про доступ к хранилищу, который обычно не задают, цена контура в месяц и минимальный сценарий проверки восстановления. Отдельно — честный разбор, когда хватает одной ежедневной выгрузки в объектное хранилище без всякой инфраструктуры.
Правило 3-2-1 на конфигурации небольшой компании
Вводные модельного примера: 40 сотрудников, файловая база 1С:Управление торговлей объёмом 25 ГБ, файловое хранилище с документами и сканами на 180 ГБ, ежедневная выгрузка облачной CRM на 4 ГБ. Итого около 210 ГБ боевых данных. Это типовой размер: он помещается куда угодно, и цена вопроса определяется не объёмом, а тем, как копии разнесены.
| Копия | Где лежит | Как часто | Что закрывает | Чем нельзя заменить |
|---|---|---|---|---|
| Первая — боевая | Рабочий сервер, снимок базы перед ночным обслуживанием | Каждый час в рабочее время | Ошибку оператора: удалили документ, испортили справочник | Это не резервная копия, это удобство отката |
| Вторая — на другом носителе | Отдельное сетевое хранилище или второй сервер, доступ по учётной записи копирования | Ежедневно ночью | Отказ диска, порчу базы, откат на вчера | Второй логический диск того же сервера |
| Третья — вне площадки | Российское объектное хранилище с версионированием и блокировкой на удаление | Ежедневно, история 30 дней | Шифровальщик, пожар, изъятие техники, отказ всей площадки | Внешний диск, который всегда подключён к серверу |
Два разных типа носителя в правиле означают не «два диска», а два разных способа хранения с разными механизмами отказа: локальный диск и объектное хранилище, локальный диск и лента, диск и съёмный носитель в сейфе. Два одинаковых диска в одном корпусе отказывают по одной и той же причине и от одного и того же вредоносного кода — это одна копия, посчитанная дважды.
Схема из трёх блоков слева направо. Блок «Боевой сервер, 210 ГБ» со стрелкой вниз в «Копия 1 — снимок раз в час, тот же сервер». От него стрелка вправо в «Копия 2 — сетевое хранилище, ежедневно ночью», обе обведены общей рамкой с подписью «одна площадка, одна сеть». Дальше вправо, за вертикальной штриховой линией с подписью «граница площадки», блок «Копия 3 — объектное хранилище, история 30 дней». Стрелка к нему подписана «только дозапись», обратной стрелки нет, рядом перечёркнутая стрелка с подписью «удалить и перезаписать нельзя». Внизу подпись: «3 копии — 2 типа носителя — 1 вне площадки». Чертёжный стиль, подписи по-русски.
Четыре копии, которые копиями не являются
Все четыре случая ниже встречаются в компаниях, где резервное копирование формально настроено и каждую ночь отрабатывает без ошибок. Общий признак у них один: до копии можно дотянуться из боевой системы с теми же правами, с которыми работает заражённая машина.
- Копия на соседнем диске того же сервера. Самый частый случай. Шифровальщик, запущенный под учётной записью с правами на сервере, обходит все примонтированные диски подряд. Разделение на «диск C для системы, диск D для копий» защищает от отказа диска и не защищает ни от чего другого.
- Копия в сетевой папке, которая примонтирована у пользователей. Если папка видна из проводника на рабочих местах, она видна и вредоносному коду. Учётная запись, под которой пишутся копии, не должна совпадать ни с одной пользовательской и не должна быть примонтирована постоянно.
- Копия в том же облачном аккаунте, что и боевая система. Один вход, один пароль, одна компрометация. Если злоумышленник получил доступ к панели управления, он удалит копии первым действием — именно так поступает любой, кто хочет исключить восстановление.
- Внешний диск, постоянно подключённый к серверу. Формально другой носитель, фактически — тот же том, доступный на запись. Съёмный носитель считается копией только тогда, когда он физически отключён между сеансами, а это ручная операция, которую в реальности перестают делать на третьей неделе.
Проверка на пять минут: сядьте за обычное рабочее место рядового сотрудника и попробуйте открыть, переименовать и удалить файл резервной копии. Если это получилось хотя бы частично — копии у вас нет, есть вторая цель для шифрования. Та же логика лежит в основе разбора прав в целом: право выдаётся не человеку и не должности, а операции, и подробно это разобрано в материале про принцип минимальных прав доступа.
Сравнение в две колонки, по четыре строки в каждой. Левая колонка «Копией не является»: соседний диск того же сервера, примонтированная сетевая папка, тот же облачный аккаунт, постоянно подключённый внешний диск. Правая «Копия»: отдельное сетевое хранилище с собственной учётной записью только на дозапись, объектное хранилище с версионированием и блокировкой удаления, съёмный носитель, физически отключаемый между сеансами. Между колонками вертикальная подпись-критерий: «дотянется ли до неё код, запущенный на рабочем месте». Чертёжный стиль, подписи по-русски.
Неизменяемое хранилище, доступ к копиям и ключ шифрования
Копия, которую нельзя перезаписать или удалить в течение заданного срока — ни пользователем, ни администратором, ни владельцем аккаунта. В российских объектных хранилищах это настраивается версионированием плюс блокировкой объектов на срок хранения: новая версия пишется поверх, старая остаётся доступной весь срок. Смысл в том, чтобы компрометация административной учётной записи не приводила к потере истории: удалить нечего, потому что удаление запрещено самим хранилищем, а не правилом в регламенте.
Учётная запись, под которой отрабатывает задание копирования, должна уметь ровно одно — дозаписывать новые объекты. Не читать чужие, не перезаписывать существующие, не удалять. Права на чтение выдаются отдельной учётной записью и только тому, кто выполняет восстановление; права на удаление старых версий не выдаются никому, за них отвечает срок хранения в настройках хранилища. Это ровно тот же принцип, по которому строится матрица доступа для остальных систем, — просто применённый к хранилищу.
Вопрос, который почти никогда не задают вслух: что произойдёт, если источником проблемы окажется человек, у которого есть доступ к копиям. Ответ здесь не технический, а организационный. Роли разделяются: тот, кто настраивает задания копирования, и тот, кто может восстановить данные в отдельный контур, — по возможности разные люди; обращения к хранилищу пишутся в журнал, а на выгрузку всей истории целиком ставится оповещение. Какие именно события в журналах требуют реакции и с какими порогами, разобрано в отдельном материале про события, требующие реакции.
Копии за пределами площадки шифруются — иначе выгрузка клиентской базы в чужие руки становится вопросом одного скачанного файла. Но ключ шифрования при этом обязан лежать отдельно от самих копий и отдельно от боевого сервера: в корпоративном менеджере паролей и вторым экземпляром на бумаге в сейфе. Потеря ключа означает, что копии есть и они нечитаемы — это ровно тот же результат, что и отсутствие копий, только обнаруживается он в худший момент. Где хранить такие секреты и как их менять, разобрано в материале про пароли и ключи компании.
Сколько это стоит в месяц и с чем сравнивать
Считаем ту же компанию на 40 человек и 210 ГБ данных. Ставка администратора — 1 200 ₽/час. Цена российского объектного хранилища на сентябрь 2026 года держится в диапазоне примерно 1,8–2,5 ₽ за гигабайт в месяц, берём 2,2 ₽; история за 30 дней с ежедневным приростом даёт около 520 ГБ хранимого объёма против 210 ГБ боевых.
Теперь другая сторона. Модельный сценарий: шифровальщик прошёл по серверу и по сетевой папке с копиями, пригодной копии не осталось, учёт восстанавливается по первичным документам. Считаем только прямые расходы, без гипотез об оттоке клиентов и репутации.
Столбчатая диаграмма из двух столбцов с подписанными значениями. Левый, низкий: «Контур 3-2-1, первый год — 71 400 ₽» с сегментами «настройка 14 400 ₽» и «эксплуатация 57 000 ₽», под ним пометка «следующие годы — 57 000 ₽». Правый, высокий: «Восстановление без копии — 374 880 ₽» с тремя сегментами: ввод первички 101 280 ₽, простой продаж и склада 201 600 ₽, внешний инженер 72 000 ₽. Между столбцами подпись «19 %». Ось — рубли. Чертёжный стиль, подписи по-русски.
Проверка восстановления: минимальный сценарий раз в квартал
Копия, из которой ни разу не разворачивали систему, копией не является — она является файлом, про который есть предположение. Задание может писать пустой архив третий месяц подряд, и в журнале это будет выглядеть как успешное выполнение. Минимальная проверка занимает три часа и не требует остановки работы: она делается в отдельном контуре, а не на боевом сервере.
- 11. Взять копию, которой не меньше недели
Не вчерашнюю. Смысл проверки в том, чтобы убедиться, что доступна вся глубина хранения, а не только последний файл. Заодно выясняется, сколько времени занимает выгрузка из объектного хранилища — обычно это дольше, чем ожидают.
- 22. Развернуть в отдельном контуре
Отдельный сервер, отдельная виртуальная машина или временный контур у подрядчика. Разворачивать поверх боевой системы нельзя ни при каких обстоятельствах: неудачная проверка в этом случае превращается в реальный инцидент. Если контур поднимается на данных с персональными сведениями, работает то же требование, что и для тестовых сред, — обезличивание перед выгрузкой.
- 33. Открыть три конкретных объекта
Не «система запустилась», а проверяемый результат: открыть последний закрытый месяц в учёте, найти карточку конкретного клиента, открыть один скан документа из файлового хранилища. Три объекта выбираются заранее и записываются, чтобы проверка была одинаковой из раза в раз.
- 44. Записать два числа
Сколько времени заняло восстановление от начала выгрузки до открытого документа и на какую дату восстановились данные. Эти два числа и есть ответ на вопрос «сколько мы простоим» и «сколько работы потеряем» — их называют руководителю, а не «копии делаются ежедневно».
Три часа администратора — это минимальный сценарий: поднимается база, а не весь рабочий контур вокруг неё. Полноценное учение с проверкой обменов, ключей интеграций, расписаний фоновых задач и настроек почтового отправителя требует инженера и стоит 6 700 ₽ за одно учение; процедура и восемь слепых зон, которые не попадают ни в одну копию, разобраны в материале про резервные копии и восстановление. Минимальный сценарий отвечает на вопрос «есть ли данные», полное учение — на вопрос «через сколько мы начнём работать».
Первую проверку разумно провести не через квартал после запуска системы, а в день приёмки: развёрнутая копия входит в перечень того, что забирается у подрядчика вместе с исходниками и документацией. Полный список из четырнадцати пунктов приведён в материале про чек-лист закрытия проекта — копия, которую никто не разворачивал, не считается принятой работой.
Когда достаточно одной копии в объектное хранилище
Полный контур 3-2-1 с сетевым хранилищем и квартальными проверками нужен не всем. Есть конфигурации, в которых он избыточен, и честнее это сказать, чем продать лишнее оборудование.
- Все рабочие системы облачные, своего сервера нет. Учёт, CRM и файлы живут у поставщиков услуг, каждый из которых держит собственные копии. Здесь достаточно одной ежедневной выгрузки в независимое объектное хранилище — примерно 1 000–1 500 ₽ в месяц и час настройки. Смысл этой выгрузки не в защите от шифровальщика, а в защите от блокировки аккаунта и от ухода поставщика.
- Объём боевых данных меньше 20 ГБ и меняется медленно. Проектное бюро, юридическая практика, небольшая торговая компания на облачной учётной системе. Ежедневная выгрузка в хранилище с историей 30 дней закрывает почти весь риск; второй носитель на площадке добавляет мало.
- Данные восстанавливаются из чужой системы за часы. Если весь товарный каталог приходит от поставщика, а заказы дублируются в кабинете маркетплейса, потеря локальной базы стоит не трёх недель, а одного дня загрузки заново. Полный расчёт в этом случае даёт отрицательный результат, и контур не нужен.
- Компания уходит с этой системы в ближайшие месяцы. Строить контур вокруг того, что через квартал будет отключено, смысла нет: разумнее один раз выгрузить полный архив и хранить его как есть, а нормальное резервирование закладывать сразу в проект новой системы.
И обратная ситуация, в которой экономить нельзя ни при каком размере компании. Если в системе есть данные, которые невозможно восстановить из внешних источников — история переписки с клиентами, записи разговоров, сканы подписанных документов, накопленная себестоимость, — правило 3-2-1 применяется целиком, независимо от того, сорок в компании человек или шесть. Восстановить учёт по первичке тяжело, но возможно; восстановить то, чего не существует в бумажном виде, нельзя вообще.
Резервная копия — это не файл, который создаётся, а система, которая разворачивается. Пока её не развернули, у вас есть только предположение.
