Стратегия резервного копирования 3-2-1 — что это и как реализовать на практике
2026-05-25 13:15
3-2-1 — как держать ключ от квартиры в трех местах: один в сумке, один у соседа, один в банковской ячейке. Потерял сумку — заходишь через соседа. Сгорел дом у соседа — забираешь из банка. Правило, придуманное фотографом Питером Крогом в 2009 году, оказалось настолько универсальным, что 15 лет спустя его применяют в финансовом секторе, телекоме и госструктурах как минимальный стандарт защиты данных. В статье разберем, что именно означают «3 копии», «2 носителя», «1 off-site», как все это реализовать без переделки инфраструктуры и почему даже идеальная схема 3-2-1 не спасет, если не добавить иммутабельность поверх.
Что такое стратегия 3-2-1 и зачем она нужна
Это базовое правило для защиты данных от любого мыслимого сценария потери — от выхода диска до пожара в серверной. Принцип формулируется в три слова и проверяется за 5 минут аудита.
Расшифровка — 3 копии, на 2 носителях, 1 копия off-site
Три цифры читаются так. Три копии данных — оригинал плюс две независимые копии. Два разных типа носителя — например, основной массив на SAS-дисках и резерв на NL-SAS или ленте. Одна копия в другом физическом месте (off-site) — в другом ЦОД, в облаке, в банковской ячейке с лентами. Если соблюдаются все три условия одновременно — данные переживут практически любой инцидент, кроме одновременной катастрофы в двух географически разных местах.
История правила и почему оно до сих пор актуально
Крог сформулировал правило для фотографов: один и тот же кадр должен лежать на рабочем диске, на резервном диске и на еще одном носителе вне дома. За полтора десятилетия принцип ушел в корпоративные регламенты, попал в рекомендации NIST SP 800-209 по защите данных и стал отраслевым стандартом. Причина простоты: 3-2-1 не привязан к технологиям, он формулирует требование к архитектуре. Меняются носители (диски → SSD → объектное S3-хранилище), но логика остается.
Эволюция — 3-2-1-1-0, 4-3-2 и расширенные варианты
С появлением шифровальщиков и облачных бэкапов появились расширения. 3-2-1-1-0 от Veeam: к классике добавляется «1» — одна air-gap или иммутабельная копия, и «0» — ноль ошибок при тесте восстановления. 4-3-2 для критичных систем: 4 копии, 3 типа носителя, 2 разных провайдера / площадки. Все это надстройки над базовой 3-2-1, не альтернативы.
Какие сценарии закрывает стратегия 3-2-1
Каждая цифра в правиле появилась как ответ на конкретный класс инцидентов. Пробежимся по четырем главным.
Отказ диска или сервера
Одна копия данных на одном RAID-массиве — недостаточно. Несмотря на резервирование, диски иногда выходят парами, контроллеры умирают, прошивки бажат. Вторая копия на физически независимом носителе защищает от большинства инцидентов с железом. Если резервная копия живет внутри той же СХД — она умрет вместе с массивом, поэтому требование «2 носителя» — не формальность.
Ошибка администратора или пользователя
Самая частая причина потери данных — человек. Удалили не ту папку, дропнули таблицу, забыли где лежит важный файл. Снэпшоты СХД часто откатывают такие случаи за минуты, но классические бэкапы дают возможность вернуться на дни и недели назад. Это особенно ценно в сценариях, где ошибку заметили не сразу.
Атака шифровальщика
Шифровальщики — это тот случай, ради которого появилась «1» в 3-2-1-1-0. Атакующий получает админ-доступ, шифрует продуктив, а потом пытается стереть резервные копии. Если бэкап лежит на том же домене и доступен админ-аккаунту — он умирает вместе с боевыми данными. Защита — иммутабельный репозиторий или air-gap-копия, до которой шифровальщик не дотянется.
Пожар, потоп, физическое уничтожение площадки
Сгорел дата-центр, прорвало трубу в серверной, рухнул потолок. Все, что лежит в одном здании — пропало. Off-site копия в другом ЦОД или в облаке — единственное, что закроет такой сценарий. Это базовое требование любой DR-схемы и часть плана восстановления.
Как выбрать 2 разных носителя
«Два носителя» — это не «два массива одного вендора». Идея — в физической независимости: разные технологии хранения, разные точки отказа, разные жизненные циклы.
Диск + лента (LTO 8/9) — классика для крупных архивов
LTO-9 хранит 18 ТБ нативных / 45 ТБ со сжатием, пишет на 400 МБ/с, держит данные до 30 лет в шкафу. Картриджи стоят 8–15 тыс. рублей за штуку. Связка «дисковый бэкап для оперативного восстановления + лента для долгого хранения» — основа архитектуры для банков, госсектора и крупных предприятий. Спроектировать корректную систему резервного копирования с ленточной библиотекой Quantum Scalar или аналогом — отдельная инженерная задача.
Диск + объектное хранилище S3-совместимое
Современная альтернатива ленте. Бэкап-копия пишется на объектное хранилище: Yandex Cloud Object Storage, Selectel S3, VK Cloud S3 или собственная инсталляция MinIO. Дешево, масштабируется, поддерживает object lock для иммутабельности. Минус — зависимость от сети и тарификация исходящего трафика при восстановлении.
Диск + диск разных классов — NL-SAS + NVMe
Самый простой вариант для среднего бизнеса. Боевые данные на быстрых NVMe или SAS-дисках, бэкап-копия на медленных NL-SAS большой емкости. Два разных пула в одной СХД — формально это уже «два носителя», хотя строгая трактовка требует физически отдельных систем. Подобрать соответствующие системы хранения данных под двухуровневую архитектуру разумнее на этапе проектирования, а не докупать потом.
Почему «два массива одной модели» — не два носителя
Соблазн поставить второй такой же массив рядом — частый и ошибочный. Если у двух систем одинаковая прошивка с одним и тем же багом, одинаковые диски из одной партии с дефектом контроллера, одинаковые батареи кэша — они откажут одновременно. Принцип «двух носителей» подразумевает максимальную независимость точек отказа: разные технологии, разные поколения, разные вендоры.
Куда уносить off-site копию
Off-site — это про географию. Главное правило: расстояние между основной и резервной площадкой должно быть больше радиуса любой реалистичной катастрофы.
Второй ЦОД компании или партнерский ЦОД
Если у компании уже есть две площадки (например, офис + коммерческий ЦОД), задача решается репликацией между ними. Если своей второй площадки нет — арендуется стойка в colocation в другом городе. Идеально — другой регион, минимум 50–100 км. Это закрывает риски пожара, наводнения, локальных аварий с электричеством и связью.
Российские облачные хранилища с S3 API
Yandex Cloud, Selectel, VK Cloud, Cloud.ru, MTS Cloud — все имеют S3-совместимые сервисы с поддержкой object lock. Бэкап-софт умеет работать с ними нативно. Тарифы — от 1,5 до 4 рублей за ГБ в месяц в зависимости от класса хранения (горячий, холодный, ледяной). Для среднего бизнеса с объемом бэкапа 5–20 ТБ это разумный способ закрыть требование off-site без своей второй площадки. Через объектное хранилище удобно держать долгосрочные копии — например, как сетевое хранилище с S3-фронтендом для интеграции с Veeam, RuBackup или Кибер Бэкап.
Лента в сейфе или у курьера с регулярной ротацией
Самый старомодный и самый защищенный вариант. Лента после записи физически вынимается из библиотеки, увозится в банковскую ячейку или офисное хранилище в другом городе. Никакая сетевая атака до нее не дотянется. Минус — медленное восстановление: курьер, перевозка, монтаж в библиотеку, чтение. Для критичных архивов 5–10-летнего хранения — рабочая схема, особенно для финансового и государственного сектора.
Иммутабельные копии и расширение до 3-2-1-1-0
Расширение возникло как ответ на эпидемию шифровальщиков. Если злоумышленник получает доступ к бэкап-серверу, обычные копии он удаляет вместе с данными. Иммутабельная копия — это копия, которую нельзя изменить или удалить до истечения срока retention, даже под root.
Object lock в S3 — WORM на N дней
S3 Object Lock — это механизм Write Once Read Many. Объект, помеченный lock-флагом, нельзя удалить или перезаписать до окончания срока удержания. Поддерживается в двух режимах: governance (можно снять флаг с особыми правами) и compliance (нельзя снять вообще, даже владельцу). Российские облака — Yandex Cloud, Selectel, VK Cloud — поддерживают object lock на срок до 100 лет. Veeam, RuBackup, Кибер Бэкап работают с такими копиями нативно.
Альтернатива облачному object lock — собственный репозиторий с иммутабельностью на уровне ОС. Veeam Hardened Repository работает поверх Linux с immutable XFS: даже root не может изменить или удалить данные до истечения срока. RuBackup Immutable Storage (с версии 2.1) дает то же самое с retention 1–3650 дней. Кибер Бэкап от Группы КИП поддерживает S3 Object Lock и собственные защищенные хранилища с шифрованием AES-256.
Air-gap копия — физически отключенный носитель
Самый радикальный вариант защиты. Лента после записи извлекается, диск отключается от сети, картридж кладется в сейф. Никакая сетевая атака физически не может достичь такой копии. Air-gap часто комбинируется с object lock: ежедневные бэкапы в S3 с иммутабельностью + еженедельная лента в сейфе для самых катастрофических сценариев.
Как реализовать 3-2-1 в реальной инфраструктуре
Архитектура зависит от масштаба. Дам три типовые схемы.
Схема для малого бизнеса (1–5 серверов)
Боевые данные на основной СХД или прямо на серверах. Первая копия — на NAS-устройстве рядом (Synology, QNAP, российский Aquarius или Forsec NAS). Off-site копия — в Yandex Cloud Object Storage с object lock на 30–90 дней. Бэкап-софт — Кибер Бэкап Standard или RuBackup для 2–3 серверов. Бюджет — 200–400 тыс. рублей единоразово плюс 5–15 тыс. в месяц за облако.
Схема для среднего бизнеса (10–50 серверов)
Основные серверы и СХД в офисной серверной или коммерческом ЦОД. Локальный бэкап-репозиторий на отдельном сервере с RAID 6 (объем — 2–3× от продуктива). Веб-репликация на second-site (партнерский ЦОД или облако) каждые 6–12 часов. Иммутабельный репозиторий локально на Hardened Linux. ПО — Veeam Backup & Replication Enterprise, RuBackup Standard или Кибер Бэкап Advanced. Бюджет — от 1,5 млн рублей CapEx + 30–80 тыс. в месяц OpEx.
Схема для крупного предприятия (100+ серверов, два ЦОД)
Активная-активная конфигурация двух ЦОД с синхронной репликацией продуктива. Локальные бэкапы в каждом ЦОД на дисковые appliance с дедупликацией (Quantum DXi, Аэродиск Backup). Ленточная библиотека LTO-9 для долгосрочного хранения. Облачная копия для критичных систем в третий регион. ПО — Veeam Enterprise Plus, Commvault, RuBackup Enterprise или связка. Полноценный DR-план с целевыми RPO 15 минут и RTO 1 час для боевых систем. Ориентировочный OpEx: от 200–500 тыс. рублей в месяц (лицензии ПО + облачное хранение + сопровождение).
Тестирование восстановления и RPO/RTO
Бэкап, который никто не восстанавливал, — это не бэкап, а файл на диске. Регулярная проверка — обязательная часть процесса.
Регулярный тест восстановления — раз в квартал минимум
NIST SP 800-209 рекомендует тестировать восстановление критичных систем не реже раза в квартал. На практике в зрелых компаниях делают чаще: ежемесячно — точечная проверка отдельных машин, ежеквартально — полный DR-сценарий с подъемом инфраструктуры на второй площадке. Цель не «проверить бэкап», а проверить документацию и навыки команды: сколько на самом деле занимает восстановление, кто принимает решения, что забыли в плане.
Sandbox-восстановление в виртуальном окружении
Современные бэкап-системы умеют поднимать восстановленные ВМ в изолированной sandbox-сети для проверки целостности. Veeam SureBackup, RuBackup Sandbox, Кибер Бэкап Test Restore — все это автоматизирует проверку: машина поднимается, прогоняется набор тестов (запуск служб, доступность сети, целостность БД), отчет уходит админу. Никаких ручных операций, никакого влияния на продуктив.
Метрики — фактический RPO/RTO vs целевой
RPO (recovery point objective) — допустимая потеря данных в часах или минутах. RTO (recovery time objective) — допустимое время простоя. Целевые значения прописаны в SLA для бизнеса. Фактические — выясняются на тесте восстановления. Расхождение «целевой RTO 1 час, фактический 6 часов» — повод пересматривать архитектуру или бюджет. Восстановление одной ВМ 100 ГБ из инкрементальной цепочки Veeam занимает 5–15 минут при skip-zero-blocks. Большой массив на терабайты — часы.
Типовые ошибки при внедрении 3-2-1
Три ошибки в реализации — не в понимании угроз (они разобраны выше), а в том, как именно строится схема.
Две копии на одном массиве — не считаются
Создали два разных пула на одной СХД, написали туда бэкапы — формально две копии. Реально — одна. При логическом отказе массива (порча метаданных, баг прошивки, шифрование на уровне block layer) оба пула умрут вместе. Правило «два носителя» означает физически разные устройства, желательно от разных вендоров.
Off-site копия без верификации целостности
Отправили бэкап в облако, увидели в логе «успешно», забыли. Через полгода понадобилось восстановить — оказалось, что половина файлов повреждена при передаче, а никто не проверял. Любой off-site репозиторий нужно регулярно прогонять через verification job: чтение всех блоков с пересчетом хеша. Это медленно и дорого по трафику, но без этого off-site копия превращается в фикцию.
Отсутствие иммутабельности при защите от шифровальщиков
Статистика последних лет: около 70% инцидентов с ransomware включают попытку стереть бэкап-репозитории. Если бэкап доступен админ-аккаунту, он удаляется вместе с продуктивом. Без иммутабельного слоя (object lock, immutable XFS, air-gap) 3-2-1 не защищает от шифровальщика — это и есть смысл «1» в расширении 3-2-1-1-0.
Хотите построить или проверить свою стратегию резервного копирования? Наши инженеры подберут СХД для основной и второй копии, ленточный накопитель LTO или S3-хранилище для off-site, спроектируют иммутабельный репозиторий. Закажите аудит ИТ-инфраструктуры — после него будет понятна реальная схема защиты и ее стоимость.
Заключение
3-2-1 — это не модный термин, а минимальный уровень защиты данных, который должен быть в любой компании старше двух лет. Три копии, два носителя, одна off-site — закрывают почти все сценарии потери: от вылета диска до пожара в серверной. Современные расширения добавляют иммутабельность (защита от шифровальщиков) и регулярное тестирование (защита от «бэкапа, который не работает»). Реализация зависит от масштаба: для малого бизнеса хватает NAS + облако с object lock, для среднего — связка локальный репозиторий + второй ЦОД + Veeam или RuBackup, для крупного — два ЦОД + лента + облачная копия в третий регион. Главное — считать не «купили ли мы софт», а проверять восстановление по факту: четверть всех серьезных инцидентов раскрывает, что бэкапы есть, но не работают. RPO и RTO — это цифры в договоре, не пожелания.
Ответы на частые вопросы
Что значит правило 3-2-1 в резервном копировании?
Три копии данных (оригинал плюс два резерва), на двух разных типах носителей (диск + лента, диск + облако, разные классы дисков), одна копия — в другом физическом месте (другой ЦОД, облако, банковская ячейка). Закрывает все типовые сценарии потери, от отказа диска до пожара.
Можно ли две копии хранить в одном ЦОД?
Формально — да, если они на разных типах носителей и разных физических устройствах. Но это не дает полноценного 3-2-1: пожар, потоп, авария электропитания в этом ЦОД уничтожат обе. Off-site копия в другой локации — обязательное условие правила.
Что такое immutable backup и зачем он нужен?
Это копия, которую нельзя изменить или удалить до истечения срока retention, даже под root. Реализуется через S3 Object Lock, immutable XFS в Veeam Hardened Repository, RuBackup Immutable Storage. Защищает от шифровальщиков, которые получили доступ на уровне админа.
Подходит ли облако для off-site копии?
Да, и это самый частый сценарий в среднем бизнесе. Российские облака (Yandex Cloud, Selectel, VK Cloud) поддерживают S3 Object Lock с retention до 100 лет, имеют интеграции с Veeam, RuBackup и Кибер Бэкап. Тариф — 1,5–4 руб/ГБ в месяц в зависимости от класса хранения.
Что такое стратегия 3-2-1-1-0?
Расширение Veeam от классики. К «3-2-1» добавляется «1» — одна иммутабельная или air-gap копия, и «0» — ноль ошибок при тесте восстановления. Иммутабельность защищает от шифровальщиков, регулярный тест — от ситуации «бэкап есть, но не восстанавливается».
Как часто тестировать восстановление?
Минимум раз в квартал для критичных систем по NIST SP 800-209. На практике зрелые компании делают точечные тесты ежемесячно (отдельные ВМ через sandbox) и полный DR-сценарий раз в квартал или полгода. Без регулярного теста бэкап превращается в файл, в работоспособности которого никто не уверен.
Можно ли заменить ленту на объектное хранилище?
В большинстве сценариев — да. S3 с object lock закрывает те же требования к иммутабельности и долгосрочному хранению, что и лента, при сопоставимой стоимости. Лента остается актуальной для очень больших объемов (петабайты), для случаев, где нужен полный air-gap, и для государственного сектора с регуляторными требованиями.
Какую систему резервного копирования выбрать под 3-2-1 в РФ?
Для среднего бизнеса в 2026 году рабочие варианты — RuBackup (российский вендор, поддержка иммутабельных репозиториев и Linux/Windows-агентов), Кибер Бэкап от Группы КИП (S3 Object Lock, AES-256), Veeam Backup & Replication (если есть действующие лицензии и совместимые гипервизоры). Выбор — по совместимости с гипервизорами, поддержке нужного объектного хранилища и бюджету на лицензии.