rclone для больших файлов: multipart‑загрузки, параллелизм и контроль памяти

Когда речь заходит о бэкапах и выгрузке артефактов в S3‑совместимые хранилища, rclone остаётся одним из самых практичных инструментов. Но при работе с очень большими файлами и высокими скоростями по сети, «из коробки» можно столкнуться либо с недозагрузкой канала, либо с чрезмерным расходом памяти. Правильная настройка multipart‑загрузок, параллелизма и буферов превращает rclone в предсказуемый и быстрый конвейер.

Зачем multipart и как это реализовано в rclone

Протокол S3 поддерживает multipart‑загрузки: один объект разбивается на части (parts), которые отправляются параллельно, а затем сервер собирает их в единый файл. Это снижает влияние высокой задержки (RTT), повышает утилизацию канала и позволяет надёжно докачивать неудавшиеся части.

Ключевые особенности и ограничения, о которых важно помнить:

• Минимальный размер части обычно 5 MiB (по спецификации S3). Для больших файлов имеет смысл увеличивать размер части.
• Лимит количества частей чаще всего 10 000. Если частей получится больше, клиент обязан увеличить размер части.
• Ограничения на одновременные соединения и API‑rate на стороне провайдера могут приводить к ответам SlowDown/Throttling — тогда помогает снижение параллелизма.

В rclone переключение на multipart управляется порогом --s3-upload-cutoff (файлы больше порога летят мультипартом), размером части --s3-chunk-size и параллелизмом по частям для одного файла --s3-upload-concurrency. Параллелизм между файлами задаётся --transfers.

Ключевые флаги для S3‑бэкапов больших файлов

Порог для multipart

--s3-upload-cutoff — размер, после которого rclone переключается на multipart. Значение по умолчанию подходит не всем. Для средних объёмов можно ставить 64–128 MiB, чтобы чаще включался мультипарт.

Размер части

--s3-chunk-size — базовый размер части. Чем больше, тем меньше накладных расходов на запросы и ниже нагрузка на CPU/метаданные, но выше «гранулярный» размер повторной отправки при сбоях. Для очень больших файлов практичны значения 64–256 MiB.

Параллелизм частей одного файла

--s3-upload-concurrency — сколько частей одного файла rclone загружает одновременно. Обычно 4–8 достаточно, чтобы хорошо заполнить канал и не «съесть» всю память.

Параллелизм между файлами

--transfers — сколько файлов за раз обрабатывает rclone. При множестве больших файлов лучше держать небольшое число (1–3) и разгонять параллелизм внутри файла через --s3-upload-concurrency, иначе множитель по памяти становится слишком большим.

Буфер и память

--buffer-size — объём буфера на один открытый файл. По умолчанию немаленький; для сценариев «локальный файл → S3» часто выгодно уменьшить до 4–8 MiB или даже 0 MiB, чтобы тесно контролировать ОЗУ. Учтите, что буфер ускоряет чтение с медленных источников.

Скорость и лимиты

--bwlimit — ограничение bandwidth, чтобы не забивать канал и не конкурировать с продовыми сервисами. Поддерживает расписания с времени суток. Пример: днём ограничиваем до 200 MiB/s, ночью до 20 MiB/s.

Надёжность

--retries, --low-level-retries, --retries-sleep и разумные --timeout/--contimeout помогут при «рыхлой» сети и облачных ограничениях.

Как оценить потребление памяти

Основной вклад в память дают:

• Буфер чтения на файл: buffer-size.
• Параллельные части: примерно s3-upload-concurrency × s3-chunk-size на один файл в активной загрузке.
• Некоторый служебный оверхед на соединения и метаданные.

Грубая оценка памяти под активную загрузку:

RAM ≈ transfers × (buffer-size + s3-upload-concurrency × s3-chunk-size) + оверхед

Примеры:

• Один большой файл, --transfers 1, --s3-upload-concurrency 4, --s3-chunk-size 64M, --buffer-size 8M → около 8M + 4×64M = 264 MiB + оверхед.
• Три больших файла параллельно, те же настройки → около 3 × 264 MiB ≈ 792 MiB + оверхед.

Если память критична, сначала снижайте --transfers, затем --s3-upload-concurrency, и только потом уменьшайте --s3-chunk-size (слишком маленькие части добавляют накладные расходы и падают в эффективность на больших RTT).

Подбор значений под разные сценарии

Ежедневный бэкап больших архивов (1–3 файла по 100–300 ГиБ)

Цель: стабильность и ограниченное потребление памяти, умеренная скорость.

rclone copy /backups s3:prod-backup/daily --transfers 1 --s3-upload-cutoff 64M --s3-chunk-size 64M --s3-upload-concurrency 4 --buffer-size 8M --bwlimit 0:200M,22:20M --retries 5 --low-level-retries 10 --stats 20s --progress

Такой профиль редко превышает ~300 МиБ RAM и даёт устойчивость при неидеальном интернете.

Максимальная утилизация гигабитного канала

Цель: добиться близкого к линк‑спиду аплоада, если диск и CPU позволяют.

rclone copy /mnt/storage s3:ingest --transfers 2 --s3-upload-cutoff 128M --s3-chunk-size 128M --s3-upload-concurrency 6 --buffer-size 16M --checkers 8 --stats 10s --progress

Потребление памяти: около 2 × (16M + 6×128M) ≈ 1568 МиБ + оверхед. Если ОЗУ меньше — уменьшайте --s3-upload-concurrency до 4.

Ограниченный канал и требование «не мешать прод‑трафику»

Цель: жёстко ограничить bandwidth, вместе с аккуратным параллелизмом.

rclone move /var/log/archives s3:cold-logs --transfers 1 --s3-upload-concurrency 3 --s3-chunk-size 32M --buffer-size 4M --bwlimit 80M --stats-one-line --stats 30s

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

Детали, о которых часто забывают

Многопоточность при скачивании

Для больших загрузок с S3 на локальный диск rclone использует многопоточное чтение с разбиением по диапазонам. Важные флаги: --multi-thread-cutoff (после какого размера включать многопоточность) и --multi-thread-streams (сколько потоков). Эти потоки тоже потребляют ресурсы; не разгоняйте их без нужды.

Server‑side copy между S3‑совместимыми хранилищами

При копировании «облако → облако» rclone, где возможно, делает server‑side copy. Для объектов больше ~5 ГиБ S3 требует multipart‑copy; порог настраивается --s3-copy-cutoff. Чем меньше клиентской полосы и чем надёжнее облака, тем выгоднее серверная копия.

Пределы частей и авто‑масштабирование

Если потенциальное число частей превысит 10 000, rclone автоматически увеличит размер части, чтобы уложиться в лимит. Это удобно для очень крупных объектов (сотни ГиБ и более), но имейте в виду рост гранулярности повторной передачи.

Хеш‑контроль и валидация

Для multipart‑объектов ETag в S3 часто перестаёт быть «простой MD5»; rclone не всегда может использовать его как полноценный контроль целостности. Для критичных данных после загрузки запускайте валидацию: rclone check по размеру и, где доступно, по хешу. Дополнительно практичен подход «хеш‑файлы рядом»: формируйте на источнике .sha256 и отправляйте вместе с данными. Для практики посмотрите пошаговую настройку sync и verify для rclone на VDS.

Диагностика и устойчивость

• Ошибки SlowDown/Throttling: уменьшайте --s3-upload-concurrency и/или --transfers, увеличивайте паузы --retries-sleep.
• HTTP 5xx на части: увеличьте ретраи, включите больше логирования (--log-level=INFO или --log-level=DEBUG) и проверьте стабильность канала.
• Недозагрузка канала при большом RTT: пробуйте увеличивать --s3-chunk-size до 128–256 MiB и параллелизм частей до 6–8.
• OOM/высокая память: уменьшайте по очереди --transfers, --s3-upload-concurrency, затем --buffer-size, и только потом --s3-chunk-size.

План тестирования и вывода в прод

1. Выберите «бюджет ОЗУ» под задачу (например, не больше 1 ГиБ) и рассчитайте стартовые параметры по формуле.
2. Прогоните перенос 1–2 больших файлов с --progress и --stats 10s, снимите показатели скорости, ошибок и пиков RAM.
3. Слегка варьируйте --s3-upload-concurrency (±2) и --s3-chunk-size (×2/÷2), фиксируя изменение throughput и стабильности.
4. Закрепите рабочий профиль, добавьте --bwlimit и расписание, если нужно «притереть» к окну бэкапов.
5. Включите лог в файл, ротацию и алерты по аномалиям (много ретраев, длительное падение скорости).

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Готовые пресеты

«Аккуратный» пресет для повседневных бэкапов

--transfers 1
--s3-upload-cutoff 64M
--s3-chunk-size 64M
--s3-upload-concurrency 4
--buffer-size 8M
--bwlimit 0:200M,22:20M
--retries 5 --low-level-retries 10
--stats 20s

«Производительный» пресет для быстрых каналов

--transfers 2
--s3-upload-cutoff 128M
--s3-chunk-size 128M
--s3-upload-concurrency 6
--buffer-size 16M
--checkers 8
--stats 10s

«Строгий по памяти» пресет для ограниченных систем

--transfers 1
--s3-upload-cutoff 32M
--s3-chunk-size 32M
--s3-upload-concurrency 3
--buffer-size 0
--bwlimit 60M
--stats 30s

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

Итоги

Для больших файлов в rclone критичны три вещи: грамотная настройка multipart (порог и размер части), баланс параллелизма между файлами и частями, а также жёсткий контроль памяти через --buffer-size и расчёт итогового потребления. Методика проста: задать бюджет RAM, подобрать стартовые значения, провести короткие замеры, затем закрепить профиль и включить валидацию. Если бэкапы крутятся на отдельном узле, удобно вынести их на VDS — так проще контролировать ресурсы и окно загрузки.