Стратегия 3-2-1: как защитить бэкапы от потери и шифровальщиков

Резервное копирование — это не просто кнопка «старт» в панели управления. Если у вас нет продуманной схемы, то в критический момент вы останетесь у разбитого корыта. Я видел, как клиенты теряли данные из-за того, что бэкап лежал на том же диске, что и исходники, или был доступен по тем же учёткам, что и рабочий сервер. Шифровальщик не прощает таких ошибок. Стратегия 3-2-1 — это база, которую я закладываю в любую инфраструктуру, будь то домашний NAS или серверная небольшой компании. Но в современных условиях её нужно усиливать immutable-копиями и изоляцией доступа. Иначе это не защита, а иллюзия безопасности.

Что такое стратегия 3-2-1 простыми словами

Суть правила 3-2-1 очень простая, я часто объясняю её на пальцах:

• 3 копии данных: оригинал и минимум две резервные копии.
• 2 разных типа носителей: например, диск и облачное объектное хранилище, диск и лента, NAS и внешний диск.
• 1 копия вне основной площадки: в другом физическом месте или хотя бы вне сети основного сервера.

На практике этого уже достаточно, чтобы не оказаться в ситуации, когда ломается единственный диск, а вместе с ним исчезает и единственный бэкап. Но в 2026 году классическая схема 3-2-1 считается базой, а не потолком: к ней почти всегда добавляют immutable-копию или air-gap. Это защищает резервные копии от шифровальщиков и от случайного удаления из-под скомпрометированной учётной записи. Как говорят сисадмины: «Один бэкап — это не бэкап, а два — это один». Три — уже норма.

Почему обычного бэкапа недостаточно

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

Шифровальщик действует быстро и без эмоций:

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

Отсюда главный вывод: бэкап должен быть не просто создан, а изолирован и проверяем. Иначе это не защита, а надежда на удачу. Я не раз видел, как после атаки клиенты доставали резервную копию, а она оказывалась зашифрованной вместе с основными данными — потому что висела на той же шаре с теми же правами.

Как выглядит надежная схема 3-2-1 в реальной инфраструктуре

Ниже — практичный вариант, который подходит для малого офиса, домашнего сервера или небольшой компании. Я сам использую примерно такую архитектуру и рекомендую её всем, кто не хочет проснуться без данных.

Если говорить совсем просто: один бэкап нужен для скорости, второй — для выживания. А четвёртый уровень — это ваш последний рубеж, когда всё остальное уже горит.

Что считать “разными носителями”

Смысл второго пункта стратегии — не класть все яйца в одну технологическую корзину. Два разных типа носителей — это не просто два раздела на одном диске. Это защита от отказа конкретной технологии.

Подходящие сочетания:

• SSD/HDD + объектное облачное хранилище;
• серверный диск + ленточный архив;
• NAS + внешний USB-диск;
• локальный репозиторий + удалённый репозиторий у другого провайдера.

Плохой вариант:

• два раздела на одном диске;
• два каталога на одном NAS;
• два репозитория в одной админке, защищенные одним паролем;
• бэкап и рабочие данные в одной и той же доменной среде без изоляции.

Если отказывает один узел, технология хранения должна пережить этот отказ. Я помню случай, когда у клиента сгорел контроллер на RAID-массиве, а бэкап лежал на том же контроллере во втором томе. Восстановить удалось только с офлайн-копии на внешнем диске, которую делали раз в месяц «на всякий случай».

Почему immutability важнее, чем просто “облако”

Многие уверены, что облачный бэкап уже автоматически безопасен. Это не так. Если доступ к облаку есть у скомпрометированной учётной записи, резервные копии тоже могут пострадать. Более того, некоторые облачные сервисы позволяют удалять объекты через API — и если злоумышленник получил ваш ключ, он может просто стереть всё.

Immutable backup — это копия, которую нельзя изменить или удалить до истечения заданного срока хранения. Чаще всего это реализуется через:

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

Именно immutable-копия часто становится той самой точкой восстановления после атаки. Для шифровальщика это тупик: он может шифровать доступные ресурсы, но не может переписать защищённый архив. Я рекомендую использовать immutable как третий или четвёртый уровень — это стоит тех денег и усилий.

3-2-1 уже мало: зачем добавляют правило 3-2-1-1-0

На практике часто используют расширение 3-2-1-1-0:

• 3 копии данных;
• 2 разных типа носителей;
• 1 копия вне площадки;
• 1 копия offline, air-gapped или immutable;
• 0 ошибок при проверке восстановления.

Последний пункт особенно важен. Бэкап без тестового восстановления — это не гарантия, а предположение. Очень часто выясняется, что архив есть, но:

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

У меня был случай, когда клиент гордился ежедневным бэкапом на ленту, а когда потребовалось восстановить базу 1С, выяснилось, что ленточный накопитель не читает ленты из-за загрязнения головок. Проверка восстановления спасла бы ситуацию за месяц до инцидента.

Как построить защиту бэкапов от шифровальщиков

1. Разделите учетные записи

У бэкап-системы должен быть отдельный доступ, который не совпадает с правами обычного администратора домена или файлового сервера. Я всегда создаю выделенного пользователя для backup, с правами только на чтение источника и запись в репозиторий. Никаких доменных админов.

Что важно:

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

Если один пароль открывает и сервер, и бэкап — это слабое место. Шифровальщик не поленится проверить хранилище с теми же кредами.

2. Изолируйте хранилище

Нормальная практика:

• отдельный VLAN или отдельная подсеть;
• закрытый доступ к репозиторию только с серверов бэкапа;
• минимизация SMB/админских портов;
• запрет прямого доступа пользователей к хранилищу.

Чем меньше поверхность атаки, тем выше шанс, что резервная копия останется целой. Идеально, если только демон бэкапа может писать в хранилище, а всё остальное — запрещено на уровне файрвола.

3. Делайте хотя бы одну копию неизменяемой

Это ключевой пункт против ransomware. Подойдут:

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

Если копия подключена постоянно и доступна из той же сети, что и заражённая система, она уязвима. Я предпочитаю комбинацию: immutable в облаке плюс внешний диск, который висит на USB только во время окна бэкапа, а потом физически отключается.

4. Проверяйте целостность и восстанавливаемость

Нужно проверять не только факт выполнения задания, но и результат. Минимум контроля:

• отчёт о завершении бэкапа;
• сверка размера и контрольных сумм;
• тестовое восстановление файла;
• тестовое восстановление виртуальной машины или образа;
• контроль времени восстановления.

Хорошая практика — раз в месяц делать полноценный drill: поднять тестовую систему из бэкапа и убедиться, что она работает. Автоматизируйте это скриптами, чтобы не забывать.

5. Храните копии на разных сроках

Полезно иметь:

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

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

Типовые ошибки, из-за которых 3-2-1 не работает

• Бэкап лежит в той же комнате, что и основной сервер, без второй площадки.
• На резервный NAS есть постоянный доступ из основной сети.
• Пароль от бэкап-сервиса хранится в браузере у всех админов.
• Резервные копии не шифруются и не защищены правами доступа.
• Никто никогда не проверял восстановление.
• Хранят только один полный архив, а старые точки восстановления очищаются слишком агрессивно.
• Облако считается защищённым по умолчанию, хотя доступ к нему открыт через обычную учётку.
• Удаление старых копий не контролируется журналами.

На бумаге схема есть, а в реальности она может быть бесполезной. Я видел ситуацию, когда компания гордилась «тройной» защитой, а на деле все три копии хранились на одном RAID-массиве в разных папках. Один сбой контроллера — и всё.

Пошаговый план внедрения 3-2-1

Шаг 1. Определите, что именно нужно защищать

Составьте список:

• рабочие документы;
• бухгалтерия;
• базы данных;
• образы систем;
• конфиги роутеров, серверов, виртуализации;
• фото и архивы.

Не все данные одинаково важны. Сначала защищают то, потеря чего бьёт по деньгам и простоям.

Шаг 2. Разделите данные по критичности

Удобно использовать три категории:

• критичные — потеря недопустима;
• важные — можно восстановить, но с простоями;
• второстепенные — допустима частичная потеря.

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

Шаг 3. Выберите минимум две технологии хранения

Например:

• локальный репозиторий на отдельном диске;
• удалённый immutable-репозиторий в облаке;
• офлайн-копия на внешнем диске по расписанию.

Используйте проверенное ПО для резервного копирования, которое умеет работать с разными типами хранилищ.

Шаг 4. Настройте раздельный доступ

• отдельный пользователь;
• сложный пароль;
• MFA;
• ограничение прав;
• отдельные ключи доступа;
• журналирование действий.

Шаг 5. Автоматизируйте проверку

Настройте:

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

Шаг 6. Опишите процедуру восстановления

Сделайте простой документ:

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

При инциденте память подводит. Документ — нет.

Чек-лист для быстрой проверки резервного копирования

• Есть ли минимум 3 копии данных?
• Хранятся ли они на 2 разных типах носителей?
• Есть ли хотя бы 1 копия вне основной площадки?
• Есть ли immutable или offline-копия?
• Разделены ли учётные записи для бэкапа и администрирования?
• Закрыт ли прямой доступ к репозиторию из основной сети?
• Проводились ли тестовые восстановления?
• Известно ли реальное время возврата системы в работу?
• Сохраняются ли логи ошибок и удалений?
• Есть ли инструкция на случай атаки шифровальщика?

Если хотя бы на три вопроса ответ “нет”, схему нужно дорабатывать.

Как часто проверять бэкапы

Оптимальный ритм зависит от нагрузки, но базово можно ориентироваться так:

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

Бэкап, который не проверяли полгода, нельзя считать надёжным. Я обычно добавляю в планировщик задач еженедельный скрипт, который восстанавливает случайный файл и сверяет контрольную сумму.

Что важно для малого бизнеса и домашнего пользователя в России

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

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

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

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

Вывод

Стратегия 3-2-1 работает не потому, что это модный стандарт, а потому что она закрывает три главные угрозы: поломку, ошибку человека и атаку шифровальщика. Но в современных условиях её нужно усиливать immutable-копией, изоляцией доступа и регулярным тестовым восстановлением.

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

FAQ

Что лучше: облако или локальный бэкап?

Лучше использовать оба варианта. Локальный бэкап быстрее восстанавливается, а облачный или офлайн-копия спасает при физической потере площадки. В идеале — облако с immutable-политикой и локальный репозиторий на отдельном диске.

Зачем нужен immutable-бэкап?

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

Можно ли считать внешний жесткий диск 3-2-1-решением?

Только если это не единственная копия и если он хранится отдельно от рабочего ПК, а не подключен постоянно. Внешний диск — отличный вариант для второго носителя, но он должен быть частью более широкой схемы.

Как понять, что бэкап действительно рабочий?

Его нужно хотя бы иногда восстанавливать: файл, папку, виртуальную машину или образ системы. Без теста надёжность неизвестна. Я рекомендую раз в месяц поднимать тестовую ВМ из бэкапа и проверять, что все сервисы запускаются.

Подходит ли правило 3-2-1 для одного компьютера?

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