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

Разбираем правило 3-2-1 по частям

В своей основе 3-2-1 — это протокол избыточности, спроектированный так, чтобы устранить единые точки отказа (SPOF) в системе хранения.

Три копии данных

Правило требует поддерживать как минимум три копии любого набора данных: продакшн-данные плюс две независимые резервные копии. Статистически такая избыточность серьёзно снижает вероятность одновременной потери. Если вероятность отказа одного диска равна 1/100, то вероятность одновременного отказа трёх независимых дисков падает до 1/1 000 000 — при условии, что отказы не коррелируют между собой.

Прим. перев. Оговорка про «независимые» отказы здесь принципиальная. На практике диски из одной партии с одной прошивкой, лежащие в одной полке, в одной стойке, в одном ЦОД — это не три независимых события. Поэтому 1/1 000 000 — это идеализированная нижняя граница, а не цифра, которую вы реально получите в продакшене. Ровно поэтому пункты про «разные носители» и «другая локация» в правиле не менее важны, чем сам факт трёх копий.

Два разных типа носителей

Две из копий должны лежать на разных типах носителей. Это требование снижает риск проблем, специфичных для конкретного носителя — например, багов прошивки в конкретной партии HDD или деградации оптических носителей. Использование разнородных технологий хранения — скажем, связки массивов на «крутящихся» дисках (HDD) с SSD или магнитной лентой — отвязывает резервные копии от уязвимостей конкретной технологии.

Одна копия за пределами площадки

Последняя копия должна находиться географически отдельно от продакшн-среды. Это защищает от катастроф уровня площадки: пожара, потопа или физической кражи. В современных архитектурах под «offsite» чаще всего понимают неизменяемое (immutable) облачное хранилище или физически отдельный ЦОД, подключённый по WAN.

Стратегии реализации в продвинутых архитектурах

Для энтерпрайз-уровня простого копирования файлов мало. Продвинутая реализация 3-2-1 требует автоматизации, верификации и интеграции с системами безопасности.

Оркестрация трёх копий

Серьёзные реализации опираются на технологии снапшотов и репликации, а не на банальное копирование файлов.

• Продакшн-данные. Лежат на высокопроизводительных массивах SAN/NAS.

• Первичный бэкап. Частые инкрементальные снапшоты, хранящиеся на отдельной локальной системе. Это даёт низкое время восстановления (RTO) для повседневных задач восстановления.

• Вторичный бэкап. Асинхронная репликация наборов резервных копий в третью локацию.

Разнообразие носителей в эпоху Software-Defined

В среде программно-определяемых хранилищ (SDS) различия физических носителей могут быть абстрагированы. Однако настоящее соответствие правилу требует физически разного «железа» под капотом.

• Disk-to-Disk-to-Tape (D2D2T). Некоторые считают это легаси, но LTO-лента остаётся жизнеспособным носителем для архивного хранения с воздушным зазором (air-gapped). Высокая плотность записи плюс защита от горизонтального распространения шифровальщиков — не самые плохие свойства.

• Disk-to-Disk-to-Cloud (D2D2C). Использование объектного хранилища (S3-совместимого) в качестве второго носителя. Чтобы получить честное различие носителей, локальный репозиторий может работать с блочным хранилищем, а облачный — с объектным.

Защита offsite-копии

Offsite-компонент — ключевая линия обороны против шифровальщиков.

• Неизменяемость (Immutability). Настройка политик Object Lock (WORM — Write Once Read Many) для облачных репозиториев. Это блокирует любому пользователю, включая администраторов, возможность удалить или изменить блоки бэкапа до истечения срока хранения.

• Воздушный зазор (Air-Gapping). Для повышенной безопасности применяется логический или физический air gap, при котором сеть управления резервным устройством не имеет постоянного подключения к продакшн-сети или интернету.

От Cloud4Y. Если задумываетесь, где разместить ту самую «третью копию за периметром», у нас сейчас как раз идёт акция для читателей Хабра: новым клиентам — скидка 20% на аренду облачных серверов для бизнеса по промокоду HABR20. Серверы размещаются в ЦОД уровня TIER III, SLA — 99,982%, можно взять готовую конфигурацию или собрать машину под задачу. Условия — на странице акции, перейдите по ссылке. На арендованном сервере (или связке из нескольких) удобно поднять свой бэкап-таргет под Veeam, Commvault, Acronis или любой другой привычный инструмент — и спокойно проверить схему 3-2-1 на реальных данных, прежде чем закладывать её в основную архитектуру.

Прим. перев. К теме air gap: за последние пару лет термин в индустрии заметно девальвировался — его стали лепить на любые решения, у которых бэкап-таргет «обычно не подключён к сети». Настоящий air gap означает, что хранилище недостижимо ни сетево, ни через identity, ни через API, ни через какой бы то ни было автоматизированный процесс — в момент инцидента. Если ваш «air-gapped» бэкап доступен оттуда же, откуда скомпрометированная среда, — это галочка для аудита, а не защита.

Плюсы и минусы модели 3-2-1

Модель надёжна, но в корпоративной среде у неё есть свои компромиссы.

Плюсы:

• Устойчивость. Максимизирует выживаемость данных при разных доменах отказа.

• Универсальность. Не привязана к конкретным вендорам железа или ПО для бэкапа.

• Соответствие требованиям. Закрывает требования к восстановлению после аварий в большинстве регуляторных рамок (GDPR, HIPAA, SOC 2).

Минусы:

• Стоимость. Содержание избыточного железа и плата за исходящий трафик из облака увеличивают совокупную стоимость владения (TCO).

• Сложность. Синхронизация по разнородным носителям и локациям требует серьёзных инструментов оркестрации.

• Задержки. Восстановление больших наборов данных из удалённого «холодного» хранилища может ухудшать RTO по сравнению с локальным восстановлением.

Инженерия отказоустойчивости

Стратегия 3-2-1 — не просто рекомендация, а фундаментальное архитектурное требование к долговечности данных. За счёт избыточности по числу копий, типам носителей и географии организации эффективно изолируют себя от катастрофической потери данных. Для опытного практика успех заключается не в самой концепции, а в её строгом применении: неизменяемое хранилище, air gap и автоматическая верификация.

Прим. перев. Канонические 3-2-1 за последние годы расширили до 3-2-1-1-0 (одна неизменяемая копия + ноль ошибок при восстановлении — версия Veeam) и 4-3-2 — именно потому, что классические три копии всё хуже справляются с современными атаками, где злоумышленник целенаправленно идёт за бэкапами. Различия между этими схемами заслуживают отдельного материала — постараемся его сделать.