В S3 растёт расход места: как проверить незавершённые multipart-загрузки

Если объём хранения S3 растёт, а готовых файлов почти не прибавляется, проверьте незавершённые multipart-загрузки. Это загрузка большого файла частями: при обрыве процесса части могут остаться в хранилище, хотя нового объекта в обычном списке ещё нет.

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

Почему список файлов не объясняет расход места

В Amazon S3 загруженные части хранятся и оплачиваются до завершения или отмены multipart-загрузки. Обычный просмотр объектов не заменяет проверку этих частей; такое поведение описано в документации AWS.

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

Ниже — порядок для обычного бакета Amazon S3 и AWS CLI. У S3-совместимого провайдера отдельно проверьте endpoint, поддержку API, lifecycle и правила учёта места; для S3 Express directory buckets действуют дополнительные ограничения.

1. Найдите незавершённые загрузки

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

aws s3api list-multipart-uploads \
  --bucket example-backups \
  --output json

Для каждой записи сохраните в закрытом рабочем отчёте:

• Key — имя будущего объекта;
• UploadId — идентификатор конкретной загрузки;
• Initiated — время её начала.

У одного имени файла может быть несколько загрузок, поэтому искать только по Key недостаточно. Проверьте все страницы ответа: AWS CLI поддерживает автоматическую пагинацию, но ограничивающие параметры могут оставить часть результатов за пределами выборки. Детали — в справке ListMultipartUploads.

Если получен AccessDenied, это не означает, что загрузок нет. Сначала проверьте права, выбранный аккаунт, бакет и endpoint; пустой успешный результат и отказ доступа — разные исходы.

2. Посчитайте части и проверьте активность

Для выбранной загрузки запросите список частей:

aws s3api list-parts \
  --bucket example-backups \
  --key 'backups/example.tar' \
  --upload-id 'UPLOAD_ID_FROM_LIST' \
  --output json

Суммируйте Size по всем частям и страницам, затем по всем проверенным загрузкам. Это объём сохранённых частей на момент наблюдения, а не готовый расчёт счёта: тариф, период хранения и другие операции учитываются отдельно. Поля и пагинация описаны в справке ListParts.

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

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

3. Отмените только подтверждённо ненужную загрузку

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

aws s3api abort-multipart-upload \
  --bucket example-backups \
  --key 'backups/example.tar' \
  --upload-id 'UPLOAD_ID_FROM_LIST'

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

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

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

4. Предотвратите накопление частей

Для обычного бакета Amazon S3 можно настроить lifecycle-действие AbortIncompleteMultipartUpload с параметром DaysAfterInitiation. Срок отсчитывается от начала загрузки; правило распространяется и на уже существующие незавершённые загрузки, а завершённые объекты этим действием не удаляются. См. правила lifecycle AWS.

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

Контролируйте число незавершённых загрузок, возраст самой старой и суммарный объём частей. Успех очистки — исчезновение выбранных остатков при сохранении нормальной работы новых загрузок, а не только уменьшение счёта.

Что проверить после очистки

Завершённая загрузка ещё не доказывает готовность бэкапа к восстановлению. Если архив хранится в холодном классе, отдельно проверьте срок выдачи копии из S3 Glacier.

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