Клиенту требовалось наладить регулярное резервное копирование данных из одного S3-совместимого хранилища в другое. На первый взгляд задача выглядела просто: нужно было переносить данные из одного бакета в другой, хранить несколько последних копий и удалять устаревшие наборы. На практике все оказалось сложнее.
В целевом бакете у клиента были включены версионирование и Object Lock Governance. Данные механизмы повышают устойчивость данных к случайному удалению и ошибочным действиям, но при некорректной логике копирования и очистки могут приводить к быстрому росту занимаемого объема
Если повторно загружать уже существующие объекты или удалять данные без учета версий, хранилище продолжит расти, даже когда визуально в бакете останется тот же набор папок.
Команда PlatformCraft доработала схему резервного копирования так, чтобы она работала автоматически, корректно обрабатывала версии объектов, поддерживала ротацию и не допускала неконтролируемого увеличения объема.
Задача клиента
Основная бизнес-задача заключалась в том, чтобы регулярно переносить в резервное хранилище только актуальные недельные наборы данных и хранить ограниченное количество последних копий.
Данные на источнике были организованы по датам в формате YYYY-MM-DD. Внутри каждой даты нужно было копировать не всю структуру, а только рабочие разделы:
- FINAL/GEOL
- FINAL/GEOPHY
- FINAL/RE
Такой подход позволял не переносить лишние данные и хранить в резервном бакете только те разделы, которые действительно нужны клиенту для восстановления и дальнейшей работы.
Требовалось обновленное решение, которое позволит:
- автоматически находить самую свежую дату на источнике;
- копировать новую недельную папку только один раз;
- не перезаписывать уже загруженные данные;
- хранить только пять последних актуальных резервных копий;
- корректно удалять старые данные вместе со всеми версиями объектов;
- учитывать работу версионирования и Object Lock (блокировки объектов);
- очищать устаревшие версии объектов и незавершенные многокомпонентные загрузки;
- исключить ручную очистку бакета;
- добавить логи, уведомления и защиту от параллельного запуска.
Что мешало стабильной работе резервного копирования
До доработки основная проблема была связана не с самим копированием, а с тем, как S3-совместимое хранилище вело себя при включенном версионировании.
Если объект загружался повторно по тому же ключу, он не просто заменялся. В бакете появлялась новая «текущая» версия, а предыдущая становится «noncurrent» версией (устаревшей). Для пользователя структура выглядела почти неизменной, но фактически объем хранилища продолжал увеличиваться.
Дополнительно рост объема усиливался из-за незавершенных multipart-загрузок. Подобные загрузки могут оставаться в хранилище после сбоев или прерванных операций и занимать место, не отображаясь при этом как актуальные объекты.
В результате клиенту требовалось не просто «скопировать папку по расписанию», а выстроить полноценную логику жизненного цикла резервных копий.
Как PlatformCraft реализовала автоматизацию
Команда PlatformCraft настроила скрипт, который запускается по расписанию через cron и выполняет полный цикл обслуживания резервного хранилища без ручного вмешательства.
Теперь при каждом запуске скрипт:
- проверяет доступные даты в исходном S3-совместимом хранилище;
- определяет самую свежую дату;
- проверяет, была ли эта дата уже загружена в целевой бакет;
- копирует данные только в том случае, если такой недельной папки ещё нет в резервном хранилище;
- очищает лишние версии объектов;
- выполняет ротацию старых резервных копий;
- пишет лог и отправляет уведомления при ошибках.
Принципиальное изменение в том, что теперь ранее загруженные папки больше не перезаписываются. Обновление позволяет избежать появления лишних версий одних и тех же объектов и снижает риск неконтролируемого роста объема.
Ротация пяти последних резервных копий
Для управления объемом хранения была реализована ротация по понятному правилу: в целевом бакете всегда должны оставаться только пять последних актуальных дат.
После успешной загрузки новой даты скрипт проверяет количество недельных папок в резервном хранилище. Если их становится больше пяти, он автоматически находит самую старую дату и полностью удаляет ее.
Важно, что удаление выполняется не только для текущих объектов. Скрипт также удаляет:
- все версии объектов;
- noncurrent-версии;
- «delete markers», если они есть в бакете.
Это критично для S3-бакетов с включенным версионированием, ведь обычное удаление объекта не всегда освобождает место, из-за чего предыдущие версии могут продолжать храниться и тарифицироваться.
Теперь в бакете остается ровно пять последних резервных наборов, а устаревшие данные автоматически удаляются.
Работа с Object Lock
В целевом бакете использовался Object Lock Governance, то есть «управляемая блокировка» (режим защищает объекты от случайного или несанкционированного удаления, но при наличии нужных прав позволяет выполнять управляемую очистку через «обход управления сохранением»).
PlatformCraft добавила в скрипт корректную работу с этим механизмом через S3 API. При ротации старых данных скрипт удаляет объекты, их версии и маркеры удаления с учетом ограничений настроек Object Lock.
Такой подход сохраняет защиту резервных копий от ошибочных действий, но при этом не мешает штатной очистке в рамках согласованной политики хранения.
Очистка устаревших версий
Отдельно была реализована автоматическая очистка noncurrent-версий (устаревших) после успешной загрузки новой даты.
Это важно, потому что при включенном версионировании старые версии объектов могут накапливаться незаметно. Текущая копия данных остается рабочей и доступной, но хранилище продолжает занимать все больше места за счет скопления предыдущих версий.
Теперь скрипт проходит по скопированному префиксу и удаляет только ненужные версии, не затрагивая актуальные «текущие» объекты, что позволяет сохранить последнюю рабочую копию и одновременно не платить за накопленные устаревшие версии.
Обработка нестандартных ключей в S3 API
В процессе работ команда столкнулась с особенностью конкретного S3-совместимого API. Некоторые объекты отображались в листинге с пробелом в имени, но при удалении API ожидал ключ, где пробел был представлен символом «+».
Из-за этого часть объектов могла не удаляться штатно и оставаться в бакете после очистки.
Чтобы исключить ручную дочистку, в скрипт был добавлен fallback-механизм. Если удаление по исходному ключу возвращало ошибку NoSuchKey, скрипт повторял операцию с заменой пробелов на «+». Это сделало очистку устойчивой даже для проблемных объектов и позволило корректно удалять данные без ручного вмешательства.
Диагностика роста объема хранилища
PlatformCraft также провела диагностику причин, по которым объем хранилища рос быстрее ожидаемого. Проверка показала, что проблема была не в актуальных current-объектах, а в накоплении:
- устаревших (noncurrent) версий;
- delete markers;
- незавершенных multipart-загрузок;
- старых данных, которые не удалялись полностью из-за особенностей версионирования.
Для аудита состояния бакета были подготовлены команды, позволяющие проверить количество текущих и старых версий, найти незавершенные multipart-загрузки, оценить размеры по датам и определить самые крупные объекты.
После очистки noncurrent-версий и multipart-загрузок объем хранилища вернулся к ожидаемому уровню. Затем логика скрипта была скорректирована так, чтобы такая ситуация не повторялась.
Логи, Telegram-уведомления и защита от параллельного запуска
Для надежной эксплуатации PlatformCraft добавила подробное логирование и уведомления в Telegram. Скрипт фиксирует:
- начало и завершение запуска;
- найденную актуальную дату;
- этапы копирования;
- очистку noncurrent-версий;
- ротацию старых резервных копий;
- ошибки при копировании или удалении;
- попытки параллельного запуска.
Также была реализована блокировка через lock-файл. Она не позволяет запустить несколько экземпляров скрипта одновременно, чтобы они не конфликтовали при записи, удалении или ротации данных.
Благодаря этому процесс резервного копирования стал не только автоматическим, но и прозрачным для эксплуатации: администраторам проще взаимодействовать с данными, получая уведомления при нештатных ситуациях.
Выводы
В результате клиент получил устойчивую и полностью автоматизированную схему резервного копирования между S3-совместимыми хранилищами.
Теперь система:
- автоматически находит новую недельную папку;
- копирует только те данные, которые еще не были загружены;
- не перезаписывает существующие резервные копии;
- хранит только пять последних актуальных дат;
- корректно удаляет старые объекты вместе со всеми версиями;
- работает с версионированием и Object Lock Governance;
- очищает устаревшие версии;
- помогает контролировать multipart-загрузки;
- ведет подробные логи;
- отправляет уведомления в Telegram;
- защищает от параллельного запуска.
Для клиента это означает более предсказуемые расходы на объектное хранилище, меньше ручных операций и более надежный процесс резервного копирования критичных данных.
PlatformCraft помогла не просто настроить копирование, а выстроить управляемый жизненный цикл резервных копий – от загрузки новых данных до безопасной очистки устаревших версий.
А если хотите протестировать наше объектное хранилище, оставьте заявку на сайте.
