S3 Object Lock, immutable и все-все-все: как это реализовано

Мы уже разбирали WORM на ленте. Сегодня продолжим данную тему и посмотрим что предлагают нам альтернативные варианты, нацеленные на защиту резервных копий. Поговорим об S3 Object Lock и immutable-репозиториях, а так же посмотрим, что могут предложить другие вендоры СХД для решения поставленных задач. У каждого крупного производителя СХД есть своя фирменная реализация похожей идеи, и различия между ними — не просто маркетинговые названия, а реальные архитектурные решения с разной моделью доверия. В этой статье разберём, что предлагают Dell EMC, HPE, ExaGrid, Quantum DXi, YADRO, NetApp, Pure Storage, Huawei — и отдельно расскажу про Object First.

Общая логика, прежде чем идти по вендорам
Все реализации, которые мы разберём ниже, решают одну и ту же задачу, но на разных уровнях стека:

• WORM на ленте — физический уровень (чип картриджа + привод).
• S3 Object Lock — уровень объектного хранилища (облачного или локального).
• Immutable-репозиторий — уровень файловой системы конкретного сервера.
• Фирменные механизмы вендоров СХД — уровень самого дискового массива: томов или файловых систем.

Сначала — что такое S3 Object Lock
Прежде чем идти по вендорам СХД, стоит явно раскрыть механизм S3 Object Lock на примере AWS — потому что дальше по тексту термины Governance и Compliance будут всплывать снова и снова, и это не совпадение: индустрия хранения данных фактически заимствовала терминологию AWS как негласный стандарт именования для похожих механизмов.
Технически S3 Object Lock работает на уровне версии объекта в S3-бакете (то есть требует включённого версионирования) и предлагает два способа защиты:

• Retention period — к версии объекта привязывается конкретная дата, до которой её нельзя удалить или перезаписать.
• Legal hold — блокировка без привязки к дате, действует до тех пор, пока её явно не снимут; полезна, когда точный срок хранения заранее неизвестен.

А дальше — те самые два режима, к которым отсылают уже все вендоры СХД:

• Governance mode — обычные пользователи не могут удалить или изменить защищённую версию объекта, но у пользователей со специальным правом есть возможность обойти защиту досрочно.
• Compliance mode — защищённую версию объекта нельзя удалить или изменить абсолютно никому, включая root-пользователя самого AWS-аккаунта, до истечения срока хранения. Единственный теоретический способ обойти — удалить весь AWS-аккаунт целиком.

S3 Object Lock официально оценён независимой компанией Cohasset Associates на соответствие регуляторным требованиям финансового регулятора — то есть Compliance mode формально признан эквивалентом традиционного WORM-хранения. Именно эта независимая оценка и терминология Governance/Compliance стали ориентиром, под который позже подстроились и большинство вендоров СХД при реализации собственных решений.

Важный нюанс: S3 Object Lock — это API, а не привязка к конкретному облаку. Он реализован не только в самом AWS S3, но и в S3-совместимых системах доступных как у Российсикх облачных провайдеров, так и у большинства on-prem объектных хранилищ на базе opensource решений или в виде железных решений.

«Дедулицирующие» СХД
Возможно и не совсем правильно их так называть, но тем ни менее, я так называю СХД, постоенные и нацеленные на хранения резервных копий (кстати, большую таблицу-сравнения этих решения я выкладывал на rbug.ru).

Dell EMC (PowerProtect DD / Data Domain) — Retention Lock
У Dell защита организована вокруг ключевой архитектурной единицы Data Domain — MTree (логический раздел файловой системы, к которому и подключается backup-приложение). Retention Lock включается не на уровне всей системы, а именно на уровне конкретного MTree — то есть можно держать на одном Data Domain как обычные, так и защищённые разделы одновременно.

Governance и Compliance — не просто переключатель, а отдельные лицензии
Здесь важная деталь, которую легко упустить: Governance и Compliance — это не два режима одной функции, а два отдельных лицензируемых продукта (Retention-Lock-Governance и Retention-Lock-Compliance), которые можно ставить как по отдельности, так и вместе. Это сразу задаёт архитектурную границу: одна лицензия не даёт автоматически доступ ко второму режиму.

Роль Security Officer — обязательный второй набор прав
Для включения Compliance-режима обязательно создание отдельной учётной записи с ролью security — так называемого Security Officer. Это не просто ещё один администратор с расширенными правами, а по сути реализация принципа разделения полномочий: чтобы включить RLC, нужно выйти из-под обычного Admin-аккаунта и зайти именно под Security Officer, подтвердить операцию, а затем вернуться к Admin для продолжения настройки. Дальше эта роль требуется для любых потенциально разрушительных операций на защищённых MTree.

Включение Compliance — необратимая операция с даунтаймом
В отличие от Governance, включение Retention Lock Compliance на всей системе требует перезагрузки и временной недоступности системы — это осознанное архитектурное решение, а не побочный эффект. Одновременно с включением администратор обязан задать лимит и частоту изменения системных часов (например, «не более 12 часов сдвига, не чаще раза в сутки») — и эти параметры нельзя изменить впоследствии. Это прямая защита от классической атаки на любую time-based защиту.

HPE StoreOnce Catalyst — ISV-Controlled Data Immutability
StoreOnce работает через фирменный протокол Catalyst — backup-приложение напрямую создаёт на StoreOnce Catalyst Store, который и служит целевым репозиторием для заданий резервного копирования, с дедупликацией на стороне источника. Immutability здесь называется ISV-Controlled Data Immutability (ISV-DI) — данные, записанные в Catalyst Store, помечаются неизменяемыми через интерфейс с конкретным backup-приложением.

Dual Authorization — разделение ролей на уровне протокола, а не просто прав доступа
Ключевой механизм здесь — Dual Authorization (DA), и он выключен по умолчанию — это первое, на что стоит обратить внимание при развёртывании, потому что без него immutability в принципе нельзя настроить со стороны СРК. DA требует двух принципиально разных ролей:

• Administrator — инициирует операцию (например, включение immutability на Catalyst Store).
• Security Officer — отдельная роль, которая может только просматривать, одобрять или отклонять запросы Dual Authorization и смотреть мониторинг — никакого доступа к управлению данными у неё нет вообще.

Под защиту Dual Authorization попадают конкретные операции: отключение immutability, удаление всего Catalyst Store, изменение системной даты и времени (важная деталь — HPE применяет не абсолютную установку времени, а временной сдвиг (time delta), что также обеспечивает time-based защиту).

Отдельно стоит отметить: root-аккаунт StoreOnce никогда не раскрывается конечному пользователю, и HPE принципиально не предоставляет shell-доступ к системе. Это устраняет целый класс атак через известные или ещё не обнаруженные уязвимости в самой оболочке ОС.

Технические ограничения immutability, о которых стоит знать заранее:

• На стороне самого StoreOnce задаётся параметр «Maximum ISV Controlled Data Retention» — потолок, выше которого СРК физически не может установить свой собственный retention. Официальная рекомендация — ставить его на максимум (365 000 дней), чтобы потолок никогда не оказался ниже реальных нужд бэкап-политики. При этом сам диапазон значений immutability, которым управляет СРК через ISV-интерфейс, — от 7 до 9999 дней.
• Immutability действует только на объекты, созданные операциями backup — если объект впоследствии участвует в операции copy или consolidation, эта производная копия иммутабельность не наследует.
• Включение immutability на уже существующем Catalyst Store защищает только новую или продолжающуюся цепочку бэкапов — созданные ранее цепочки защиты не получают.
• Отдельное предупреждение из документации: все описанные меры защиты StoreOnce теряют смысл, если интерфейс iLO остаётся доступен и не защищён — через iLO устройство можно физически стереть удалённо, в обход абсолютно всех программных механизмов Catalyst.

Производительность Gen4+ — поворот в позиционировании
Ещё один момент: исторически дедуп-appliance вроде StoreOnce рекомендовались к использованию, как вторичный уровень хранения (архивную/капасити-цель), а не основной репозиторий. Но начиная с поколения Gen4+, где метаданные вынесены на flash-накопители, HPE по результатам собственного тестирования и валидации Veeam Ready Repository уже прямо рекомендует использовать эти модели как основной репозиторий — с приростом IOPS для Instant VM Recovery до 20 раз и пропускной способностью 100–400 МБ/с на поток. Это меняет прежнее позиционирование StoreOnce исключительно как «медленной, архивный» слой — во всяком случае, для топовых моделей линейки.

ExaGrid — Retention Time-Lock
ExaGrid стоит особняком среди уже разобранных appliance-вендоров благодаря архитектуре, которую сама компания называет Tiered Backup Storage — и именно эта архитектура, а не отдельная «функция иммутабельности», лежит в основе их защиты от ransomware.

Двухуровневая архитектура как основа защиты
Данные сначала попадают в Landing Zone — недедуплицированный, обращённый к сети дисковый кэш, который обеспечивает быстрое резервное копирование и особенно быстрое восстановление (в этом слое лежит недедуплицированная копия последних бэкапов). Затем данные асинхронно перетекают в Repository Tier — второй уровень, который физически не адресуется по сети вообще. ExaGrid называет это tiered air gap: репозиторий существует и обслуживается только собственным программным обеспечением ExaGrid, а не как примонтированный сетевой ресурс, до которого можно было бы дотянуться извне.

Ключевое следствие такой архитектуры: даже если шифровальщик доберётся до Landing Zone и зашифрует свежие бэкапы, это никак не затронет уже дедуплицированные объекты в Repository Tier — они физически находятся вне досягаемости той же сетевой атаки, а не просто защищены программным флагом.

Immutable-объекты и отложенное удаление
Внутри Repository Tier данные хранятся как дедуплицированные объекты и метаданные, которые никогда не изменяются — возможно только создание новых объектов или удаление старых по истечении retention. Но и здесь есть дополнительный защитный слой — Retention Time-Lock (RTL): любой запрос на удаление, даже легитимный (в рамках нормальной ротации бэкапов), исполняется не сразу, а с задержкой в заданное число дней (по умолчанию — 10, конфигурируется с шагом в 1 день). По умолчанию эта отложенная защита требует всего около 10% дополнительного места в репозитории.

Auto Detect & Guard — поведенческая защита поверх задержки
С октября 2025 года у ExaGrid появилась ИИ-надстройка над RTL — Auto Detect & Guard. Система обучается на паттернах повседневных операционных удалений (обычная ротация бэкапов) и, если видит запрос на удаление, который выбивается из привычного паттерна (например, аномально массовое удаление, характерное для атаки шифровальщика, пытающегося зачистить историю бэкапов), автоматически продлевает задержку удаления и уведомляет ИТ-команду — вместо того чтобы просто исполнить подозрительный запрос по истечении обычного таймера. Изменение самой настройки Time-Lock защищено двухфакторной аутентификацией (2FA).

Quantum DXi — Secure Snapshot и Retention Lock
Иммутабельность на DXi реализована через два разных, независимых механизма:

• Secure Snapshot — защита на уровне всей системы: point-in-time снимки shares, партиций или LSU (logical storage units для протокола OST) изолируются в специальный non-network-addressable blockpool прямо внутри appliance. Ключевая формулировка из документации Quantum: у такого снапшота вообще нет datapath-доступа — то есть атакующий не может добраться до него ни через смонтированную файловую систему, ни через GUI, ни через REST API DXi. Это концептуально очень похоже на «tiered air gap» у ExaGrid, только реализовано как изолированный пул, а не отдельный физический уровень хранения.
• Retention Lock — классический файловый WORM: применяется на уровне отдельных файлов внутри NAS-шары, но только для протокола NFS с включённой дедупликацией — то есть область применения у́же, чем у Secure Snapshot, зато защита гранулярнее (можно защитить конкретный файл, а не весь снапшот целиком).

Место DXi в более широкой экосистеме Quantum
Отдельно стоит отметить, как Quantum позиционирует DXi в общей линейке защиты данных: appliance выступает быстрым тиром для оперативного восстановления, а для по-настоящему долгосрочной и максимально устойчивой к атакам копии данные реплицируются или тирятся дальше — либо в объектное хранилище ActiveScale (S3-совместимое, с собственным Object Lock), либо на ленточные библиотеки Scalar с их Active Vault, о которых мы говорили в статье «Обзор актуальных лент: IBM, HPE, Quantum — что выбрать». То есть DXi — не самостоятельная крепость, а один из уровней в общей многоуровневой стратегии Quantum, что логично перекликается с идеей 3-2-1-1-0.

YADRO — TATLIN.BACKUP
Раз уж мы разобрали западных производителей backup-таргетов — стоит сразу закрыть тему и российским аналогом TATLIN.BACKUP от YADRO, который прямо позиционируется производителем и независимыми обзорами как отечественный аналог Dell Data Domain (и по совместительству HPE StoreOnce). Причём архитектурное сходство настолько прямое, что в обзоре на Хабре проводится буквальное сопоставление: там, где у Dell — MTree, у YADRO — VFS; там, где у Dell — протокол DD Boost, у YADRO — свой протокол T-BOOST. Кстати сейчас у меня на тесте находится TATLIN.BACKUP.M и скорее всего скоро выйдет обзор на наго на Хабре.

T-BOOST — дедупликация на источнике
T-BOOST — фирменный протокол YADRO, концептуально идентичный DD Boost у Dell и Catalyst у HPE: специальный агент устанавливается прямо на источнике данных (сервере с бэкап-агентом) и выполняет часть дедупликации ещё до передачи данных по сети — на систему хранения уходят только уникальные блоки. По заявлению производителя, это снижает среднюю нагрузку на сеть более чем в 10 раз и ускоряет запись резервных копий до 3 раз. Дедупликация — глобальная, inline, блоком переменной длины, где границы блока определяются автоматически в зависимости от типа и структуры данных.

Три режима снапшотов
Начиная с версии TATLIN.BACKUP v1.3 в системе реализована технология мгновенных снимков сразу в трёх режимах с разным уровнем защиты — и вот тут проявляется прямая параллель с логикой WORM/immutability:

• Basic — обычные снапшоты со сроком хранения, управляются напрямую администратором СХД без ограничений.
• Secure — снапшоты, доступ к которым возможен только через отдельного пользователя с ролью Security, то есть обычный администратор СХД такой снапшот удалить не может.
• Locked — самый строгий режим: снимок нельзя удалить или изменить вообще никем, включая администратора. Снять эту защиту может только служба поддержки самой YADRO. Именно этот режим предназначен для сценариев, где данные нужно зафиксировать «навсегда» без возможности отмены изнутри компании.

С точки зрения интеграции TATLIN.BACKUP уже подтвердил совместимость с российским бэкап-ПО — например, с Кибер Бэкап, а также с решениями для миграции/защиты данных, вроде MIND Guard.

Теперь упомянем пару «классических» СХД, которые могут использоваться под хранение резервных копий и при этом обеспечивать их защиту

NetApp — SnapLock
У NetApp решение самое давнее и, пожалуй, самое зрелое технически из всех — SnapLock, реализующий WORM именно на уровне файлов через стандартные сетевые протоколы NFS и CIFS/SMB. Том NetApp превращается в обычный NAS-таргет, на который backup- или архивное приложение пишет файлы по сети, и они становятся неизменяемыми.

Технически SnapLock существует в двух режимах — Compliance и Enterprise, и разница между ними принципиальна:

• SnapLock Compliance защищает WORM-файлы на уровне диска — committed-данные нельзя удалить или изменить вообще никем до истечения retention, единственный способ уничтожить их раньше срока — физически изъять и уничтожить сами диски.
• SnapLock Enterprise защищает на уровне файла, но оставляет доверенному администратору возможность удалить WORM-файл раньше срока через специальную аудируемую процедуру privileged delete — компромисс между жёсткостью защиты и операционной гибкостью.

Ключевая деталь, которая защищает retention от подмены системного времени — ComplianceClock: программные, защищённые от изменения часы, инициализируемые администратором один раз и работающие дальше только на основе аппаратных тиков. После инициализации сдвинуть их вперёд невозможно никакими правами доступа — это исключает классическую атаку на любую time-based защиту. У каждого SnapLock-тома есть собственные Volume ComplianceClock, независимые от системных часов кластера в целом.

SnapLock хорошо стыкуется и с остальной экосистемой NetApp: том можно использовать как цель для SnapVault (WORM-защита снапшотов на вторичном хранилище) и реплицировать через SnapMirror на другую географическую площадку с сохранением WORM-свойств копии.

Pure Storage — SafeMode
Небольшая ремарка: в феврале 2026 года Pure Storage официально сменила название на Everpure, но я продолжу пока называть его Pure Storage.

SafeMode у Pure Storage не просто делает снапшоты immutable — он делает их ineradicable (невозможными для окончательного стирания). Технически это работает так: снапшоты у Pure являются чисто метаданными (никакого физического копирования блоков при создании снапшота не происходит), а SafeMode добавляет к этому дополнительный уровень — даже полное удаление тома не стирает данные немедленно. Они попадают в очередь на «эрадикацию» (не знаю как ещё можно адаптировать на русский язык — eradicable) с настраиваемым таймером — по умолчанию 24 часа, но можно растянуть вплоть до 400 дней.

Но по-настоящему нестандартна здесь модель доверия при досрочном снятии защиты. Чтобы обойти SafeMode раньше срока, нужно:

1. Иметь как минимум двух заранее авторизованных сотрудников организации-клиента, у каждого из которых есть свой уникальный шестизначный PIN, выданный технической поддержкой Pure.
2. Оба этих сотрудника должны одновременно связаться с технической поддержкой Pure Storage и подтвердить операцию.

То есть Pure сознательно вынес финальное решение за пределы организации-клиента. В одиночку — ни один отдельно взятый администратор, даже с полным набором прав в системе, физически не может обойти защиту без звонка в компанию-производителя.

Huawei — OceanProtect
Архитектурно Huawei выстраивает защиту вокруг трёх взаимодополняющих компонентов:

WORM на уровне файловой системы
Классический WORM применяется на уровне неймспейса backup-хранилища — администратор задаёт защитный период (protection period), в течение которого файлы доступны только на чтение. Технически интересна асимметрия правила: защитный период можно продлить, но нельзя сократить — то есть у администратора остаётся возможность усилить защиту задним числом, но не ослабить её раньше изначально заданного срока. После истечения периода данные становятся доступны для обычного удаления.

Secure Snapshot — WORM на уровне снапшотов
Отдельный механизм — Secure Snapshot, тесно интегрированный с фирменной технологией снепшотов Huawei HyperCDP. Здесь диапазон защитного периода особенно широкий — от 1 дня до 20 лет, с той же асимметричной логикой (можно продлить, нельзя сократить), и опциональным автоматическим удалением снапшота по истечении срока, если администратор заранее это разрешил. Снапшот можно создавать как вручную, так и по расписанию непосредственно из механизма HyperCDP.

Air Gap как отдельная физически изолированная зона
В отличие от чисто логической изоляции у некоторых конкурентов, Huawei описывает свою реализацию air gap как создание физически обособленной зоны хранения, куда данные реплицируются, а канал репликации автоматически разрывается после завершения передачи — то есть связь между продуктивной системой и изолированной зоной не остаётся постоянно открытой, а поднимается только на время самой репликации и затем принудительно закрывается.

OceanCyber — отдельный appliance для обнаружения атак
Пожалуй, самая нетипичная часть экосистемы Huawei по сравнению с другими разобранными вендорами — выделенный OceanCyber Data Security Appliance, отдельное устройство, специализирующееся именно на AI-детекции атак, а не на хранении данных. Оно анализирует резервные копии на признаки шифрования — по заявлению Huawei, отслеживая аномалии в изменении размера файлов, энтропии содержимого и схожести файлов между собой, — и заявляет точность обнаружения около 99,9% при производительности анализа до 50 ТиБ/ч. OceanCyber интегрируется с OceanProtect через единую консоль управления политиками безопасности, которая к тому же охватывает не только backup-хранилище, но и первичные системы хранения линеек OceanStor Dorado и OceanStor Pacific — то есть управление ransomware-защитой единое для продакшена и бэкапов одновременно, а не два разрозненных инструмента.

Такой трёхкомпонентный подход (WORM + Secure Snapshot + физический air gap + отдельный ИИ-детектор атак) концептуально ближе к комплексной платформе, чем к точечному механизму вроде Retention Lock — Huawei с самого начала продаёт это как целостное решение против ransomware, а не как отдельную immutability-функцию поверх существующего хранилища.

Object First
Компанию Object First основали Ратмир Тимашев и Андрей Баронов — те же люди, которые в своё время создали саму компанию Veeam. И в начале 2026 года Veeam официально приобрела Object First, включив её appliance в собственную продуктовую линейку.

Object First — это не совсем классическая СХД, а специализированный appliance именно для Veeam. Технически внутри — нативная реализация S3 Object Lock (та же логика, что мы разбирали для облачного AWS S3, но развёрнутая локально, у себя в серверной) поверх собственного Linux.

Что здесь сделано интересно с инженерной точки зрения:

• root не имеет сетевого доступа вообще — зайти под root можно только физически, подключив монитор и клавиатуру непосредственно к appliance.
• Для окончательного, необратимого удаления данных — нужно физическое подтверждение от двух авторизованных сотрудников клиента и двух сотрудников Object First одновременно.
• Позиционируется как immutable «из коробки» без необходимости в экспертизе по Linux или security.

А как насчёт других систем резервного копирования?
Раз уж упомянул Veeam, то поговорим о Hardened Linux Repository: это фирменная фишка исключительно Veeam, или другие вендоры backup-софта предлагают что-то похожее? По сути решения можно разделить на три категории.

1. тот же принцип — свой Linux-репозиторий с XFS
   NAKIVO Backup & Replication предлагает прямой аналог — тоже называется Hardened Repository, и построен ровно на том же механизме: immutable-атрибут файловой системы XFS в Linux, который можно выставить и снять только через привилегированный локальный сервис. Конфигурация практически повторяет Veeam один в один — выделенный Linux-сервер, XFS-раздел, отключённый SSH-доступ для повседневной работы.
   Bacula тоже способна работать с immutable-атрибутами файловой системы на Linux, хотя это менее готовое «из коробки» решение — требует больше ручной настройки со стороны администратора, чем у Veeam или NAKIVO.
2. immutable by default — через собственную закрытую ФС
   Rubrik и Cohesity решают ту же задачу принципиально иначе. Они не дают строить immutable-репозиторий самостоятельно на произвольном Linux-сервере — вместо этого продают закрытый appliance с собственной проприетарной распределённой файловой системой, где immutability встроена по умолчанию и не требует отдельной настройки администратором. Обратная сторона такого подхода — меньше гибкости в выборе железа (вы привязаны к appliance конкретного вендора) и обычно заметно более высокая стоимость входа.
3. мост к чужой immutable-инфраструктуре
   Commvault идёт третьим путём — не строит собственную immutable-технологию поверх голого Linux, а полагается на интеграцию с внешними immutable-таргетами через свой WORM Storage Lock, который синхронизируется либо с облачным S3 Object Lock, либо с фирменными механизмами конкретного вендора СХД — например, с уже разобранным нами HPE StoreOnce Catalyst ISV-DI. То есть у Commvault иммутабельность — это не своя реализация, а согласованный «мост» к чужой инфраструктуре хранения.

Вендор	Название механизма	Уровень защиты	Кто может снять защиту досрочно	Особенность
Dell EMC	Retention Lock	MTree (логический раздел Data Domain)	В Governance — админ с правами; в Compliance — никто, даже через recovery-режим без физического доступа	Требует отдельных лицензий на RLG/RLC и роли Security Officer; VTL-протокол работает только в Governance
HPE	StoreOnce Catalyst ISV-DI	Дедупликационный backup-таргет (Catalyst Store)	Никто в одиночку — Dual Authorization требует отдельного Security Officer, включая для смены системного времени	Root/shell недоступны конечному пользователю; retention 7–9999 дней; уязвимо через незащищённый iLO
ExaGrid	Retention Time-Lock	Отдельный физический уровень — Repository Tier	Никто — данные физически недоступны по сети, а удаление отложено на заданный срок	Auto Detect & Guard автоматически продлевает задержку при аномальных запросах на удаление; 2FA на смену настроек RTL
Quantum DXi	Secure Snapshot + Retention Lock	Non-network-addressable blockpool (снапшоты) / файлы NFS-шары (Retention Lock)	Никто — у Secure Snapshot нет datapath-доступа вообще, ни через ФС, ни через GUI/API	Без Landing Zone — инлайн-дедупликация; тирится дальше в ActiveScale (S3 Object Lock) или Scalar (Active Vault)
YADRO	Locked-снапшоты	VFS (виртуальная файловая система)	Никто внутри организации — снять может только поддержка YADRO	Аналог DD Boost/Catalyst — протокол T-BOOST; три уровня защиты снапшотов (Basic/Secure/Locked)
NetApp	SnapLock	Файлы тома по NFS/CIFS	В Enterprise — админ через privileged delete; в Compliance — никто, кроме физического уничтожения дисков	Защищённые ComplianceClock на каждый том
Pure Storage	SafeMode	Снапшоты — immutable + ineradicable	Никто в одиночку — нужны 2 авторизованных контакта + звонок в Pure Support	Настраиваемый таймер эрадикации до 400 дней
Huawei	WORM + Secure Snapshot	Файловая система + снапшоты (HyperCDP)	Защитный период можно только продлить, нельзя сократить, никем	Комплексное решение с отдельным ИИ-детектором атак (OceanCyber) и физически разрываемым air gap
Object First	Нативный S3 Object Lock	Объектное хранилище + hardened OS	Никто в одиночку

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

Тип хранилища	Типичная скорость	Особенность
Лента (LTO-9/10)	~260–400 МБ/с на привод (native), до 1000–1200 МБ/с со сжатием	Строго последовательный доступ
Дедуп-таргет на дисках (StoreOnce, Data Domain)	~300–400 МБ/с на поток	Произвольный доступ на порядки быстрее ленты
ExaGrid	До ~10 ГБ/с	Восстановление из Landing Zone идёт ещё быстрее — данные там не дедуплицированы и не требуют «регидратации». производительность масштабируется вместе с кластером до 32 узлов
Quantum DXi	До ~30 ГБ/с	Инлайн-дедупликация без Landing Zone
YADRO TATLIN.BACKUP	До ~4,0 ГБ/с
NetApp AFF	До ~30 ГБ/с	Тот же контроллер ONTAP, что и под SnapLock — производительность масштабируется вместе с кластером до 24 узлов
Pure Storage FlashBlade	До 15 ГБ/с	Массивно-параллельная архитектура — производительность растёт почти линейно с добавлением blade-модулей и шасси
Huawei OceanProtect (X9000)	До ~18 ГБ/с	Показатели растут с добавлением узлов в кластер (до 16 узлов)
On-prem Object First	~2 ГБ/с на узел	Локальная сеть, без зависимости от интернет-канала. Показатели растут с добавлением узлов в кластер
Облачный S3	Зависит от ширины канала до интернета, не от самого хранилища	При реальном disaster recovery узкое место — не S3, а WAN-канал заказчика

On-prem S3 против облачного S3
Раз лента — не единственный кандидат на роль «медленной, но надёжной» копии, стоит сравнить и два варианта S3-хранилища — локальный и облачный.

	On-prem Object First	Облачный S3 (AWS и аналоги)
Модель затрат	Капитальные затраты (CapEx) на оборудование, дальше — фиксированная стоимость владения	Операционная модель (OpEx) — платите помесячно за объём, растёт вместе с данными
Плата за исходящий трафик (egress)	Нет	Да
Скорость restore	Ограничена локальной сетью и производительностью системы	Ограничена шириной канала заказчика
Контроль над данными и суверенитет	Полный — данные физически у вас	Данные физически у облачного провайдера
Эластичность масштабирования	Требует физической докупки оборудования при росте	Практически неограниченная, оплата по факту использования
Заявленная durability	Зависит от конкретной реализации избыточности	У крупных провайдеров заявлено до «11 девяток»
Типичная роль в 3-2-1-1-0	Быстрый локальный immutable-таргет для оперативного восстановления	Географически удалённая копия для катастрофоустойчивости

Практический вывод: on-prem S3 и облачный S3 обычно не конкурируют (если мы конечно не говорим о построение выделенного канала до облачного провайдера до S3 хранилища), а дополняют друг друга в рамках одной стратегии 3-2-1-1-0 — быстрый локальный immutable-репозиторий (тот же Object First) для повседневного восстановления с низким RTO, и облачная копия как географически разнесённая офсайт-копия на случай полной потери площадки.

Вместо заключения
Если сравнивать все эти реализации с WORM-лентой и S3 Object Lock и прочие решения, вырисовывается чёткий тренд: индустрия постепенно уходит от модели «защита обходится администратором с нужными правами» к модели «защита не обходится вообще без участия внешней стороны». Pure SafeMode и Object First — наиболее показательные примеры: они сознательно не дают ни одному человеку внутри организации-клиента возможности в одиночку снять защиту, вынося это решение за периметр компании целиком.

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