Построение архитектуры для обеспечения хранения архивов данных

Архивная архитектура должна отвечать на конкретные вопросы:

1. Какие данные нужно архивировать;
2. Кто является владельцем этих данных;
3. Сколько времени они должны храниться;
4. Где они должны размещаться;
5. Кто может получить к ним доступ;
6. Должны ли они быть неизменяемыми;
7. Как быстро их нужно найти или восстановить;
8. Когда и по каким правилам их можно удалить;
9. Сколько будет стоить хранение на горизонте 3-5 лет.

Архивная архитектура становится особенно важной в компаниях, где данные должны сохраняться долго, но использоваться по-разному.

Главный принцип: архив должен проектироваться от требований к данным, а не от выбранного хранилища. Сначала нужно определить классы данных, сроки хранения, требования к доступу и восстановлению. Только после этого выбирать технологию: объектное хранилище, ленточную библиотеку, облачный архив, on-premises-платформу или гибридную модель.

Что должна обеспечить целевая архитектура

Хорошая архитектура архивного хранения строится вокруг шести требований:

1. Долговечность – данные не должны теряться из-за сбоя оборудования, ошибки площадки или деградации носителей.
2. Управляемость – данные должны автоматически переходить между классами хранения в зависимости от возраста и частоты доступа.
3. Безопасность – доступ к архиву должен контролироваться через роли, политики, шифрование и аудит.
4. Неизменяемость – критические данные должны быть защищены от удаления и изменения.
5. Доступность – для каждого класса данных нужно определить допустимое время получения.
6. Наблюдаемость – команда должна видеть объемы, ошибки, стоимость, операции доступа и состояние политик.

Архитектура архивного хранения должна поддерживать не только хранение, но и управление жизненным циклом данных:

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

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

Архив данных

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

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

Для архива важны не только надежность и стоимость. Не менее важны метаданные, политики, блокировка, контроль доступа и возможность доказать неизменность данных.

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

Резервное копирование

Резервное копирование – это механизм защиты от потери данных и простоев. Его цель – восстановить данные, приложение или инфраструктуру после инцидента.

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

Основные сценарии для резервного копирования следующие:

Также для бэкап-архитектуры критичны два показателя:

• RPO – сколько данных компания готова потерять по времени;
• RTO – за какое время данные или система должны быть восстановлены.

Например, если для базы заказов RPO составляет 15 минут, а RTO 1 час, архитектура резервного копирования должна обеспечивать частые копии и быстрое восстановление. Холодный архив с восстановлением за сутки для такого сценария не подходит.

Бэкап не заменяет архив. Если его использовать как архивное хранилище, появляются проблемы:

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

Бэкап – это страховка на случай инцидента, а архив – управляемое долгосрочное хранение данных.

Горячее хранилище (или активный архив)

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

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

«Активное» хранилище обычно включает больше компонентов, чем холодное:

Главное отличие «активного архива» в том, что данные не нужно полностью возвращать в продуктивную систему, чтобы получить от них пользу. Пользователь или приложение может найти объект, посмотреть метаданные, получить выборку или инициировать восстановление только нужного набора данных.

Сравнение: архив, бэкап и горячее хранилище

Как понять, куда относятся данные

Для проектирования архитектуры удобно использовать простой чек-лист.

Архитектурный принцип

Архивное, бэкап и горячее хранилище не должны конкурировать. Они должны дополнять друг друга.

Оптимальная модель выглядит так:

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

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

Правильная архитектура отвечает на три группы вопросов:

1. Зачем храним, сколько храним, кто владелец?
2. Где храним, как защищаем, как восстанавливаем?
3. Сколько это стоит сейчас и сколько будет стоить через 3-5 лет?

Основные цели архивного хранения

Цель №1: сохранить данные на весь срок их ценности

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

Важно учитывать:

• срок хранения данных;
• формат данных;
• зависимость от конкретного приложения;
• наличие метаданных;
• возможность переноса в другое хранилище;
• контроль целостности;
• периодическую проверку читаемости.

Цель №2: снизить стоимость без потери управляемости

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

Архитектура должна разделять данные по классам доступа:

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

Однако дешевое хранилище может стать дорогим, если данные часто восстанавливаются или активно читаются.

Цель №3: обеспечить безопасность и неизменяемость

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

Минимальный набор требований включает:

• IAM и отдельные роли для администраторов;
• шифрование при хранении и передаче данных;
• управление ключами через KMS или аналогичный механизм;
• изолированные и неизменяемые копии, запрет массового удаления, контроль аномалий.

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

Цель №4: сделать данные находимыми

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

Поэтому архитектура должна включать слой метаданных.

Минимальный набор метаданных включает:

• владельца данных (кто отвечает за хранение и удаление);
• тип данных;
• дату создания;
• срок хранения;
• уровень чувствительности;
• бизнес-контекст;
• источник данных.

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

Цель №5: обеспечить восстановление и проверяемость

Архив имеет смысл только тогда, когда данные можно получить обратно в понятные сроки и в пригодном виде. Поэтому для каждого класса данных нужно определить не только срок хранения, но и параметры восстановления.

Архивное восстановление нужно тестировать так же, как резервное копирование, иначе компания может обнаружить проблему только в момент аудита, расследования или судебного запроса.

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

Главная ошибка – это архивировать все одинаково. В результате критичные данные могут оказаться без защиты, а редко используемые массивы будут храниться слишком дорого.

Архитектурный принцип следующий: данные нужно архивировать не по месту их хранения, а по их ценности, рискам и требованиям к доступу.

Что нужно определить для каждого класса данных

Перед переносом данных в архив для каждого типа нужно ответить на базовые вопросы:

1. Что это за данные? Нужно чтобы определить тип хранилища и формат доступа.
2. Кто ответственный за срок хранения и удаление данных?
3. Сколько нужно хранить данные?
4. Как часто данные требуются (для выбора горячего, теплого или холодного класса хранения)?
5. Как быстро нужно восстанавливать данные (чтобы определить SLA на получение данных)?
6. Насколько данные чувствительны (для выбора модели доступа и шифрования)?
7. Нужны ли версии и можно ли удалять данные?
8. Есть ли регуляторные требования к данным?

Основные типы архивируемых данных: документы, финансовые или медицинские данные, логи и события, почта и коммуникации, медиа, данные приложений, бэкап-данные, инженерные данные и ИИ-датасеты.

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

Классификация по частоте доступа

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

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

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

Классификация по сроку хранения

Срок хранения должен задаваться не технической командой, а совместно с бизнесом, юристами, ИБ и владельцами данных.

Важно не хранить данные «по умолчанию», то есть всегда. Бессрочное хранение увеличивает стоимость, усложняет соответствие и создает дополнительные риски при утечке.

Классификация по чувствительности

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

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

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

Классификация по необходимости поиска

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

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

А если архивируются финансовые отчеты, то может быть достаточно поиска по периоду, компании и типу документа. Если архивируется почта или юридические документы, часто нужен полнотекстовый поиск, фильтрация по участникам, датам, вложениям и статусу.

Практическая матрица классификации

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

Минимальный чек-лист перед архивированием

Классификация – это основа всей архивной архитектуры. Она определяет, какие технологии нужны, какие политики применять, как считать стоимость и какие риски закрывать.

Перед тем как переносить данные в архив, нужно проверить:

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

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

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

Минимальная модель оценки выглядит так:

1. Надежность – сохранность данных на протяжении всего срока хранения.
2. Доступность – скорость получения архивных данных при запросе.
3. Безопасность – защита от несанкционированного доступа, утечек и атак.
4. Неизменяемость – защита от удаления, перезаписи и подмены данных.
5. Стоимость – предсказуемость расходов на хранение, чтение, восстановление и рост объемов.

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

Надежность и долговечность хранения

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

Для архивов особенно важна долговечность хранения. Продуктивные системы могут обновляться каждые несколько лет, а архивные данные часто должны храниться 5, 7, 10 и более лет. Это означает, что архитектура должна быть рассчитана не только на отказ диска или сервера, но и на долгий жизненный цикл данных.

Что нужно учитывать:

1. Вероятность сохранности объекта в течение длительного периода.
2. Хранение копий данных в нескольких узлах, зонах или площадках.
3. Защита от потери региона, дата-центра или площадки.
4. Проверка, что объект не поврежден и неизменен незаметно.
5. Регулярная валидация читаемости и восстанавливаемости данных.
6. Версионирование, сохранение, корзина, процессы утверждения.

Репликация: локальная, зональная и географическая

Репликация должна соответствовать ценности данных и допустимому риску потери.

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

Контроль целостности

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

• «контрольную сумму» при записи и чтении;
• регулярную проверку целостности объектов;
• отчеты о поврежденных или недоступных объектах;
• автоматическое восстановление из реплики;
• тестовое восстановление выборочных наборов данных;
• журналирование результатов проверок.

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

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

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

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

Как выбирать класс доступа

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

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

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

Практический чек-лист по доступности:

1. Как часто данные будут читаться? Ежедневно, ежемесячно, ежегодно, только при инциденте?
2. Как быстро они должны быть доступны?
3. Кто будет запрашивать данные? ИТ-отдел, юристы, ИБ-отдел, приложения?
4. Нужен ли поиск до восстановления? Если да, то по каталогу, индексу, метаданным?
5. Что будет, если доступ займет дольше? Какое влияние на аудит, расследование, SLA, бизнес-процессы?

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

Базовые требования к безопасности

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

Архитектура безопасности архива должна строиться по принципу минимальных привилегий и полной наблюдаемости. Следует реализовать:

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

Разграничение доступа

Доступ к архивам должен быть ролевым. Нельзя выдавать широкие права по принципу «администратору нужно все». Для архивной среды лучше использовать отдельные роли:

1. Владелец данных – утверждает срок хранения и доступ.
2. Пользователь хранилища – читает разрешенные данные.
3. Оператор архива / хранилища – управляет загрузкой и жизненным циклом без права отключать срок хранения.
4. Администратор хранилища – управляет инфраструктурой без доступа к содержимому.
5. Сотрудник службы безопасности – контролирует политики и подозрительные действия.
6. Администратор бэкапирования – управляет операциями по резервному копированию.

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

Архивы нужно считать не на текущий объем, а на прогноз роста. Если сейчас в архиве 500 ТБ, а данные растут на 30% в год, через 5 лет объем может увеличиться в несколько раз. Без «lifecycle» и удаления это напрямую превращается в рост бюджета.

Простая модель планирования следующие параметры:

Пример расчетной логики

Если 20% данных нужны для поиска и периодического доступа, их нельзя сразу переносить в глубокий архив. Если 70% данных старше одного года почти не читаются, для них можно применить холодный класс хранения.

Если 10% данных юридически значимы, для них нужны сроки хранения, защита от изменений и отдельный контроль доступа.

Если резервные копии нужны только для восстановления, их стоимость нужно считать отдельно от бизнес-архива.

Такой подход позволяет не хранить все одинаково и не переплачивать за универсальную модель.

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

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

Чек-лист перед выбором архитектуры

Перед выбором архитектуры нужно ответить:

• сколько данных будет храниться сейчас;
• какой ожидается рост за 3-5 лет;
• какие данные можно удалять автоматически;
• какая доля данных требует быстрого доступа;
• какая доля может уйти в холодный или глубокий архив;
• как часто данные будут восстанавливаться;
• сколько будет стоить восстановление 1 ТБ, 10 ТБ и 100 ТБ;
• какая исходящая полоса пропускания при выгрузке данных;
• сколько стоят операции PUT, GET, LIST;
• сколько стоит индексация и поиск;
• сколько стоит репликация;
• есть ли минимальный срок хранения;
• сколько будет стоить миграция на другую платформу;
• кто будет администрировать архив;
• как будет контролироваться бюджет.

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

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

PlatformCraft можно развернуть On-Premise в инфраструктуре заказчика, сохранив контроль над данными, политиками безопасности и требованиями соответствия. Это удобная основа для архивного хранения, резервных копий, горячего хранилища и долгосрочного управления корпоративными данными.

Вы также можете попробовать облачное хранилище бесплатно в течение 14 дней.

1. Чем архив данных отличается от резервного копирования?

Архив предназначен для долгосрочного управляемого хранения данных: документов, логов, отчетов, медиа, юридически значимых материалов и исторических наборов данных. Его задача – сохранить данные на нужный срок, обеспечить доступ, контроль, безопасность и соблюдение политик хранения.

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

2. Что такое горячее или теплое хранилище?

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

3. Когда компании нужно горячее хранилище, а когда достаточно холодного архива?

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

Холодного архива достаточно, если данные почти никогда не используются и нужны только для долгосрочного хранения, аудита, расследования или юридического запроса.

4. Какие данные стоит архивировать?

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

К ним относятся:

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

5. Почему нельзя хранить все архивные данные одинаково?

У разных данных разные требования к сроку хранения, скорости доступа, безопасности, неизменяемости и стоимости. Например, логи безопасности за последние 90 дней могут требовать быстрого поиска, а финансовые документы пятилетней давности – только защищенного долгосрочного хранения. Если хранить все в одном классе, компания либо переплачивает за ненужную доступность, либо теряет скорость доступа там, где она критична.

6. Какие ключевые требования нужно учитывать при построении архивной архитектуры?

Базовые требования:

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

7. Что такое политика хранения и зачем она нужна?

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

8. Что такое WORM, Object Lock и legal hold?

WORM означает Write Once Read Many: данные можно записать один раз и читать много раз, но нельзя изменить или удалить до окончания срока хранения.

Object Lock – механизм блокировки объекта от удаления и перезаписи на заданный период.

Legal hold – юридическая блокировка, которая запрещает удаление данных, связанных с расследованием, спором, аудитом или судебным процессом.

Эти механизмы нужны для защиты критичных архивов, юридически значимых документов, логов и резервных копий.

9. Как архивная архитектура помогает защититься от программ-вымогателей?

Архивная архитектура снижает риск потери данных при атаке, если в ней предусмотрены:

• неизменяемое хранилище;
• Object Lock или WORM;
• MFA для административных действий;
• разделение ролей;
• запрет массового удаления;
• аудит логов;
• изоляция бэкапов и архивной среды;
• регулярные тесты восстановления;
• алерты на аномальные операции.

Особенно важно защищать резервные копии и критичные архивы от удаления администраторами и скомпрометированными учетными записями.

10. Как считать стоимость архивного хранения?

Нельзя смотреть только на цену за терабайт. Нужно считать полную стоимость владения – TCO. В расчет входят стоимость хранения, операции чтения и записи, исходящий трафик, индексация и поиск, репликация, администрирование, рост объемов на 3-5 лет. У PlatformCraft бесплатные исходящий трафик, запросы и репликация.

11. Какие ошибки чаще всего допускают при построении архивного хранения?

Типовые ошибки:

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

12. С чего начать построение архитектуры архивного хранения?

Начинать нужно не с выбора платформы, а с инвентаризации и классификации данных.

1. Определить типы архивируемых данных.
   2. Назначить владельцев.
   3. Задать сроки хранения.
   4. Определить требования к доступу и восстановлению.
   5. Разделить данные на горячий, теплый, холодный и глубокий архив.
   6. Определить требования к безопасности и неизменяемости.
   7. Рассчитать TCO.
   8. Выбрать архитектурную модель.
   9. Провести пилот.
   10. Настроить мониторинг, аудит и lifecycle.

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