Как установить и настроить rclone на VPS

MAATRIX

Когда данные на сервере нужно синхронизировать с облачным хранилищем — выгрузить бэкапы в S3, забрать файлы из Google Drive или зеркалировать каталог в Backblaze — обычный scp или rsync не подходит: у облачных хранилищ свой API, а не файловая система. rclone решает эту задачу: это одна утилита командной строки, которая одинаково работает с десятками облачных провайдеров и локальными дисками. Ниже — установка, настройка под конкретные хранилища и рабочие сценарии автоматизации.

Установка rclone на VPS

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

sudo -v
curl https://rclone.org/install.sh | sudo bash

Если не хочется гнать скрипт из интернета через sudo, тот же результат даёт бинарник вручную:

cd /tmp
curl -O https://downloads.rclone.org/rclone-current-linux-amd64.zip
unzip rclone-current-linux-amd64.zip
cd rclone-*-linux-amd64
sudo cp rclone /usr/bin/
sudo chown root:root /usr/bin/rclone
sudo chmod 755 /usr/bin/rclone
sudo mkdir -p /usr/local/share/man/man1
sudo cp rclone.1 /usr/local/share/man/man1/
sudo mandb 2>/dev/null || true

Для ARM-серверов замените amd64 на arm64 в имени архива. Пакет в стандартных репозиториях Ubuntu/Debian (apt install rclone) тоже работает, но обычно отстаёт на несколько версий — для S3-совместимых бэкендов и rclone mount лучше брать актуальную версию через скрипт.

Проверка:

rclone version

Команда покажет версию самого rclone, версию Go и платформу — если вывод есть, установка прошла успешно.

Настройка удалённого хранилища через rclone config

Вся настройка хранилищ («remotes» в терминологии rclone) идёт через интерактивный мастер:

rclone config

Пример для S3-совместимого хранилища (подходит для AWS S3, Backblaze B2 через S3 API, Selectel, Yandex Object Storage):

1. n — новый remote, задайте имя, например mybackup.
2. Тип хранилища — введите s3.
3. Provider — выберите из списка (AWS, Other для остальных S3-совместимых сервисов).
4. access_key_id и secret_access_key — берутся из личного кабинета провайдера.
5. Region и endpoint — для не-AWS сервисов endpoint обязателен, например s3.us-east-005.backblazeb2.com для Backblaze.
6. Остальные параметры (acl, storage_class) можно оставить по умолчанию — Enter пропускает шаг.

Для Google Drive процесс отличается: rclone откроет браузерную авторизацию OAuth. На VPS без графического интерфейса это неудобно — мастер предложит вариант rclone authorize, который выполняется на локальной машине с браузером, а полученный токен вставляется обратно в конфиг на сервере. Шаги:

# на VPS
rclone config
# выбрать n → drive → согласиться на auto config: N

# на локальной машине с браузером
rclone authorize "drive"
# скопировать полученный токен

# вернуться в rclone config на VPS и вставить токен

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

rclone lsd mybackup:

Команда покажет список бакетов или папок верхнего уровня — если хранилище видно, конфигурация верна.

Неинтерактивная настройка для автоматизации

Для автоматических деплоев или Ansible-плейбуков интерактивный мастер неудобен — можно прописать remote напрямую в конфиг-файл. По умолчанию он лежит в ~/.config/rclone/rclone.conf:

[mybackup]
type = s3
provider = Other
access_key_id = YOUR_ACCESS_KEY
secret_access_key = YOUR_SECRET_KEY
endpoint = s3.us-east-005.backblazeb2.com
acl = private

[gdrive]
type = drive
client_id =
client_secret =
scope = drive
token = {"access_token":"...","token_type":"Bearer","refresh_token":"...","expiry":"..."}

Секреты в открытом виде в конфиге — не лучшая практика для продакшна. rclone поддерживает шифрование самого конфиг-файла паролем:

rclone config
# в главном меню: s) Set configuration password

После этого при каждом запуске rclone будет спрашивать пароль (или брать его из переменной окружения RCLONE_CONFIG_PASS для автоматизации без интерактивного ввода). Для CI/CD и systemd-сервисов такой пароль удобно хранить в отдельном env-файле с правами 600, недоступном другим пользователям.

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

У rclone несколько команд для переноса данных, и путаница между copy и sync — частая причина потерянных файлов:

Примеры:

# скопировать локальную папку в бакет, ничего не удаляя
rclone copy /var/backups mybackup:server-backups --progress

# зеркалировать с удалением лишних файлов на удалённой стороне —
# сначала обязательно проверьте dry-run
rclone sync /var/www mybackup:site-mirror --dry-run
rclone sync /var/www mybackup:site-mirror

# скачать файлы из облака на сервер
rclone copy mybackup:server-backups /var/backups/restore

# сравнить локальную и удалённую копию без изменений
rclone check /var/www mybackup:site-mirror

Полезные флаги для продакшна: --transfers 8 (количество параллельных передач), --bwlimit 10M (ограничение скорости, чтобы не забить канал сервера), --log-file /var/log/rclone.log --log-level INFO (лог вместо вывода в консоль), --exclude "*.tmp" (исключить временные файлы по маске).

Автоматизация через cron

Для регулярной синхронизации проще всего добавить задачу в cron. Пример — ежедневная выгрузка бэкапов в 3 часа ночи с логированием:

crontab -e

0 3 * * * /usr/bin/rclone sync /var/backups mybackup:server-backups --log-file /var/log/rclone-backup.log --log-level INFO

Если задачи требуют более сложной логики (проверка успешности, уведомления об ошибках, ретраи), оберните вызов в shell-скрипт:

#!/bin/bash
set -e
LOGFILE="/var/log/rclone-backup.log"
rclone sync /var/backups mybackup:server-backups --log-file "$LOGFILE" --log-level INFO
if [ $? -ne 0 ]; then
  echo "rclone sync failed $(date)" >> /var/log/rclone-errors.log
fi

Настройку самих cron-выражений и типичные ошибки (например, забытый PATH в crontab, из-за которого бинарник не находится) разобраны отдельно в статье про настройку cron-задач на VPS. Как вариант посерьёзнее cron — можно завернуть rclone-задачи в docker-compose со своим планировщиком, готовый файл под это разобран в статье про rclone в Docker Compose.

Шифрование и монтирование как диска

Если данные в облаке должны быть зашифрованы независимо от того, шифрует ли что-то сам провайдер, rclone умеет создавать поверх обычного remote «шифрующий» слой — crypt. Через rclone config выбирается тип crypt, указывается remote-приёмник (например, mybackup:encrypted-data) и задаётся пароль шифрования. После этого все файлы, записанные через crypt-remote, на стороне облака выглядят как случайный набор байт с обфусцированными именами — расшифровать их можно только зная пароль. Такой подход хорошо сочетается с уже настроенным резервным копированием через borgbackup, если нужно и локальное шифрованное хранилище, и облачную копию с независимым шифрованием.

Отдельная возможность — примонтировать облако как обычную файловую систему через FUSE:

sudo apt install fuse3
mkdir -p /mnt/cloud
rclone mount mybackup:server-backups /mnt/cloud --daemon --vfs-cache-mode writes

Это удобно для разовой работы с файлами через обычные cp/ls, но для постоянной высоконагруженной синхронизации mount работает медленнее и менее предсказуемо, чем прямые команды copy/sync — используйте его для разовых задач, а не как постоянный сервис.

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