Синхронизация серверного каталога с облачным хранилищем редко остаётся одной командой. Сначала хватает простого копирования, потом появляется второй сервер, желание закрыть содержимое от посторонних и потребность принимать правки с обеих сторон, а файлы в облаке должны оставаться закрытыми. Rclone закрывает обе задачи одним инструментом: единый интерфейс к десяткам облачных хранилищ, именованные remote в конфигурации, шифрование всего, что уходит наружу, проверка результата по хэшам. В материале собрана рабочая схема от первого remote до двустороннего режима bisync, слоя crypt, команды check и расписания в cron.
Именованные remote в конфигурации rclone и первый вход в облачное хранилище
Работа с rclone начинается не с команд, а с конфигурации. Любое хранилище описывается именованным remote: за коротким именем скрываются тип подключения, ключи доступа и адрес сервера. Параметры лежат в файле rclone.conf, у стандартной установки Linux это каталог .config/rclone внутри домашней папки, путь переопределяется флагом --config или переменной окружения RCLONE_CONFIG.
Базовая настройка идёт через меню команды rclone config: утилита предложит создать remote, покажет список типов хранилищ и задаст вопросы по выбранному варианту. Для S3-совместимых хранилищ достаточно пары ключей и адреса сервера, для файловых сервисов rclone предложит войти в аккаунт через браузер и сохранить токен обновления, продлевая его без участия человека. Для скриптов есть неинтерактивный rclone config create с параметрами в аргументах.
Имена remote продумывают сразу: имя фигурирует в командах, скриптах и расписании, а для разных задач держат отдельные remote, для проектов, архива и шифрованной копии.
rclone config
rclone listremotes
rclone lsd storage:
rclone ls storage:backupПосле настройки соединение проверяют сразу: rclone listremotes выведет список имён, rclone lsd покажет каталоги хранилища, rclone ls перечислит содержимое. Файл конфигурации закрывают от посторонних: внутри ключи и токены, права меняют командой chmod 600 ~/.config/rclone/rclone.conf, а файл не хранят в репозитории и не пересылают в открытом виде.
Команды copy и sync и осторожность при удалении лишних файлов на приёмнике
Две базовые команды похожи, но различаются поведением, за которое регулярно платят удалёнными файлами. Команда copy переносит новые и обновлённые файлы и никогда ничего не удаляет: лишнее на приёмнике останется там, даже если исчезло из источника. Команда sync строит точное зеркало: приёмник повторяет источник файл в файл, а всё лишнее на приёмнике исчезает без корзины. Цена ошибки измеряется целым каталогом.
rclone copy /srv/projects storage:projects --transfers 8
rclone sync /srv/projects storage:projects --dry-run
rclone sync /srv/projects storage:projects --max-delete 100 --backup-dir storage:archive/$(date +%F)Перед sync принято выполнять прогон с флагом --dry-run: rclone перечислит будущие действия, но не тронет ни один файл. Флаг --max-delete задаёт предел на удаления за один прогон и останавливает операцию, когда реальность расходится с ожиданиями. Флаг --backup-dir переносит файлы, которые sync собирался удалить или заменить, в отдельный каталог с прежними путями, оттуда состояние возвращается командой copy. Заодно это страховка от перепутанных сторон: если поменять местами источник и приёмник, sync молча сотрёт свежие данные с локального диска, и только лимит на удаления спасёт от масштабной потери.
Решение о копировании rclone принимает по размеру и времени изменения, содержимое байт в байт по умолчанию не сверяется. Если хранилище поддерживает хэши, помогает флаг --checksum, если не хранит время изменения честно, выручает --size-only. Параллелизм регулируют флагами --transfers и --checkers, прогресс показывает -P.
Двусторонняя синхронизация bisync с начальной подготовкой и хранением состояний
Одностороннего зеркала хватает, пока правки идут с одной стороны. Когда файлы меняют и на сервере, и в облаке, нужен двусторонний режим bisync. Честно говоря, в справке rclone его называют менее зрелым, чем copy и sync, и этот статус стоит принять всерьёз: режим рассчитан на регулярные циклы и аккуратный первый запуск.
Логика держится на сохранённых состояниях обеих сторон. После каждого цикла bisync записывает списки файлов слева и справа, в следующем цикле сравнивает текущую картину с прежней и переносит расхождения: новый файл уходит на другую сторону, исчезнувший пропадает и там, изменившийся копируется по времени изменения, а переименование проходит как исчезновение старого пути и появление нового. Если один и тот же файл изменился с обеих сторон между циклами, bisync не выбирает победителя вслепую, он отмечает спорный путь в отчёте и завершает цикл с ошибкой.
Первый запуск выполняется с ключом --resync и складывается в строгую последовательность:
1. Определите сторону истины и укажите её в команде первой, ключ --resync сначала прогоняет одностороннюю синхронизацию от первой стороны ко второй, лишние файлы на второй стороне исчезнут;
2. Запустите rclone bisync /srv/projects storage:projects --resync --dry-run и прочитайте отчёт репетиции полностью;
3. Повторите запуск без --dry-run и убедитесь, что файлы состояний записаны в служебный каталог rclone, у типичной установки это подкаталог .cache/rclone в домашней папке пользователя;
4. Скопируйте каталог состояний в надёжное место командой rclone copy, это страховка от повторной начальной подготовки;
5. Запустите следующий цикл без --resync, добейтесь чистого прохождения и переносите команду в расписание.
Дальше действует жёсткое правило: два экземпляра bisync по одной паре путей не запускают, состояния перепутаются, служебный файл блокировки страхует лишь отчасти. Лимит --max-delete здесь работает так же, как в sync, и первое время его держат небольшим. Если правки приходят с двух сторон регулярно, уменьшайте интервал между циклами: bisync мирится с правками с обеих сторон, но не угадывает, какая версия главнее, когда менялись обе.
Шифрование через crypt поверх готового remote и политика паролей
Второй частый запрос, чтобы провайдер хранилища не видел содержимого. Rclone решает его слоем crypt: поверх существующего remote создаётся новый, при записи в него шифруются содержимое и имена файлов, при чтении расшифровываются обратно. На стороне хранилища лежат бессмысленные имена и нечитаемые данные, а администратор работает с привычными путями.
Настройка идёт в том же меню rclone config: выбирается тип crypt, указывается путь поверх готового remote в формате storage:backup, подойдёт и вложенный подкаталог, затем задаются два секрета, пароль и соль. Соль смешивается с паролем и увеличивает стойкость шифрования к перебору. Оба значения rclone прячет в конфигурации, но это скрытие, а не крепкая защита, поэтому файл rclone.conf берегут отдельно. Главное правило простое: потеря любого из двух секретов означает потерю содержимого навсегда, восстановить его не сможет ни разработчик утилиты, ни провайдер.
Готовая секция конфигурации выглядит так:
[backup-crypt]
type = crypt
remote = storage:backup
filename_encryption = standard
directory_name_encryption = trueПараметр filename_encryption допускает три значения. Значение standard шифрует имена полностью, файлы в облаке получают длинные нечитаемые имена из безопасного алфавита, obfuscate лишь маскирует имена, не разрывая структуру, off оставляет имена открытыми и шифрует только содержимое. Параметр directory_name_encryption распространяет шифрование на имена каталогов: при выключенном значении структура папок останется видимой, что иногда выдаёт больше, чем хотелось бы. Работа с шифрованным remote не отличается от обычного:
rclone copy /srv/projects backup-crypt:projects
rclone ls backup-crypt:projects
rclone ncdu backup-crypt:backupУ crypt есть цена. Зашифрованные данные не получится скопировать внутри хранилища серверными средствами провайдера, любая операция между crypt и открытым remote идёт через локальную машину с расшифровкой и новым шифрованием. Зашифрованная копия занимает чуть больше места из-за служебных заголовков, а длинные имена иногда упираются в лимиты хранилища. Вдобавок rclone умеет закрыть паролем весь файл конфигурации, тогда секрет запрашивается при каждом запуске или читается из переменной окружения, и утёкший конфиг перестаёт быть ключом от всех хранилищ.
Проверка целостности командой check по хэшам и размерам файлов
Копирование прошло, но доверять отчёту команды слепо не стоит. Команда check сверяет источник и приёмник по хэшам и размерам, не трогая файлы, и выводит счётчики совпавших, различающихся и отсутствующих с каждой стороны. Расхождение после переноса терабайтов обиднее любой медленной загрузки.
rclone check /srv/projects storage:projects
rclone check /srv/projects backup-crypt:projects
rclone cryptcheck /srv/projects backup-crypt:Для пары из открытого каталога и шифрованного remote есть отдельная команда cryptcheck, она сверяет исходные файлы с их зашифрованными копиями. Не каждое хранилище отдаёт хэши, в этом случае выручает флаг --download: rclone скачивает файлы с приёмника и сравнивает содержимое, дольше, зато без иллюзий. Проверку ставят сразу после первого переноса и повторяют периодически, при расхождениях команда завершается с ненулевым кодом, поэтому её вызывают из скрипта после каждой синхронизации: ошибка попадёт в журнал и в мониторинг, молчаливое расхождение дороже громкой ошибки.
Фильтры включения и исключения файлов в повседневных командах rclone
Реальные каталоги редко синхронизируются целиком: в них мешаются временные файлы, кэши инструментов, крупные архивы и служебные каталоги систем контроля версий. Для отбора у rclone есть флаги --include и --exclude для быстрых случаев, --filter для явного набора правил и --filter-from для файла правил, который хранится рядом со скриптами.
rclone sync /srv/projects storage:projects --exclude "*.tmp" --exclude ".git/**"Правила читаются по порядку, применяется первое подходящее, поэтому последовательность имеет значение. Шаблон покрывает имена в пределах одного каталога, * - все вложенные уровни. Флаг --include работает как белый список, а --delete-excluded заставляет sync удалять на приёмнике и файлы под исключением, пользоваться им стоит с чётким пониманием, что попадает под правило. Для bisync правила держат в отдельном файле и передают флагом --filters-file, не меняя от цикла к циклу. Файл правил для каталога проектов выглядит так:
- *.tmp
- *.log
- /media/**
+ /**Правила записываются относительно корня переноса, ведущий символ / привязывает шаблон к корню, без него шаблон применяется к именам на любой глубине. Файл выше исключает временные файлы и журналы где бы то ни было, целиком убирает подкаталог media и возвращает в набор всё остальное последней строкой.
Расписание в cron и резервные копии каталога состояний bisync
Ручные прогоны хороши для отладки, рабочая схема живёт в расписании. Для bisync удобно выделить ночное окно и защититься от параллельных запусков утилитой flock, она не даст новому циклу начаться, пока не закончился прежний.
30 2 * * * flock -n /run/lock/rclone-bisync.lock rclone bisync /srv/projects storage:projects --max-delete 25 --filters-file /etc/rclone/bisync.filters --log-file /var/log/rclone/bisync.log --log-level INFOЖурнал ведёт флаг --log-file, уровень задаётся --log-level, файл журнала подключают к logrotate, иначе за год он растолстеет до неудобных размеров. Код возврата bisync обрабатывают: при ошибке администратору нужно письмо или запись в системе мониторинга.
Каталог состояний bisync невелик, но критичен, его копируют в надёжное место после каждого успешного цикла:
rclone copy $HOME/.cache/rclone/bisync storage:states/bisyncЕсли состояния потеряны, двусторонний режим вернётся к первому запуску: сторона истины, ключ --resync, новая запись состояний. Резервная копия сокращает восстановление до одной команды copy. Синхронизация сама по себе не заменяет резервное копирование: bisync честно разносит по сторонам и ошибочные удаления, поэтому рядом с рабочей схемой держат архив с историей версий и независимую копию на отдельном носителе. Связка из именованных remote, осторожного sync с --backup-dir, bisync с состояниями и слоя crypt собирается за вечер и работает сама.