Жизненный цикл объектов в хранилище: правила, архивация и удаление

Прямой ответ

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

Правило задаётся в конфигурации бакета:

<LifecycleConfiguration>
  <Rule>
    <ID>logs-to-archive</ID>
    <Filter><Prefix>logs/</Prefix></Filter>
    <Status>Enabled</Status>
    <Transition>
      <Days>30</Days>
      <StorageClass>STANDARD_IA</StorageClass>
    </Transition>
    <Transition>
      <Days>90</Days>
      <StorageClass>GLACIER</StorageClass>
    </Transition>
    <Expiration>
      <Days>365</Days>
    </Expiration>
  </Rule>
</LifecycleConfiguration>

Механика:

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

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

Второй подводный камень — минимальный срок хранения. Классы с пониженной стоимостью имеют минимальный период тарификации, обычно 30–180 дней. Объект, удалённый раньше, всё равно оплачивается за полный период, поэтому частая ротация мелких файлов в таком классе обходится дороже обычного хранения.

Практика: проектирование сроков хранения

1. Начните с классификации данных. Разные категории требуют разных сроков: логи, пользовательские файлы, резервные копии, отчётность. Одно правило на весь бакет почти всегда неверно.

2. Разделяйте бакеты по политике хранения. Префиксы работают, но отдельный бакет упрощает контроль прав и снижает риск ошибки в фильтре.

3. Учитывайте юридические требования. Для персональных данных срок хранения определяется целью обработки, а не удобством; удаление по расписанию помогает соответствию требованиям — см. статью про GDPR и 152-ФЗ.

4. Версионируемые бакеты требуют отдельного правила. Без NoncurrentVersionExpiration старые версии накапливаются и оплачиваются, хотя в списке объектов не видны — о версиях подробнее в статье про версии объектов.

5. Отменяйте незавершённые загрузки. Правило AbortIncompleteMultipartUpload обязательно: части занимают место, не отображаясь как объекты — см. статью про multipart.

6. Защищайте критичные данные от удаления. Object Lock фиксирует объект на заданный срок и запрещает удаление даже владельцу бакета:

aws s3api put-object-retention \
  --bucket compliance --key report-2026.pdf \
  --retention '{"Mode":"COMPLIANCE","RetainUntilDate":"2031-10-21T00:00:00Z"}'

Режим COMPLIANCE нельзя снять досрочно, что защищает от случайного или намеренного удаления.

7. Проверяйте правила до включения. Ошибка в префиксе приводит к удалению не тех данных. Тест на отдельном бакете с копией структуры обязателен.

Рекомендации:

1. Ведите правила в репозитории. Конфигурация жизненного цикла — часть инфраструктуры и должна проходить ревью; подход описан в статье про Terraform.
2. Мониторьте объём по префиксам. Рост категории без изменения бизнес-активности означает, что правило не сработало.
3. Не удаляйте единственную копию. Срок хранения резервных копий должен превышать срок хранения исходных данных.
4. Учитывайте стоимость запросов. Дешёвое хранение с дорогой выборкой невыгодно для данных, которые читают часто.
5. Документируйте сроки. Ответ на вопрос «почему файл удалён» должен находиться в конфигурации, а не в памяти сотрудника.

Практический сценарий: нужные логи оказались в архиве в момент инцидента

Контекст: при разборе инцидента потребовались логи трёхнедельной давности. Запрос к хранилищу вернул ошибку: объекты находились в архивном классе.

1. Диагностика. Lifecycle-правило переводило всё с префиксом logs/ в архив через 30 дней. Правило написали для экономии, не оценив частоту обращений.
2. Оценка восстановления. Операция восстановления занимала от трёх до пяти часов, что делало её бесполезной для оперативного разбора. Дополнительно восстановление тарифицировалось по объёму.
3. Проверка стоимости. Расчёт показал, что экономия на хранении составляла около 15 % по категории, тогда как однократное восстановление всего объёма превышало её за два месяца.
4. Действия. (а) Разделили логи по назначению: logs/app/ с хранением 90 дней в обычном классе и logs/audit/ с переходом в архив через 180 дней; (б) для архивируемых категорий ввели индекс по датам, чтобы восстанавливать только нужный диапазон, а не всё; (в) добавили правило AbortIncompleteMultipartUpload после обнаружения 40 незавершённых загрузок; (г) вынесли конфигурацию правил в репозиторий с ревью; (д) добавили проверку «время получения данных» в описание каждой категории.
5. Результат. Логи, нужные для оперативного разбора, доступны сразу; архивируются только категории с документированным редким доступом.

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

FAQ

Когда применяется lifecycle-правило? Проверка выполняется периодически, обычно раз в сутки, поэтому удаление происходит не в точную секунду истечения срока, а в следующем цикле.

Можно ли восстановить удалённый по правилу объект? Нет, если бакет не версионируемый. В версионируемом бакете правило удаляет текущую версию, а старые могут сохраняться согласно своим настройкам.

Что дешевле: много мелких файлов или один большой? Один большой: тарифицируются и запросы, и минимальный размер объекта в некоторых классах. Миллионы мелких файлов обходятся дороже ожидаемого объёма.

Нужны ли lifecycle-правила в MinIO? Да, MinIO поддерживает переход между слоями и удаление по сроку. Конфигурация задаётся командой mc ilm или через S3 API.

Источники: AWS S3 docs (lifecycle, object lock), MinIO docs — ссылки в шапке.