Правило 3-2-1 и почему к нему дописали ещё два числа

Классическая формула

Правило 3-2-1 сформулировали ещё до того, как облака стали массовыми, и оно держится до сих пор:

• 3 копии данных, считая оригинал;
• на 2 разных типах носителя или в двух разных системах хранения;
• 1 копия вне площадки.

Логика простая: одна авария не должна дотянуться до всех копий сразу.

Почему три, а не две

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

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

Почему два разных носителя

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

Поэтому копии разносят по разной природе хранения: локальные диски и объектное хранилище, файловая система сервера и NAS, облако одного провайдера и облако другого.

В облачном мире «два носителя» читается как «две независимые системы»: диск виртуалки и бакет объектного хранилища это разные системы, даже если физически стоят в одном ЦОД.

Почему одна копия вне площадки

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

Off-site копия это другой ЦОД, другой регион, другой провайдер или просто диск, который увозят физически. Важно не расстояние само по себе, а отсутствие общей точки отказа: общего питания, общей сети, общего аккаунта.

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

Дописанные числа: 3-2-1-1-0

Шифровальщики изменили модель угроз, и к правилу добавили ещё две позиции.

1 копия должна быть иммутабельной или офлайновой. В объектных хранилищах это блокировка объектов (object lock), в лентах и съёмных дисках — сам факт отключения от сети.

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

Здесь важна деталь, которую часто пропускают: иммутабельность бывает разной крепости. У S3 Object Lock два режима. В governance удалить объект по-прежнему можно, если у пользователя есть право s3:BypassGovernanceRetention, и консоль AWS отправляет заголовок обхода по умолчанию. В compliance не удалит никто, включая root, пока не истечёт срок; единственный обходной путь — закрыть весь аккаунт.

В Azure та же логика: пока политика хранения не заблокирована (unlocked), её можно сократить или снять, и защита начинается только после блокировки.

Поэтому «включили object lock» ещё не ответ. Вопрос в том, в каком режиме он включён и кто может этот режим изменить.

0 ошибок при проверке. Копия считается копией только после успешной проверки: контрольные суммы сошлись, тестовое восстановление прошло.

Как это выглядит на практике

Небольшой сервис:

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

Схема не самая дорогая, а закрывает и отказ диска, и удаление, и потерю провайдера, и шифровальщика.

Что важно запомнить

Три копии дают право на одну ошибку: битый бэкап не оставляет вас ни с чем.

Два разных носителя защищают от одинакового отказа однотипных устройств.

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

Иммутабельная копия защищает от того, у кого уже есть права на удаление, но только в жёстком режиме: governance у S3 штатно обходится, compliance нет.

Копия без успешной проверки не считается копией.

Дальше разберём, из чего складывается сам бэкап: полные, инкрементальные и сколько всего этого хранить.