В 2026 году «синхронизация файлов» в админской реальности всё ещё означает не UI и «магическую кнопку», а предсказуемое поведение: что будет при обрыве сети, при частично записанном файле, при конфликте правок, при удалениях и при необходимости шифрования. И главное — как это потом сопровождать в production, чтобы не просыпаться от алертов в 03:00.
Ниже — практическое сравнение четырёх инструментов, которые чаще всего встречаются у админов и DevOps: rsync, rclone, syncthing и unison. Я отталкиваюсь от сценариев: зеркалирование «источник → реплика», репликация между серверами, синк в S3-совместимое объектное хранилище, двусторонняя синхронизация рабочих директорий и деплой статики.
О чём на самом деле спор «rsync vs rclone vs syncthing vs unison»
Название вводит в заблуждение: задачи похожи, но ответы на ключевые вопросы у инструментов разные.
- Топология: «один источник → много приёмников» (push), «много узлов ↔ много узлов» (mesh), «клиент ↔ объектное хранилище».
- Односторонняя или двусторонняя: нужна реплика (mirror) или полноценная двусторонняя синхронизация с конфликтами.
- Где живут данные: локальный диск/SSH/демон на узлах или объектное хранилище (S3/WebDAV и т. п.).
- Модель консистентности: кто «истина» и как предотвращаются/обрабатываются конфликты.
- Эксплуатация: установка, обновления, логи, мониторинг, восстановление после инцидентов.
Грубая, но полезная формула такая: rsync — «копировать быстро и экономно», rclone — «копировать в/из объектных и облачных бэкендов», syncthing — «синхронизировать между узлами как сервис», unison — «двусторонняя синхронизация на основе состояния».
Короткий портрет каждого инструмента
rsync: стандарт де-факто для репликации по SSH
rsync хорош там, где у вас есть чёткий источник истины (source of truth) и нужно быстро держать копию на другом узле. Сила rsync — алгоритм дельт, зрелость, работа поверх SSH и простая интеграция в cron/systemd timers/CI.
Но rsync не решает конфликты как класс: можно запускать в обе стороны, но при одновременных правках «кто последний записал — тот и прав». В production это означает: либо вы проектируете однозначный поток изменений, либо сознательно берёте риск на себя.
rclone: швейцарский нож для S3/WebDAV и «облаков»
rclone — инструмент для копирования/синхронизации между локальной ФС и удалёнными бэкендами: S3-совместимые хранилища, WebDAV, SFTP и многое другое. Он часто заменяет самописные пайплайны для выгрузки бэкапов и медиа.
Важно: rclone «думает» в терминах объектов и списков, а не POSIX-атрибутов. Это плюс в мире S3, но ограничение, если вы пытаетесь сделать «полный слепок» файловой системы с владельцами/ACL/xattrs.
Syncthing: автономная синхронизация как сервис
syncthing — демон, который постоянно следит за директориями и синхронизирует их между устройствами. Он удобен для распределённых команд, edge-узлов, «надо чтобы само разъехалось», а связь может быть нестабильной или узлы часто офлайн.
Цена удобства — необходимость думать про модель конфликтов, версионирование, исключения, права и состояние сервиса (база/индексы, очередь событий, место на диске).
Unison: двусторонняя синхронизация с базой состояния
unison — инструмент для двусторонней синхронизации. Он хранит информацию о предыдущем состоянии и на этой базе понимает, что изменилось на обеих сторонах. Поэтому unison обычно честнее подходит для сценария «два узла редактируют файлы», чем попытки «закрутить» rsync в обе стороны.
Ограничение: unison чувствителен к совпадению версий (а иногда и сборок), поэтому в эксплуатации важнее дисциплина обновлений и тесты совместимости.
Сравнение по критериям, которые важны в production
1) Односторонняя реплика (mirror) и «правда» данных
Если вы точно знаете, где источник истины (деплойные артефакты, выгрузка медиа с одного узла, реплика каталога, «сборка → сервер»), проще жить в одностороннем мире.
- rsync — лучший выбор для mirror «сервер → сервер» по SSH, когда важны права/времена и хочется минимального сетевого трафика.
- rclone — лучший выбор для mirror «локально → объектное хранилище» или «объектное → локально».
- syncthing — можно в режиме «Send Only / Receive Only», но это уже сервис со своим жизненным циклом.
- unison — может работать односторонне, но его сильная сторона именно bidirectional.
Практический вывод: для классической file replication «источник → реплика» почти всегда выигрывают rsync или rclone (в зависимости от того, SSH это или S3/WebDAV).
2) Двусторонняя синхронизация и конфликты
Когда изменения возможны с обеих сторон, главный вопрос один: «что происходит при конфликте».
- unison выявляет конфликтные ситуации, когда один и тот же файл менялся с обеих сторон, и требует решения (интерактивно или правилами).
- syncthing делает conflict copies и может вести версионирование (в зависимости от настроек). Это хорошо, если конфликты редки и важнее «не потерять».
- rsync конфликты не решает. Для bidirectional это опасно без строгих правил владения и блокировок.
- rclone в основном про sync/copy между «ремоутами». Двусторонние сценарии возможны, но требуют особой осторожности.
Если у вас «два автора правят один и тот же файл», проблема обычно не в инструменте синхронизации, а в модели владения и предотвращении гонок. Unison и syncthing помогают не потерять изменения, но не заменяют процесс.
Если вам всё-таки нужен двусторонний режим в rclone, используйте отдельные безопасные практики и внимательно тестируйте на копии данных. Полезный разбор рисков и защитных мер: как безопаснее применять rclone bisync.
3) Производительность: миллионы мелких файлов и большие объекты
В production обычно болит одно из двух: либо «миллионы мелких файлов», либо «большие файлы, но их немного».
- rsync хорош на больших деревьях, но сканирование и построение списка файлов тоже стоит времени. Сильно помогают исключения и правильная структура каталогов.
- rclone часто упирается в листинги и лимиты API удалённого хранилища. Он хорош для больших объектов и параллелизма, но проверка «всего и сразу» может быть дорогой.
- syncthing удобен в постоянном режиме: он не обязан каждый раз «пересканировать весь мир» как при ручных запусках. Но первая индексация и поддержание базы — это тоже нагрузка.
- unison обычно адекватен на «рабочих» деревьях, но не лучший вариант для гигантских складов бинарей. Его сила — корректная двусторонняя логика.
4) Атрибуты, права доступа, ACL, xattrs
Тут прячутся самые неприятные сюрпризы «после синка всё сломалось».
- rsync традиционно сильнее, если вам важны POSIX-атрибуты. Но перенос владельца между разными системами может быть нежелателен — опции выбирайте осознанно.
- rclone на объектных хранилищах не может быть «POSIX-идеальным» по определению: там объектная модель и метаданные, а не полноценная ФС.
- syncthing умеет синхронизировать права в рамках настроек, но это не всегда 1:1 то, что вы ожидаете от rsync. Нужны тесты на ваших типах данных.
- unison может синхронизировать права/времена, но практическая совместимость зависит от платформ и конфигурации.
5) Безопасность: транспорт, шифрование, ключи
Базовый минимум для production: шифрование в пути, минимальные привилегии, управляемые ключи, аудит.
- rsync обычно гоняют поверх SSH: понятно, прозрачно, можно ограничить ключ на уровне
authorized_keysи прав на сервере. - rclone зависит от бэкенда: для S3 важны ключи доступа и политика минимальных прав. Плюс есть клиентское шифрование (crypt), если нужно хранить данные в зашифрованном виде на стороне хранилища.
- syncthing шифрует соединения и опирается на идентичности устройств. Операционно важно контролировать список доверенных устройств и хранение конфигурации демона.
- unison часто используют поверх SSH, поэтому модель безопасности похожа на rsync.
Если вы планируете хранить данные в объектном хранилище в зашифрованном виде, пригодится отдельный разбор практики ключей и режима crypt: rclone crypt и ключи для S3. А для внешних веб-сервисов и админок не забывайте про SSL-сертификаты — это снижает риски перехвата и упрощает соответствие базовым требованиям безопасности.
6) Наблюдаемость и эксплуатация
«Работает на тесте» и «работает годами» — разные вещи. Для репликации файлов важны: понятные логи, коды возврата, dry-run, воспроизводимость и восстановление после сбоя.
- rsync: предсказуем, удобен для cron/systemd timers, легко логировать и анализировать.
- rclone: богатые режимы логирования и проверки, но нужно учитывать цену операций в удалённом API и выбирать режим сравнения аккуратно.
- syncthing: это сервис со своим состоянием. Удобно для «постоянного синка», но требует мониторинга сервиса и ресурсов (диск/индексы/очередь).
- unison: обычно задача по расписанию или ручной запуск; важно контролировать совместимость версий и хранение архивов состояния.
Типовые сценарии и что выбирать
Сценарий A: деплой статики/артефактов «CI → сервер»
Нужен односторонний поток, быстрый инкремент и минимум магии.
- Выбор по умолчанию: rsync.
- Когда rclone: если артефакты лежат в S3-совместимом хранилище, а сервер подтягивает их оттуда.
- Когда не стоит syncthing/unison: если вы не хотите держать постоянный сервис синхронизации и разруливать последствия ручных правок на сервере.
Сценарий B: резервная копия/реплика в объектное хранилище
Если цель — «складировать версии/бэкапы/выгрузки» в S3, естественный инструмент — rclone: он понимает семантику объектов и типовые ограничения API.
- Выбор по умолчанию: rclone.
- rsync уместен, если у вас есть промежуточный backup-host по SSH, а уже он льёт в объектное хранилище.
Сценарий C: синхронизация проектов между ноутбуком и сервером
Здесь чаще всего нужна «две стороны» и устойчивость к офлайну.
- Выбор по умолчанию: syncthing (когда хочется «чтобы само» и устройств больше двух).
- Альтернатива: unison (когда важнее контролируемая двусторонняя логика и вы готовы запускать синк по расписанию/вручную).
- Осторожно с rsync: без строгих правил легко перетереть изменения.
Сценарий D: двусторонняя репликация конфигов между двумя серверами
На практике это редко хорошая идея: конфиги в production обычно живут в Git и раскатываются декларативно. Но если по условиям задачи нужна именно двусторонняя синхронизация файлов между двумя узлами:
- Выбор: unison (как более честный bidirectional sync) или syncthing с дисциплиной папок и версионированием.
- rsync — только если вы назначили один узел источником истины.
Сценарий E: «горячее» распространение файлов на много edge-узлов
Если нужно быстро размножать данные на много узлов, часто практичнее схема «объектное хранилище + pull» (узлы сами забирают нужное). Для этого обычно нужен предсказуемый сервер/среда, где удобно держать задачи и ключи — например, VDS.
- rsync хорош для push на фиксированный набор узлов (скриптом/оркестрацией), когда изменения односторонние.
- syncthing может быть удобен как «распределитель», но внимательно смотрите на масштабирование, контроль доступа и поведение при разрывах.
Практические подводные камни (и как не наступить)
Удаления и «идеальное зеркало»
Самый частый инцидент в file replication — когда включили удаление «как на источнике», а источник внезапно оказался пустым: ошибка монтирования, сбой диска, неверный путь. Дальше инструмент честно делает «идеальное зеркало» и удаляет всё на приёмнике.
Правило для production: перед режимами зеркалирования ставьте защиту от пустых/не тех путей, используйте dry-run, и продумывайте ретеншн (снимки, версии, корзина).
Частично записанные файлы
Если приложение пишет файл «в лоб» (без временного имени и атомарного rename), синхронизатор может забрать полузаписанный файл. Для продовых сценариев лучше обеспечить атомарную запись на стороне приложения (временный файл → rename), либо использовать staging-каталог и публиковать готовые файлы отдельно.
Симлинки, сокеты, device-файлы
Синхронизация «всего подряд» из системных директорий часто приводит к сюрпризам. Реплицируйте только то, что действительно является данными/артефактами, а не runtime-сущностями.
Не путайте синхронизацию и бэкап
Синхронизация поддерживает актуальную копию. Бэкап — это ещё и возможность откатиться «вчера/неделю назад». Для production обычно нужны оба слоя: реплика (быстро восстановиться) и отдельная стратегия бэкапов с версиями.
Мини-таблица выбора (без фанатизма)
- Нужно быстро и просто зеркалировать по SSH → rsync.
- Нужно синкать в S3/WebDAV/облако → rclone.
- Нужно, чтобы директории синхронизировались постоянно и между многими узлами → syncthing.
- Нужна двусторонняя синхронизация двух деревьев с контролем конфликтов → unison.
Рекомендации для production-архитектуры
Если цель — снизить риск и упростить поддержку, держите в голове несколько принципов.
- Назначайте источник истины для критичных данных и избегайте двусторонней синхронизации там, где это не необходимо.
- Разделяйте данные по классам: артефакты деплоя, пользовательские загрузки, бэкапы, конфиги — часто требуют разных инструментов и разных гарантий.
- Делайте проверки и репетиции восстановления: репликация бессмысленна, если вы не проверяли, что из неё реально можно восстановиться.
- Ставьте наблюдаемость: логи задач, алерты по ошибкам синка, контроль свободного места, контроль количества объектов/файлов.
Итог простой: спор «rsync vs rclone vs syncthing vs unison» сводится к тому, где вы хотите держать сложность — в одностороннем потоке (rsync), в объектной модели и API (rclone), в постоянно работающем сервисе (syncthing) или в двусторонней логике с базой состояния (unison). Правильный выбор — тот, который делает поведение системы предсказуемым именно в вашем production-сценарии.
