Домашний сервер живет по простому правилу: диски заполняются сами, а свободное место кончается всегда внезапно. Фотографии, записи с камер наблюдения, дампы баз и старые iso-образы складываются в стопку, и однажды единственный накопитель превращается в единую точку отказа. Вторая машина в кладовке с пустым диском на терабайт напрашивается на роль второго экземпляра, но таскать файлы вручную по ssh надоедает за неделю. Выход занимает один вечер: rclone зеркалит каталоги по расписанию, ограничивает скорость передачи по часам и дням недели, спасает перезаписанные файлы в отдельный каталог и сверяет результат контрольными суммами. Дальше разобран полный сценарий от установки до ночного таймера systemd, без облачных подписок, без графических панелей и с готовыми к копированию конфигурациями.
Один статический бинарник вместо облачной подписки
rclone написан на Go и распространяется одним исполняемым файлом: распаковал, положил в /usr/local/bin, сразу работаешь, никаких зависимостей и сборок. Заявлена поддержка более 70 облачных хранилищ, но для схемы из двух домашних машин хватает двух бэкендов, локальной файловой системы и sftp, который ездит поверх обычного ssh. Свежий релиз v1.76.0 вышел в начале ноября 2026 года, проект развивается активно, а конфигурации старых версий подхватываются новыми без переделок.
От rsync утилита выгодно отличается тем, что принимающей стороне достаточно ssh-службы с подсистемой sftp, а она включена по умолчанию в OpenSSH. rsync требует своей программы на обеих машинах, и когда на старом накопителе нет пакетного менеджера, это превращается в препятствие. rclone переносит время изменения файлов, сравнивает пары по размеру и дате, а по желанию и по суммам md5 или sha1. Есть и вещи, которых в rsync в таком виде нет: каталог --backup-dir для спасения перезаписанных копий и расписание лимитов скорости внутри одного флага.
Установка и ключ доступа между машинами
В дистрибутивных репозиториях пакет обычно старый, в Ubuntu 22.04, например, лежит версия 1.53.3, выпущенная в 2020 году. Свежую сборку ставит официальный скрипт, команда выполняется на обоих серверах:
sudo -v
curl https://rclone.org/install.sh | sudo bashДальше на первой машине, назовем ее nas1, создается отдельный ключ для этой задачи, а на принимающем сервере nas2 заранее заводится выделенный пользователь backup с правом записи только в каталог для копий:
ssh-keygen -t ed25519 -f ~/.ssh/nas2_rclone -N "" -C "rclone-nas1"
ssh-copy-id -i ~/.ssh/nas2_rclone.pub Адрес электронной почты защищен от спам-ботов. Для просмотра адреса в браузере должен быть включен Javascript. Каталог под архивы на nas2 создается один раз от администратора:
sudo mkdir -p /srv/pool/backup
sudo chown backup:backup /srv/pool/backupВыделенный пользователь здесь не паранойя, а удобство: если что-то пойдет не так, огрехи копирования останутся внутри одного каталога и не заденут систему.
Второй сервер как именованное хранилище в конфигурации
Свои удаленные машины rclone называет ремоутами и хранит их в текстовом файле ~/.config/rclone/rclone.conf, отдельном для каждого пользователя. Интерактивный rclone config проведет по вопросам: имя nas2, тип sftp, host 192.168.1.20, port пустой означает 22, user backup, пароль оставляем пустым, потому что дальше работает ключ, key_file /home/vasya/.ssh/nas2_rclone. Те же ответы одной командой без вопросов:
rclone config create nas2 sftp host 192.168.1.20 user backup key_file /home/vasya/.ssh/nas2_rcloneОтсюда практический вывод: службу, которая будет копировать по ночам, стоит запускать от того пользователя, у которого настраивался ремоут, иначе rclone просто не найдет nas2 в своей конфигурации.
Проверка связи перед большими объемами:
rclone lsd nas2:/srv/pool
rclone size nas2:/srv/pool/backupКоманда size печатает количество объектов и суммарный объем:
Total objects: 1.234k (1234)
Total size: 45.678 GiB (49045350212 Byte)Про пути есть коварная мелочь: nas2: без слэша означает домашний каталог пользователя backup, а nas2:/ открывает корень файловой системы. Забытый слэш не дает ошибки, а дает совсем другой каталог, и разница всплывет только в журнале, когда копия ляжет мимо.
Сначала сухой прогон, потом настоящая передача
У rclone есть copy и sync, и путать их опасно. copy только добавляет и обновляет файлы, ничего не удаляя. sync делает приемник точной копией источника и стирает на нем лишнее, разработчики прямо предупреждают о возможной потере данных и советуют первый прогон делать с --dry-run:
rclone sync -v --dry-run /srv/backup nas2:/pool/backupВывод покажет план без единой реальной операции:
2026/11/08 03:00:01 NOTICE: photos/archive-2025.tar.zst: Skipped copy as --dry-run is set (size 4.2Gi)
2026/11/08 03:00:02 NOTICE: scratch/scan-draft.txt: Skipped copy as --dry-run is set (size 12.4Ki)Если в списке оказался лишний путь, его отсекают фильтром вида --exclude "scratch/**". Когда план устраивает, флаг --dry-run убирается и sync выполняется по-настоящему. Для ручных запусков в терминале удобен флаг -P, он рисует живую статистику вместо потока строк журнала, и в конце прогона видно всё сразу:
Transferred: 4.2 GiB / 12.8 GiB, 33%, 28 MiB/s, ETA 5m12s
Checks: 1234 / 1234, 100%
Elapsed time: 5m12.3sСтраховку от случайного удаления дает связка с --backup-dir: перезаписанные и исчезнувшие из источника файлы rclone не стирает, а переносит в отдельный каталог на том же ремоуте:
rclone sync /srv/backup nas2:/pool/backup --backup-dir "nas2:/pool/trash/$(date +%F)"Подкаталог с датой собирает bash, поэтому старые версии накапливаются по дням. Требование у флага жесткое: каталог должен лежать на том же хранилище, что и приемник, и не пересекаться с ним по пути.
Ограничение скорости по часам и дням недели
Флаг --bwlimit задает потолок полосы, и главное здесь единицы измерения: rclone считает байтами в секунду, а не битами, значит --bwlimit 10M держит 10 МиБ/с, это около 84 Мбит/с. По умолчанию ограничений нет, значение 0 означает полную скорость. Отдачу и прием можно ограничить раздельно в формате UP:DOWN, например --bwlimit 10M:off зажимает только отдачу.
Настоящая сила флага в расписании. Гигабитная домашняя сеть честно отдаст синхронизации весь канал, и тогда телевизор зависнет на середине фильма, а пинг в сетевых играх взлетит до смешного. Расписание снимает конфликт: пока дома люди, копирование идет тихо, ночью канал отдается целиком:
rclone sync /srv/backup nas2:/pool/backup --bwlimit "08:00,10M 23:00,off"С восьми утра действует потолок 10 МиБ/с, после одиннадцати вечера ограничение снимается. Слот читается как время и через запятую скорость, между записями пробел, действует ближайший наступивший. Дни недели пишутся перед временем, запись Mon-00:00,512 зажимает понедельник до 512 КиБ/с. Если окружение ломает пробелы, например внутри Docker, записи разделяют точкой с запятой.
Перед выбором цифры канал стоит измерить, а не угадывать. Утилита iperf3 между nas1 и nas2 показывает реальную полосу без ограничений: на честном гигабите это обычно 940 Мбит/с, то есть около 112 МиБ/с. От этой цифры и отсчитывают долю синхронизации: треть канала днем, остальное ночью. Точное число внутри флага подбирается за пару вечеров наблюдений, когда видно, что происходит с фильмом и пингом во время прогона.
Пара цифр для планирования. Первая полная копия 500 ГБ при потолке 30 МиБ/с займет около 4,7 часа, значит одного ночного окна хватает с запасом. Дальше таскаются только изменения, и на типичном домашнем архиве это единицы гигабайт в месяц. Параллельных потоков передачи по умолчанию четыре, параметр --transfers, и общий лимит --bwlimit они делят между собой, а не умножают. Для умных роутеров с QoS есть отдельный бонус: --dscp LE помечает пакеты низшим классом scavenger из RFC 8622, и маршрутизатор понижает приоритет такого трафика без искусственных потолков.
Ночной таймер systemd вместо cron
Разовые запуски хороши для отладки, а штатный режим - это расписание. Подойдет таймер systemd, и у него перед cron два преимущества: Persistent=true догоняет пропущенный запуск, если сервер был выключен, а журналы оседают в journald вместе со всем остальным. Создаются два файла.
/etc/systemd/system/rclone-sync.service:
[Unit]
Description=Ночная синхронизация бэкапов на второй сервер
After=network-online.target
Wants=network-online.target
[Service]
Type=oneshot
ExecStart=/bin/sh -c '/usr/bin/rclone sync /srv/backup nas2:/pool/backup --backup-dir "nas2:/pool/trash/$(date +%%F)" --bwlimit "08:00,10M 23:00,off" --log-level INFO'Двойной процент в $(date +%%F) не опечатка: systemd сам раскрывает знак процента в своих файлах, поэтому для оболочки его удваивают. Оболочка /bin/sh -c нужна, чтобы подстановка даты и вложенные кавычки обработались корректно.
/etc/systemd/system/rclone-sync.timer:
[Unit]
Description=Расписание ночной синхронизации
[Timer]
OnCalendar=*-*-* 03:00:00
RandomizedDelaySec=10m
Persistent=true
[Install]
WantedBy=timers.targetТри часа ночи выбраны не с потолка: суточные задачи обновлений и проверки дисков обычно приходятся на два часа, и наложение дорого обошлось бы обеим. RandomizedDelaySec размазывает старт на десять минут. До включения расписания службу стоит один раз запустить руками: sudo systemctl start rclone-sync.service, затем systemctl status rclone-sync.service покажет код возврата и последние строки журнала. Код 0 означает, что копирование прошло чисто и таймеру можно доверять ночь.
Включение и первая проверка:
sudo systemctl daemon-reload
sudo systemctl enable --now rclone-sync.timer
systemctl list-timers | grep rclone
journalctl -u rclone-sync.service -n 50Если службу пускает root, ремоут настраивается тоже от root: rclone config выполняется с его правами, ключ кладется в /root/.ssh с правами 600, путь к нему вписывается в конфигурацию. Альтернатива, секция User=имя в [Service], работает так же надежно.
Проверка целостности, восстановление и уборка старых копий
Копия, в правильности которой нет уверенности, не копия. rclone check сверяет источник и приемник по размеру и контрольным суммам:
rclone check /srv/backup nas2:/pool/backupИтог печатается в конце двумя строками:
2026/11/08 09:12:44 NOTICE: /srv/backup vs nas2:/pool/backup: 0 differences found
2026/11/08 09:12:44 NOTICE: /srv/backup vs nas2:/pool/backup: 1234 matching filesДля жесткой ревизии, когда хочется убедиться в самих данных, а не в метаданных, добавляется --download: обе стороны читаются полностью и сверяются на лету. Операция тяжелая, поэтому ей место в ежеквартальном регламенте, а не в каждом ночном прогоне. Флаг --one-way ограничивает проверку правилом "файл источника должен существовать на приемнике". Отдельная удобная команда rclone md5sum nas2:/pool/backup печатает таблицу сумм в том же формате, что и классический md5sum, поэтому старые сверки, лежащие в текстовых файлах, продолжают собираться без переписывания скриптов.
Восстановление выглядит как тот же copy в обратную сторону, и никаких sync, чтобы при сбое не задеть рабочий каталог:
rclone copy nas2:/pool/backup /srv/restore -PФлаг -P рисует прогресс со скоростью и оценкой времени. Старые версии из trash убираются по мере накопления: rclone purge nas2:/pool/trash/2026-08-05 сносит каталог вместе с содержимым, а rclone delete --min-age 90d nas2:/pool/trash удаляет только файлы старше девяноста дней по всему дереву. Срок хранения подбирается от объема диска на nas2 и аппетитов источника.
Весь порядок внедрения умещается в один вечер:
- установить rclone на обеих машинах и убедиться, что rclone version показывает свежий номер;
- создать ключ ed25519 и отдать его пользователю backup на принимающем сервере;
- завести ремоут nas2 командой rclone config create и проверить связь через rclone lsd;
- выполнить пробный rclone sync с --dry-run и разобрать список будущих операций;
- подобрать лимит --bwlimit так, чтобы вечерний интернет оставался живым;
- положить оба unit-файла в /etc/systemd/system и включить таймер.
После первого ночного прогона настройка заканчивается сама собой: утром на втором сервере лежит вчерашнее состояние архива, сеть за ночь не заметила ни одного гигабайта, а для полной проверки достаточно вспомнить одну команду check. Облако в такой схеме нужно ровно одному человеку, маркетологу хостинга, а домашние данные остаются дома, на двух железных ящиках, между которыми ходит тихий, вежливый и предсказуемый rclone.