Резервное копирование по правилу «3-2-1»: инструменты и лучшие практики

Резервное копирование давно стало необходимой частью ИТ-рутины, особенно с распространением шифровальщиков. Правило «3-2-1» ещё в начале 2000-х годов стало золотым стандартом: три копии данных на двух разных носителях, одна из которых хранится офлайн (вне основной сети).

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

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

Содержание:

1. Как появилось правило «3-2-1»
2. «3-2-1» перед лицом современных киберугроз
3. Инструменты резервного копирования: современный ландшафт
4. Лучшие практики резервного копирования по «3‑2‑1»
5. Заключение: чек-лист для самопроверки

Как появилось правило «3-2-1»

Правило «3-2-1» уходит корнями в практики системных администраторов, которые эмпирически вывели, что двух копий недостаточно. Авторство чаще всего приписывают Питеру Крогу, фотографу и эксперту по цифровому архивированию, который в своей книге «Digital Asset Preservation» обобщил многолетний опыт потери и восстановления данных. Однако инженеры IBM и крупных дата-центров использовали схожие принципы ещё в 1980-х — на магнитных лентах и дисковых массивах.

Классическая формулировка правила звучит так: необходимо иметь как минимум три копии данных, хранящихся на двух разных типах носителей, причём одна из копий должна находиться за пределами основной площадки (offsite). Расшифруем каждый элемент.

Три копии — это первичные данные (рабочая копия, с которой работает пользователь или приложение) плюс две резервные копии. Первичные данные не считаются «копией» в терминах резервирования, но в контексте правила их учитывают, чтобы подчеркнуть, что ни один бэкап не должен быть единственным источником данных. Итого: оригинал плюс две независимые резервные копии.

Два разных носителя подразумевают, что копии должны физически различаться по технологии хранения. Например, основная копия на внутреннем SSD, первая резервная — на внешнем HDD, вторая — в облаке. Смысл в том, чтобы исключить общую точку отказа: если один тип носителя имеет системную уязвимость (например, контроллер RAID выходит из строя), другой тип носителя может уцелеть. Классическая пара: диски (SSD/HDD) и ленты (LTO). В современных условиях — локальный NAS и облачное объектное хранилище.

Одна копия офлайн (или вне основной площадки) — это защита от физических катастроф: пожара, наводнения, кражи оборудования, а также от программных атак, которые поражают всё, что доступно по сети. Офлайн означает, что носитель физически отключён от сети. Чаще всего это внешний жёсткий диск, который подключается только на время бэкапа, или магнитная лента, извлечённая из библиотеки. Вне площадки (offsite) — это когда копия находится в другом здании, городе или даже стране, исключая общий риск для всех носителей на основном объекте.

«3-2-1» перед лицом современных киберугроз

В эпоху доминирования ленточных библиотек и ручной смены картриджей правило «3-2-1» было относительно легко выполнимо. Бэкап на ленту автоматически давал офлайн-копию и сменный носитель. Администратор мог спокойно спать, зная, что даже если злоумышленник сотрёт все диски в ЦОД, ленты в сейфе соседнего здания останутся нетронутыми.

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

Более того, правило ничего не говорит о проверке восстановления. Многие организации десятилетиями делали бэкапы по схеме «3-2-1», но в критический момент обнаруживали, что их резервные копии повреждены, нечитаемы или не содержат нужных данных — потому что процесс никогда не тестировался.

Основная проблема: все копии могут быть доступны по сети. В классическом правиле «3-2-1» offsite-копия не обязана быть изолированной от сети. Она может храниться в облаке (S3-совместимое хранилище) или на удалённом NAS, доступном через VPN. Злоумышленник, получивший контроль над доменом и укравший учётные данные для облачной «корзины» или удалённой системы, может удалить или зашифровать и эти копии. Более того, современные шифровальщики активно охотятся за подключёнными сетевыми дисками и облачными синхронизациями.

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

Сергей Коловангин

Начальник отдела ИТ компании «Газинформсервис»

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

Классическое правило «3-2-1» также ничего не говорит о проверке того, что из этих копий действительно можно восстановить данные. Многие организации в критический момент обнаруживали, что файлы бэкапов повреждены, нечитаемы, не содержат нужных данных или просто несовместимы с текущей версией программного обеспечения. Это происходит потому, что процесс восстановления никогда не тестировался. В эпоху ransomware цена такой ошибки — не просто потерянные данные, а невозможность отказаться от выкупа.

Именно в ответ на эти новые угрозы индустрия выработала эволюцию классического правила — концепцию «3-2-1-1-0», которая добавляет два критически важных элемента:

• 3 копии данных (оригинал плюс две резервные).
• 2 разных типа носителей или платформ хранения.
• 1 копия вне основной площадки (offsite).
• 1 копия, которая является неизменяемой (immutable) или физически изолированной от сети (air-gapped).
• 0 ошибок после верифицированного тестирования восстановления.

Расширение правила адресует именно те уязвимости, которые описаны выше. Дополнительная единица — «одна неизменяемая или изолированная копия» — решает проблему доступа атакующего к репозиториям бэкапов. Immutable-бэкапы — технология, при которой данные после записи блокируются на заданный срок и не могут быть изменены, перезаписаны или удалены, даже при наличии у атакующего полного административного доступа к системе хранения. Реализуется через механизмы Object Lock на S3-совместимых облачных хранилищах, через immutable-снапшоты на уровне СХД или через встроенные функции современных систем бэкапа. Главное преимущество — ransomware-устойчивая конструкция при сохранении оперативности восстановления.

Семен Рогачев

Руководитель отдела реагирования на инциденты компании «Бастион»

[В современных подходах к резервному копированию] Добавились пункты с одной неизменяемой копией — WORM (Write Once Read Many) — и нулевым количеством ошибок восстановления, то есть с регулярными перепроверками резервных копий. При этом с точки зрения безопасности и восстановления в самом критичном случае внедрение схемы WORM крайне важно — в случае, если механизм реализован исключительно программными методами или содержит изъяны, на бумаге схема может считаться выполненной, но при этом остается риск компрометации самой системы хранения, что сведет все усилия на нет.

Ещё один важный принцип вошёл в общее использование из опыта промышленных сетей. Air-gap (изоляция резервных копий) — это физический или логический разрыв между резервными копиями и производственной сетью. Это могут быть диски, извлечённые из библиотеки и хранящиеся в сейфе, виртуальная изоляция через специальные механизмы доступа, например, временное подключение хранилища только на период бэкапа. 

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

Параллельно с эволюцией «3-2-1-1-0» на рынке появляются и другие подходы. Концепция «4-3-2» предусматривает четыре копии данных на трёх различных типах носителей, с двумя изолированными средами хранения. Правило «4-3-2-1» требует четыре копии в трёх разных физических локациях, две из которых находятся за пределами основной площадки, и одна из четырёх копий должна быть неизменяемой. Для организаций с самыми высокими требованиями к отказоустойчивости (финансовый сектор, КИИ, критическая инфраструктура) эти расширенные схемы становятся новым стандартом.

Инструменты резервного копирования: современный ландшафт

Сегодняшний рынок решений для резервного копирования в России кардинально отличается от того, что был несколько лет назад. Уход западных вендоров (Veeam, Commvault, Veritas), ужесточение требований импортозамещения и эволюция угроз привели к формированию нового ландшафта, где ключевыми критериями выбора стали не только функциональность, но и наличие в реестрах российского ПО, сертификация ФСТЭК и способность противостоять целенаправленным атакам на инфраструктуру бэкапов.

Российские платформы

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

• «Акронис-Инфозащита». «Акронис Защита Данных» представляет собой систему резервного копирования, восстановления и защиты данных для ИТ-систем любой сложности с централизованным управлением и оптимизацией хранения. 
  
• «Кибер Бэкап». Продукт поддерживает многопоточное копирование (до 24 потоков на агент), безагентную интеграцию с российскими системами виртуализации (zVirt, «Горизонт-ВС»), имеет встроенный модуль защиты от шифровальщиков на базе ИИ для Linux, масштабируется до 20 тысяч виртуальных машин и 60 тысяч почтовых ящиков под единым управлением. 
• RuBackup (Группа Астра). Поддерживает полный, инкрементальный и дифференциальный бэкап, различные типы носителей (диски, ленты, облака), использует шифрование и электронную подпись. Компания позиционирует продукт не просто как систему бэкапа, а как платформу управления данными и обеспечения непрерывности (включая архивирование, репликацию, миграцию).
• Handy Backup. Российская программа для резервного копирования файловой системы, поддерживающая Windows (включая серверные версии) и имеющая версии для различных сегментов — от домашних пользователей до крупных предприятий. Продукт предназначен для резервного копирования, восстановления и синхронизации данных любых типов, включая файловые и SQL-версии программ системы «1С:Предприятие», а также поддерживает СУБД Postgres Pro Standard. Handy Backup также совместим с операционной системой РЕД ОС.
• «Циркон-резерв».Программный комплекс, предназначенный для создания отказоустойчивого кластера (кластер высокой доступности) и выполнения резервного копирования и восстановления информации. В состав входят служба кластеризации, служба менеджера ресурсов, сетевая клиент-серверная программа для резервного копирования и архивирования, а также графический web-интерфейс для управления через браузер. Решение имеет возможности для управления хранилищами данных, поиска и восстановления потерянных файлов.
• «Хайстекс Акура». Платформа позволяет организациям мигрировать рабочие нагрузки между платформами виртуализации и облачными средами, а также обеспечивающая аварийное восстановление данных, их резервное копирование и миграцию. Ключевой особенностью является поддержка S3 Object Lock, которая гарантирует неизменяемость резервных копий — их невозможно удалить или изменить технически. Продукт доступен на базе операционной системы РЕД ОС.

Open source и гибридные подходы

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

Bacula и Bareos — классические представители open-source-экосистемы. Bacula поддерживает гибкую настройку задач и работает с большинством современных платформ, включая российские ОС (Astra Linux, ALT Linux). Bareos — форк Bacula с активным развитием. Архитектура строится вокруг нескольких компонентов (Director, Storage Daemon, File Daemon), что даёт гибкость, но требует квалификации для настройки и поддержки.

В российском контексте нужно учитывать ограничения open source: отсутствие единой сертификации ФСТЭК, необходимость собственной поддержки, трудоёмкость интеграции с современными механизмами защиты. Тем не менее, для организаций с сильной ИТ-командой и без жёстких регуляторных требований это работоспособный вариант.

Лучшие практики резервного копирования по «3‑2‑1»

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

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

Андрей Кузнецов

Генеральный директор ООО "РуБэкап" (входит в "Группу Астра")

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

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

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

Семен Рогачев

Руководитель отдела реагирования на инциденты компании «Бастион»

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

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

Андрей Кузнецов

Генеральный директор ООО "РуБэкап" (входит в "Группу Астра")

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

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

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

Сергей Коловангин

Начальник отдела ИТ компании «Газинформсервис»

При обнаружении критических нарушений: А) создайте незамедлительно внеплановую резервную копию данных. Не надо разбираться с автоматизацией или регламентом РК — это потом. Сначала бэкап данных! Б) созданную копию отключите от сети, она должна быть offline, пока идёт разбирательство с нарушением. В) зафиксируйте факт нарушения и начинайте расследование причин с целью их устранения.

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

Решением будет план восстановления (Disaster Recovery Plan), в котором пошагово описано: кто принимает решение о восстановлении, где находятся резервные копии, какие учётные данные нужны, в каком порядке восстанавливаются системы. Раз в полгода проводите учения, когда команда изолирует заражённый сегмент и восстанавливает ключевой сервис из бэкапа «на чистую». Время восстановления должно измеряться и сравниваться с целевым RTO.

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

Включите в периметр резервного копирования конфигурации всей критической сетевой инфраструктуры. Используйте автоматизированные системы бэкапа конфигураций или встроенные средства сетевых устройств (копирование config на TFTP-сервер). И не забывайте, что эти конфигурации тоже нужно хранить в соответствии с правилом «3-2-1».

Резервное копирование — это постоянный процесс. Рост данных требует расширения хранилищ, обновление версий требует тестирования, смена ИТ-ландшафта требует пересмотра политик.

Закладывайте в бюджет ежегодное расширение бэкап-хранилищ на 20–30% (или на прогнозируемый рост данных), а также стоимость поддержки и обновлений ПО. Выделите ответственного за систему бэкапа, который будет следить за метриками, инициировать тесты восстановления и актуализировать документацию. Для крупных организаций имеет смысл создать выделенную роль «инженер по резервному копированию».

Разные системы имеют разную критичность. Платёжный шлюз нужно восстановить в течение 15 минут, а архив логов прошлого года может подождать и сутки. Бессмысленно тратить ресурсы на критически быстрое восстановление для некритичных данных.

Проведите классификацию всех систем по критичности и утвердите целевые RTO (время восстановления) и RPO (допустимая потеря данных, то есть как давно должен быть сделан бэкап). Для каждой группы настройте соответствующую частоту бэкапов и приоритет восстановления. Для самых критичных систем используйте синхронную репликацию или непрерывную защиту данных (CDP).

Заключение: чек-лист для самопроверки

Правило «3-2-1» остаётся фундаментом, но сегодня его недостаточно. Ниже — 10 пунктов, по которым можно оценить свои процессы резервного копирования. 

1. Есть ли у вас оригинал плюс минимум две независимые резервные копии критических данных?
   
2. Хранятся ли копии на физически разных типах устройств (например, диск и лента, локальный диск и облако)?
3. Находится ли хотя бы одна копия за пределами основной локации (offsite)?
4. Имеется ли хотя бы одна копия, которую нельзя изменить или удалить (immutable), либо физически изолированная от сети (офлайн)?
5. Проводите ли вы регулярные (не реже раза в квартал) проверки реального восстановления данных из бэкапов?
6. Используются ли для управления бэкапами отдельные учётные записи, не совпадающие с доменными администраторами?
7. Может ли учётная запись, создающая бэкапы, удалять или изменять старые копии?
8. Отслеживаете ли вы резкие изменения объёма или времени выполнения бэкапов (признак атаки)?
9. Есть ли письменный, протестированный и актуальный план восстановления (RTO/RPO для разных систем)?
10. Зашифрованы ли резервные копии, и хранятся ли ключи шифрования отдельно от самих данных?

Если хотя бы на три ответа «нет», вы в зоне риска. Если вы ответили «нет» на пункты 4, 5 или 6, действуйте немедленно.