rclone на Ubuntu 24.04: пошаговая установка

MAATRIX

Если вы храните бэкапы на одном сервере, при его потере вы теряете и данные, и копии — это классическая ошибка, которая вскрывается только в момент аварии. rclone решает эту задачу: он копирует и синхронизирует файлы между сервером и облачными хранилищами (S3-совместимыми, Google Drive, Backblaze B2 и десятками других) из командной строки, без веб-интерфейсов и ручного перетаскивания файлов. Ниже — рабочая установка и настройка на чистой Ubuntu 24.04, с автоматизацией и типичными граблями.

Установка rclone на Ubuntu 24.04

В репозиториях Ubuntu 24.04 лежит rclone, но обычно устаревшей версии — новые провайдеры и флаги (например, часть S3-совместимых бэкендов) в ней могут не поддерживаться. Проверить, что даёт apt:

apt-cache policy rclone

Если версия вас не устраивает, ставьте через официальный скрипт — он сам подберёт актуальный релиз под архитектуру сервера:

sudo apt update
sudo apt install -y unzip
curl https://rclone.org/install.sh | sudo bash

Скрипт скачивает бинарник с официального сайта rclone.org, распаковывает в /usr/bin/rclone и ставит man-страницу. Через apt тоже работает, если версия из репозитория вас устраивает и вы не хотите тянуть внешний скрипт на прод:

sudo apt install -y rclone

Проверьте версию после установки:

rclone version

Если планируете монтировать облако как локальную папку (раздел про mount ниже), сразу поставьте FUSE:

sudo apt install -y fuse3

Отдельного systemd-юнита для самого rclone не требуется — он не демон, а обычная утилита командной строки. Демоном при необходимости станет либо rclone mount, либо задачи cron/systemd timer, которые запускают rclone sync по расписанию.

Подключение облачных хранилищ: S3, Google Drive, Backblaze

Вся конфигурация хранится в одном файле, ~/.config/rclone/rclone.conf (для рута — /root/.config/rclone/rclone.conf). Проще всего заполнить его через интерактивный мастер:

rclone config

Мастер спросит имя «remote» (произвольное, например s3backup), тип бэкенда и данные доступа. Дальше — по типам хранилищ.

S3-совместимое хранилище (Amazon S3, или любой S3-совместимый провайдер, включая MinIO на вашем же сервере). Понадобятся Access Key ID, Secret Access Key, регион и endpoint (для не-Amazon хранилищ endpoint обязателен). Через rclone config выбираете тип s3, провайдера (AWS, Other для остальных S3-совместимых), вводите ключи. Итоговый блок в rclone.conf выглядит так:

[s3backup]
type = s3
provider = Other
access_key_id = YOUR_ACCESS_KEY
secret_access_key = YOUR_SECRET_KEY
endpoint = s3.example-provider.com
region = us-east-1

Backblaze B2 — дешёвый вариант для хранения бэкапов. Нужны Key ID и Application Key из панели B2:

[b2backup]
type = b2
account = YOUR_KEY_ID
key = YOUR_APPLICATION_KEY

Google Drive — авторизация через OAuth. На сервере без графического окружения мастер rclone config предложит либо открыть ссылку на другой машине с браузером и вставить код, либо (если у вас есть локальный rclone) выполнить rclone authorize "drive" на своём компьютере и скопировать полученный токен на сервер. Это единственный из трёх вариантов, где придётся один раз пройти браузерную авторизацию — доступ по чистым ключам API Google Drive не выдаёт.

После настройки проверьте, что remote видит хранилище:

rclone lsd s3backup:
rclone lsd b2backup:
rclone lsd gdrive:

Файл rclone.conf содержит секреты в открытом виде (кроме случаев, когда вы явно задали пароль на сам конфиг через rclone config → Set configuration password). Ограничьте права на файл:

chmod 600 ~/.config/rclone/rclone.conf

Если нужно передать значение пароля в скрипт, не храня его в открытом виде в командной строке, используйте rclone obscure — он обфусцирует строку для вставки в конфиг (это не криптостойкое шифрование, а защита от случайного считывания через ps или history).

Основные команды: copy, sync, move, check

Четыре команды покрывают почти все сценарии.

rclone copy — копирует файлы, ничего не удаляя в источнике и назначении. Безопасный вариант для регулярного докидывания данных:

rclone copy /var/backups s3backup:my-bucket/backups --progress

rclone sync — приводит назначение к точному виду источника, удаляя в назначении всё, чего нет в источнике. Мощный инструмент и одновременно самый опасный — перепутанные местами источник и назначение сотрут данные в облаке:

rclone sync /var/backups s3backup:my-bucket/backups --progress

Перед первым запуском sync на реальных данных обязательно прогоните --dry-run — команда покажет, что было бы сделано, без реальных изменений:

rclone sync /var/backups s3backup:my-bucket/backups --dry-run

rclone move — как copy, но с удалением файлов из источника после успешного переноса. Полезно для разгрузки локального диска.

rclone check — сверяет источник и назначение без передачи данных, полезно после большого переноса для контроля целостности:

rclone check /var/backups s3backup:my-bucket/backups

Если нужно работать с облаком как с обычной папкой (например, отдавать файлы через nginx напрямую из S3), можно смонтировать remote через FUSE:

sudo mkdir -p /mnt/s3backup
rclone mount s3backup:my-bucket /mnt/s3backup --vfs-cache-mode writes --allow-other --daemon

Для --allow-other нужно раскомментировать user_allow_other в /etc/fuse.conf. Учтите: FUSE-монтирование удобно для чтения и разовой работы с файлами, но не рассчитано на нагрузку продакшен-СУБД или частую конкурентную запись — под такие сценарии лучше copy/sync по расписанию, а не постоянно смонтированный том.

Автоматизация бэкапов через cron и systemd

Для регулярной выгрузки бэкапов проще всего завести задачу cron. Отредактируйте crontab нужного пользователя:

crontab -e

И добавьте ежедневную синхронизацию в 3 ночи с логированием и защитой от параллельного запуска через flock:

0 3 * * * /usr/bin/flock -n /tmp/rclone-backup.lock /usr/bin/rclone sync /var/backups s3backup:my-bucket/backups --log-file=/var/log/rclone-backup.log --log-level INFO

flock -n не даст запуститься второй копии, если предыдущая синхронизация ещё не закончилась (актуально при большом объёме данных или медленном канале).

Для более прозрачного контроля — что запустилось, когда упало, какой был exit code — удобнее systemd-таймер вместо cron. Юнит сервиса /etc/systemd/system/rclone-backup.service:

[Unit]
Description=rclone backup sync to S3

[Service]
Type=oneshot
ExecStart=/usr/bin/rclone sync /var/backups s3backup:my-bucket/backups --log-level INFO
User=backup

Таймер /etc/systemd/system/rclone-backup.timer:

[Unit]
Description=Daily rclone backup

[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true

[Install]
WantedBy=timers.target

Активация:

sudo systemctl daemon-reload
sudo systemctl enable --now rclone-backup.timer

Persistent=true гарантирует, что если сервер был выключен в момент запуска (например, во время планового обслуживания), таймер отработает при следующей загрузке. Статус и историю запусков смотрите через systemctl status rclone-backup.timer и journalctl -u rclone-backup.service.

Шифрование, лимит скорости и логирование

Если облачное хранилище не ваше собственное (сторонний провайдер), разумно шифровать данные перед загрузкой — так провайдер не увидит содержимое файлов даже при доступе к бакету. rclone умеет оборачивать любой remote в шифрующий слой crypt:

rclone config
# n) New remote
# name: s3crypt
# type: crypt
# remote: s3backup:my-bucket/encrypted
# filename_encryption: standard
# (задаёте пароль на шифрование — сохраните его отдельно, без него данные не восстановить)

После этого работаете с s3crypt: как с обычным remote — rclone шифрует файлы и их имена на лету при copy/sync, а при чтении расшифровывает обратно.

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

rclone sync /var/backups s3backup:my-bucket/backups --bwlimit 08:00,10M 20:00,off

Здесь с 8:00 скорость ограничена 10 МБ/с, а с 20:00 (в нерабочее время) ограничение снимается. Формат --bwlimit поддерживает и постоянное значение вроде --bwlimit 5M, если расписание не нужно.

Для больших объёмов мелких файлов важны --transfers (число параллельных передач) и --checkers (число параллельных проверок) — по умолчанию 4, для канала с запасом можно поднять:

rclone sync /var/backups s3backup:my-bucket/backups --transfers 16 --checkers 16

Оптимальные значения зависят от вашего канала и лимитов API у провайдера хранилища — начните с дефолтных и поднимайте постепенно, наблюдая за логом и ошибками throttling. Логи --log-file растут без ограничения — добавьте ротацию через logrotate, если планируете хранить историю:

/var/log/rclone-backup.log {
    weekly
    rotate 8
    compress
    missingok
    notifempty
}

Типичные ошибки и их решение

403 Forbidden при обращении к S3-бакету. Чаще всего — неверный region или endpoint в конфиге, либо у ключа доступа нет прав на конкретный бакет. Проверьте политику доступа (bucket policy / IAM) на стороне провайдера и сверьте endpoint из его документации.

fusermount: failed to open /dev/fuse при rclone mount. Не установлен пакет fuse3 или модуль не загружен. Установите sudo apt install fuse3 и проверьте modprobe fuse.

mount helper error: fuse device not found в контейнере или на некоторых VPS с урезанным ядром. Часть облачных провайдеров ограничивает доступ к /dev/fuse для виртуальных машин без явного разрешения. Если mount недоступен в принципе, используйте copy/sync по расписанию вместо постоянного монтирования.

Токен Google Drive протух, синхронизация падает с ошибкой авторизации. OAuth-токены Google Drive периодически требуют обновления. Перезапустите rclone config reconnect gdrive: — это обновит токен без повторного ввода всех параметров remote.

Синхронизация внезапно удалила файлы в облаке. Почти всегда — перепутанные местами источник и назначение в rclone sync, либо запуск без предварительного --dry-run. Для критичных бэкапов добавьте --backup-dir /path/to/deleted — тогда sync не удаляет файлы безвозвратно, а переносит их в отдельную папку перед удалением из основного назначения.

Синхронизация ощутимо медленнее, чем ожидалось на большом количестве мелких файлов. Узкое место обычно не в пропускной способности канала, а в количестве запросов к API хранилища — каждый мелкий файл это отдельный HTTP-запрос. Поднимите --transfers и --checkers, но учитывайте лимиты запросов у конкретного провайдера — слишком агрессивные значения приводят к throttling и ошибкам 429.

Скорость и стабильность бэкапов зависят и от самого сервера — канала и диска. Перед тем как доверить серверу регулярные бэкапы, полезно свериться с чек-листом безопасности нового сервера и настроить SSH-ключи вместо пароля.

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