Если вы регулярно гоняете бэкапы, статику, медиа или артефакты CI/CD в S3-совместимое объектное хранилище, то выбор CLI-инструмента быстро перестаёт быть «делом вкуса». На практике всплывают нюансы: что именно делает «sync», сколько запросов уходит на «безобидный» просмотр префикса, как ведёт себя multipart upload и почему ETag иногда вообще не про md5.
Ниже — практическое сравнение трёх утилит: s5cmd, awscli и rclone. Сфокусируемся на том, что важно админам/DevOps: параллелизм и скорость, корректность синхронизации, проверка целостности, а также стоимость операций LIST/HEAD и способы держать её под контролем.
Когда важны не мегабайты, а запросы: S3 как биллингуемая API
В объектном хранилище цена обычно складывается из хранения, исходящего трафика и операций API. Именно операции становятся «тихим убийцей бюджета» в двух типовых случаях:
- у вас сотни тысяч или миллионы объектов в одном префиксе;
- вы запускаете частые синхронизации, которые каждый раз «прочёсывают» бакет.
Команда «посмотреть, что лежит в префиксе» почти всегда означает вызов ListObjectsV2. А «умный sync» обычно делает не один LIST, а постраничный обход, иногда с дополнительными HeadObject для уточнения метаданных и проверок.
Скорость передачи данных — не единственный критерий. Для больших бакетов решают количество запросов и то, умеет ли инструмент сокращать их без потери корректности.
Кандидаты: s5cmd, awscli, rclone — что ждать в реальности
s5cmd
s5cmd — компактная утилита, заточенная под высокую параллельность и быстрые массовые операции в S3. Чаще всего её берут, когда нужно «прокачать через S3» очень много объектов и важна максимальная производительность на малых файлах.
- Сильные стороны: высокая скорость, агрессивный параллелизм, минимальные накладные расходы.
- Ограничения: меньше «экосистемных» возможностей, чем у awscli; не всегда удобно, если вы завязаны на специфичные AWS-опции и сценарии.
awscli
awscli — официальный клиент AWS. Его часто используют и с S3-совместимыми сервисами (через endpoint), особенно когда вокруг уже есть профили, политики доступа и «единый тулчейн» под AWS.
- Сильные стороны: предсказуемость поведения, документация, совместимость.
- Ограничения: на массовых операциях с большим количеством мелких объектов может уступать по скорости; «sync» на огромных наборах нередко получается дорогим по числу LIST/HEAD.
rclone (S3 backend)
rclone — универсальный инструмент для десятков облаков и протоколов. Для S3 это полноценный клиент со своими стратегиями сравнения, синхронизации и верификации.
- Сильные стороны: гибкие правила sync/copy, фильтры, dry-run, режимы проверки, удобство миграций между провайдерами.
- Ограничения: из-за гибкости легко «переусложнить» параметры и случайно увеличить число LIST/HEAD (а значит и расходы).
Если вы выбираете инфраструктуру под задачи, где важна предсказуемая производительность и ресурсы, часто удобнее иметь отдельную виртуалку под бэкапы/синхронизации. Под такие задачи обычно берут VDS, чтобы изолировать I/O и не мешать веб-приложению.
Скорость и параллелизм: что упирается в latency, а не в канал
В сценариях «много объектов, каждый маленький» узкое место — не пропускная способность, а задержки и количество параллельных запросов. Поэтому:
- s5cmd обычно выигрывает за счёт агрессивного параллелизма и простого пайплайна операций;
- awscli часто более «тяжёлый» и может проигрывать на миллионах ключей из-за накладных расходов и стратегии обхода;
- rclone показывает отличные цифры при правильной настройке потоков и режима сравнения, но нужно контролировать, какой именно режим вы включили (и сколько дополнительных запросов он провоцирует).
Быстрый ориентир выбора
- Нужно «залить/скачать максимум прямо сейчас» на массивах мелких файлов — чаще s5cmd.
- Нужно «как в AWS и как у всех в команде» — чаще awscli.
- Нужно переносить данные между разными облаками и применять сложные правила — чаще rclone.
Sync без сюрпризов: как инструменты решают «файл изменился или нет»
Любой режим «sync» упирается в ключевой вопрос: как понять, нужно ли перекачивать объект? На практике используются три базовых подхода:
- сравнение по размеру и времени модификации (быстро, но требует аккуратности с метаданными и временными зонами);
- сравнение по ETag (удобно, но ETag не всегда равен md5);
- сравнение по отдельному checksum (надёжно, но дороже по CPU и/или по числу операций).
На маленьких каталогах разница не видна. На десятках миллионов ключей это становится вопросом денег и времени: чем «умнее» проверка, тем чаще инструмент делает LIST и/или HEAD.
Опасный паттерн: частый sync по огромному префиксу
Типичный сценарий: вы складываете бэкапы «в одну папку», а потом запускаете sync/проверку каждый час. В итоге каждый запуск проходит по всей истории: сотни тысяч или миллионы ключей, постраничный LIST, плюс выборочные HEAD. Стоимость операций иногда начинает обгонять стоимость хранения.
Чтобы контролировать расходы, сначала оптимизируйте стратегию обхода: дробите префиксы по датам/проектам, синхронизируйте только «свежие» ветки и по возможности работайте от манифестов, а не от полного сканирования бакета.
Если вы используете rclone для синхронизаций и хотите аккуратно подойти к безопасности удаления/перезаписи, полезно свериться с практикой в статье про безопасную синхронизацию rclone bisync для медиа и S3.
Multipart upload: пороги, скорость и уборка незавершённых загрузок
multipart upload обычно включается автоматически для крупных объектов: файл режется на части, части грузятся параллельно, затем сервер «собирает» объект. Это ускоряет заливку и повышает устойчивость к обрывам.
Эксплуатационный нюанс — незавершённые multipart-загрузки. Они остаются после падения процесса, таймаутов или сетевых ошибок. В зависимости от реализации S3 такие «хвосты» могут занимать место и усложнять учёт.
Практика для продакшена:
- включить lifecycle-правило очистки незавершённых multipart uploads (если поддерживается сервисом);
- держать под контролем размер частей и параллелизм, чтобы не упираться в лимиты API и не создавать лишнюю нагрузку;
- понимать, как инструмент ретраит и как именно завершает/абортит сессии при ошибках.
Мини-набор команд для контроля multipart (AWS API)
Даже если вы пользуетесь не awscli, понимание этих операций полезно для диагностики «хвостов»:
aws s3api list-multipart-uploads --bucket BUCKET --prefix PREFIX/
aws s3api abort-multipart-upload --bucket BUCKET --key OBJECT_KEY --upload-id UPLOAD_IDОбратите внимание: массовое перечисление незавершённых загрузок тоже может упираться в LIST-подобные операции. Делайте это точечно (по префиксу) и по регламенту, а не каждые 5 минут.
ETag и checksum: почему ETag не всегда md5 и как проверять целостность
Частая ловушка — воспринимать ETag как «контрольную сумму файла». Для обычной (не multipart) загрузки в классическом S3 ETag часто совпадает с md5 содержимого. Но при multipart, серверном шифровании или особенностях совместимого сервиса ETag перестаёт быть простым md5.
Практические последствия:
- сравнение «локальный md5 == ETag» может давать ложные несовпадения;
- sync-логика, основанная на ETag, иногда принимает неверные решения (зависит от инструмента и режима);
- для строгой верификации нужно опираться на дополнительные механизмы, а не только на ETag.
Надёжные подходы
- Манифест с хэшами: хранить рядом файл со списком sha256 и сверять на стороне назначения.
- Режимы verify/check: включать осознанно и помнить, что это увеличит CPU и/или число HEAD/GET.
- Единые пороги multipart: если бизнес-логика завязана на сравнение, заранее определите, с какого размера включается multipart, и зафиксируйте настройки в пайплайне.
Если у вас доступ к S3 критичен и вы раздаёте данные через CDN/прокси/хранилище с кастомным доменом, часто логичным шагом становится выпуск сертификата на домен. Для этого пригодятся SSL-сертификаты, чтобы клиенты не ругались на TLS и можно было безопасно работать с приватными/публичными endpoint.
LIST и стоимость обхода: как не платить за «просто посмотреть»
LIST выглядит безобидно: «покажи, что в бакете». Но при миллионах объектов один полный обход превращается в тысячи страниц выдачи, то есть в тысячи запросов. А если инструмент во время sync делает несколько проходов или добавляет HEAD на объекты, стоимость растёт ещё быстрее.
Способы держать расходы под контролем:
- Структурируйте ключи: префиксы по датам/проектам/тенантам, чтобы операции затрагивали только нужный сегмент.
- Избегайте частых полных sync: синхронизируйте только свежие ветки (например,
2025/12/28/), а не весь архив. - Используйте манифесты и инкрементальность: проверяйте дельту, а не перечитывайте всё дерево.
- Осторожнее с удалениями: режимы sync с удалением на стороне назначения часто требуют «полного знания множества ключей», то есть большего числа LIST.
На больших бакетах «дешёвый» инструмент — это не тот, кто быстрее скачал 10 ГБ, а тот, кто сделал на порядок меньше LIST/HEAD в ежедневной рутине.
Рекомендации по выбору под типовые сценарии
1) Артефакты CI/CD и статика
Если вы выгружаете много файлов (особенно мелких) и хотите максимальную скорость, чаще всего удобен s5cmd. Главное — заранее продумать схему префиксов, чтобы последующие проверки и синхронизации не превращались в постоянный «полный LIST».
2) Бэкапы и регламентные операции
Когда важнее предсказуемость и соответствие «как в AWS», обычно выбирают awscli. Он хорошо ложится в процессы, где уже есть профили/роли и стандартные процедуры доступа.
3) Миграции и сложные правила синхронизации
Для переносов между разными хранилищами, фильтров, dry-run, выборочной сверки и понятных логов часто удобнее rclone. Если вы упираетесь в производительность rclone на S3, посмотрите практические приёмы в статье про настройку rclone для multipart и параллелизма в S3.
Мини-чеклист перед запуском sync на проде
- Оцените масштаб: сколько объектов и каков средний размер?
- Выберите правило сравнения: размер/время, ETag или отдельный checksum.
- Продумайте структуру префиксов: чтобы не обходить исторические данные каждый запуск.
- Проверьте multipart: пороги, потоки, cleanup незавершённых загрузок.
- Сделайте тестовый прогон: на небольшом префиксе и с фиксацией статистики времени и количества запросов (если сервис это показывает).
Итоги
s5cmd, awscli и rclone решают похожие задачи, но по-разному расставляют приоритеты. В «чистой скорости» и массовых копированиях часто выигрывает s5cmd. В стандартизации и предсказуемости — awscli. В универсальности, миграциях и гибких сценариях sync — rclone.
А главный практический критерий для больших хранилищ — не только мегабайты в секунду, но и то, сколько вы платите за операции API, особенно за LIST/HEAD. Оптимизируйте префиксы, избегайте полных обходов без необходимости и относитесь к ETag аккуратно: при multipart upload это не всегда md5.
