rclone на сервере: частые ошибки и решения

MAATRIX

Rclone на бумаге выглядит просто: настроил ремоут, запустил sync, файлы улетели в S3 или Google Drive. На практике первая же синхронизация большого каталога упирается то в 403 от провайдера, то в обрыв на середине гигабайтного архива, то в файлы с правами root, которые никто, кроме root, прочитать не может. Ниже — ошибки, с которыми реально сталкиваешься на сервере, и что с ними делать, без магии и повторов документации слово в слово.

Ошибка 403/401: неверные ключи доступа к S3-хранилищу

Самая частая проблема на старте — rclone отказывается подключаться к S3-совместимому хранилищу (AWS S3, Backblaze B2, MinIO, Selectel, Yandex Object Storage) с 403 Forbidden или SignatureDoesNotMatch.

Причины, по порядку убывания частоты:

• Пароль/секрет не тот, что скопирован в конфиг. Если вы вставляли ключ вручную, легко подхватить лишний пробел или перенос строки. Проверьте конфиг:

cat ~/.config/rclone/rclone.conf

Секции выглядят так:

[mys3]
type = s3
provider = AWS
access_key_id = AKIA...
secret_access_key = ...
region = eu-central-1
endpoint =

• Расхождение времени на сервере. S3 подписывает запросы с временной меткой, и если системные часы уехали больше чем на 15 минут — получите SignatureDoesNotMatch даже с правильными ключами. Проверка и синхронизация:

timedatectl
sudo apt install -y chrony
sudo systemctl enable --now chrony

• Неверный endpoint или region для не-AWS провайдера. Для MinIO или Backblaze B2 нужно явно указать endpoint, иначе rclone пытается стучаться в AWS и получает отказ на уровне DNS/TLS, который иногда маскируется под 403. Пример для Backblaze B2 через S3-совместимый API:

[b2s3]
type = s3
provider = Other
access_key_id = 0012xxxxxxxx
secret_access_key = K002xxxxxxxx
endpoint = s3.eu-central-003.backblazeb2.com
region = eu-central-003

• Ключ создан с ограниченными правами (bucket policy / IAM). Если ключ привязан к конкретному бакету, а вы обращаетесь к другому — тоже 403. Проверьте политику на стороне провайдера, а не только конфиг rclone.

Диагностика в одну команду — покажет реальную причину без догадок:

rclone lsd mys3: -vv

Флаг -vv даёт подробный лог HTTP-запросов, и в нём видно точный код ответа от провайдера, а не только обёртку rclone.

Google Drive: "User rate limit exceeded" и лимиты API

Для Google Drive типична другая боль — не проблема с доступом, а троттлинг. Google выдаёт квоту на API-запросы по умолчанию на весь проект, и при активной синхронизации многих мелких файлов легко её выбить:

Failed to copy: googleapi: Error 403: User Rate Limit Exceeded

Решения по возрастанию усилий:

1. Снизить параллелизм и добавить паузы между запросами. По умолчанию rclone уже делает экспоненциальный backoff при 403 от Google, но для больших деревьев файлов стоит явно ограничить темп:

rclone sync /data gdrive:backup \
  --transfers 4 \
  --checkers 8 \
  --tpslimit 10 \
  --drive-pacer-min-sleep 100ms

1. Завести собственный OAuth-клиент вместо общего rclone. По умолчанию все пользователи rclone делят одну квоту Google API на клиентское приложение rclone, и в часы пик её легко исчерпать. Свой client_id и client_secret в Google Cloud Console дают отдельную квоту только для вас — это самый надёжный фикс для регулярных бекапов:

[gdrive]
type = drive
client_id = ваш_client_id.apps.googleusercontent.com
client_secret = ваш_client_secret
scope = drive
token = {...}

1. Использовать service account для серверных сценариев без интерактивного OAuth — удобно для cron, не требует повторной авторизации при истечении токена:

[gdrive]
type = drive
scope = drive
service_account_file = /etc/rclone/sa-backup.json

Отдельно держите в уме: точные цифры квот Google меняет без предупреждения, поэтому не закладывайтесь на конкретные значения запросов в секунду — ориентируйтесь на поведение (частые 403) и снижайте темп, а не на цифру из чужой статьи.

Обрывы соединения и таймауты на больших файлах

Копирование архива на 20-50 ГБ обрывается на середине с ошибками вида context deadline exceeded или connection reset by peer. Обычно это не баг rclone, а совокупность сетевых таймаутов по умолчанию, которые не рассчитаны на медленный или нестабильный канал.

Что помогает:

rclone copy /data/backup.tar.gz mys3:backups/ \
  --timeout 10m \
  --contimeout 60s \
  --retries 5 \
  --low-level-retries 20 \
  --retries-sleep 30s \
  --multi-thread-streams 4

• --timeout — сколько ждать данных от сервера до разрыва простаивающего соединения. Значение по умолчанию рассчитано на быстрые каналы, на VPS с более скромной сетью до зарубежных хранилищ его стоит увеличить.
• --contimeout — таймаут установки самого TCP-соединения, актуален, если хранилище географически далеко от сервера.
• --low-level-retries — сколько раз повторить именно сетевой запрос (не всю операцию копирования), прежде чем сдаться.
• --multi-thread-streams — режет большой файл на несколько параллельных потоков закачки, что заметно снижает шанс полного обрыва на нестабильном канале, но не всегда поддерживается конкретным провайдером.

Если файлы бьются постоянно на одном и том же шаге — проверьте MTU и стабильность внешнего соединения сервера отдельно от rclone:

mtr -rw storage.provider.example

Иногда причина вообще не в rclone, а в проблемах с маршрутизацией до дата-центра хранилища — тогда решает не тюнинг флагов, а смена локации сервера ближе к хранилищу или смена самого провайдера объектного хранилища.

rclone mount: права доступа и "Transport endpoint is not connected"

rclone mount монтирует облачное хранилище как локальную файловую систему через FUSE, и здесь свой набор граблей.

"Transport endpoint is not connected" после обрыва сети или падения процесса rclone — точка монтирования остаётся "залипшей", файлы через неё не читаются. Лечится размонтированием и повторным монтированием:

sudo fusermount -uz /mnt/storage
sudo umount -l /mnt/storage   # если fusermount не сработал
rclone mount mys3:bucket /mnt/storage --daemon

Файлы видны только root, хотя монтировал обычный пользователь. По умолчанию FUSE-точка недоступна другим пользователям системы, даже с правильными правами внутри. Нужен --allow-other, а для него — разрешение в системном конфиге FUSE:

echo "user_allow_other" | sudo tee -a /etc/fuse.conf

rclone mount mys3:bucket /mnt/storage \
  --allow-other \
  --uid 1000 \
  --gid 1000 \
  --umask 022 \
  --daemon

Монтирование не переживает перезагрузку сервера. Ручной запуск rclone mount живёт до первого reboot. Для постоянного монтирования нужен systemd-юнит:

# /etc/systemd/system/rclone-storage.service
[Unit]
Description=rclone mount storage
After=network-online.target
Wants=network-online.target

[Service]
Type=notify
ExecStart=/usr/bin/rclone mount mys3:bucket /mnt/storage \
  --allow-other --vfs-cache-mode writes --config /etc/rclone/rclone.conf
ExecStop=/bin/fusermount -uz /mnt/storage
Restart=on-failure
RestartSec=10
User=rclone

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now rclone-storage.service

Флаг --vfs-cache-mode writes стоит отдельного упоминания: без него запись через mount в некоторые приложения (например, редактирование файла программой, которая делает seek) будет падать с ошибками, потому что rclone по умолчанию не буферизует запись на диск перед отправкой в облако.

Дубликаты файлов и повреждение при передаче

Два смежных, но разных симптома.

Дубликаты в Google Drive — там файловая система построена на ID, а не на уникальности имени и пути, поэтому одноимённые файлы могут накапливаться при повторных ручных загрузках или сбоях синхронизации. rclone это видит и умеет чистить:

rclone dedupe gdrive:backup --dedupe-mode newest

Режимы --dedupe-mode: newest/oldest оставляют один файл по дате, rename переименовывает дубли вместо удаления (безопаснее для первого запуска — сначала посмотрите, что нашлось, прежде чем удалять).

"Corrupted on transfer" или расхождение чексумм — rclone по умолчанию сверяет размер и, где провайдер поддерживает, чексумму после каждой передачи. Ошибка означает, что файл на приёмнике не совпал с источником. Если это происходит стабильно на одних и тех же файлах, а не разово из-за сети:

rclone check /data mys3:backups/ --one-way -v

Команда покажет точный список несовпавших файлов, не трогая данные. Частая причина — VPN или прокси между сервером и хранилищем, который на лету пережимает или обрезает трафик; проверяется тестовой передачей напрямую, без туннеля.

Автоматизация без сюрпризов: cron, логи и алерты

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

Базовый cron с логированием:

# crontab -e
0 3 * * * /usr/bin/rclone sync /data mys3:backups/daily \
  --log-file /var/log/rclone-backup.log \
  --log-level INFO \
  --max-age 7d

Флаг --max-age 7d в связке с sync ограничивает синхронизацию свежими файлами, что ускоряет ежедневные проверки на больших архивах — rclone не пересчитывает то, что заведомо старше указанного возраста.

Отдельная и частая ошибка новичков: cron-задача с rclone падает молча, потому что у cron другой PATH и другой HOME, чем в интерактивной сессии, из-за чего rclone не находит конфиг. Указывайте путь к конфигу явно:

0 3 * * * /usr/bin/rclone sync /data mys3:backups/daily --config /etc/rclone/rclone.conf

Для контроля, что бекап действительно прошёл, а не завис, полезно завязать задачу на внешний пинг-мониторинг — сам rclone не умеет никого уведомлять при неудаче:

0 3 * * * /usr/bin/rclone sync /data mys3:backups/daily --config /etc/rclone/rclone.conf && curl -fsS -m 10 https://hc-ping.com/ваш-uuid

Если пинг не пришёл в ожидаемое окно — сервис мониторинга сам присылает алерт, и вы узнаёте о падении бекапа не через месяц, когда данные понадобятся. Подробнее про саму настройку такого мониторинга — в статье про мониторинг cron-задач через healthchecks.io. А если проблема не в rclone, а в самом cron — частые причины разобраны в статье про частые ошибки cron-задач на сервере.

Если в качестве хранилища используется собственный MinIO, а не внешний облачный провайдер, часть проблем с 403 и правами доступа снимается ещё на этапе настройки — см. частые ошибки MinIO на сервере и расчёт того, сколько ресурсов нужно VPS под бекапы и архив.

Частые вопросы