rsync

7 июня 2026 · ~11 мин чтения

rsync

Утилита для синхронизации файлов и каталогов между двумя машинами (или двумя путями на одной машине), которая передаёт только отличающиеся части файлов, а не файлы целиком.

История

В 1996 году аспирант Эндрю Триджелл (Andrew Tridgell) из Австралийского национального университета опубликовал программу rsync вместе со статьёй, описывающей лежащий в её основе алгоритм. Триджелл известен широкой аудитории ещё и как создатель Samba (реализация SMB-протокола для Linux). Сооавтором алгоритма выступил Пол Маккеррас (Paul Mackerras).

Поводом стала скучная, но реальная проблема: как обновить файл на удалённом сервере, когда файл большой, а канал — медленный и дорогой? Загружать файл целиком дорого. Как передать только изменения, даже если у удалённой стороны нет исходника?

Триджелл решил эту задачу, придумав rolling checksum (скользящая контрольная сумма) — алгоритм, который позволяет стороне-получателю вычислить, какие блоки файла у неё уже есть, и передать эту информацию отправителю в виде компактного «отпечатка». Отправитель использует отпечаток, чтобы найти совпадающие блоки и передать только новое.

Несколько вех:
- 1996 — первый выпуск, версия 0.1. Лицензия GPL.
- 2002 — версия 2.5.6 стала де-факто стандартом; именно её большинство Unix-систем включили в базовые пакеты.
- 2007 — разработка перешла в статус «живой, но без крупных новшеств»; rsync долго был в режиме maintenance.
- 2020 — выход версии 3.2.0 с улучшенной поддержкой Unicode и исправлением ряда уязвимостей. Сейчас актуальна ветка 3.3.x.

Утилита по-прежнему развивается как открытый проект. Репозиторий — на samba.org и зеркале GitHub.

Что это такое

rsync — это и утилита командной строки, и протокол. С точки зрения пользователя это программа с синтаксисом, похожим на cp или scp. С точки зрения инженера это реализация алгоритма дельта-кодирования (delta encoding) поверх SSH (или собственного rsync-демона).

Ключевые свойства, которые отличают rsync от конкурентов:

Только дельта. rsync не копирует файл заново, если он уже есть на другой стороне и не изменился. Это ускоряет повторные синхронизации в десятки раз.

Инкрементальная передача внутри файла. Если изменилась середина большого файла, rsync отправит только изменившийся блок. Это принципиально отличает его от scp, который всегда переносит файл целиком.

Атомарность на уровне файла. Файл либо скопирован целиком, либо нет. Частично скопированный файл под временным именем, финальное переименование — только после завершения.

Фильтры и правила. Можно тонко управлять тем, что именно синхронизируется: исключить node_modules/, включить только *.log, зеркалировать структуру с сохранением прав доступа и временных меток.

Без специального ПО на приёмнике. Если rsync работает через SSH, на принимающей стороне нужен только rsync и ssh-демон. Никаких дополнительных агентов.

Сравнение с похожими инструментами:

rsync не предназначен для двустороннего слияния (если оба конца изменили файл — rsync не поможет разрулить конфликт, он просто перепишет). Для этого нужен Unison или git.

Аналогии из жизни

Почта и контрольная опись. Представь: ты регулярно шлёшь другу посылки с книгами. В первый раз везёшь всё. Потом перед каждой отправкой сверяешь список — «у тебя уже есть Толстой, Достоевский, нет только Чехова» — и кладёшь в посылку только Чехова.

Где работает: именно так rsync работает при регулярном деплое. Если 95% файлов не изменились, передаётся только 5%.

Где ломается: опись занимает время. Если файлов миллион и нужно проверить каждый — сравнение займёт больше, чем сама передача. Поэтому для очень большого количества мелких файлов rsync работает медленнее, чем tar + scp одним архивом.

Подзорная труба и переписка в море. Два корабля хотят обменяться картами. Первый показывает через трубу «квадраты», которые у него есть, второй отвечает: «такие квадраты у меня тоже есть, пришли только вот эти». Передаётся минимум.

Где работает: именно так работает rolling-checksum алгоритм — приёмник вычисляет «отпечатки» своих блоков и сообщает отправителю, что уже есть.

Где ломается: если у приёмника ничего нет (первый деплой), оба корабля вынуждены передать всё — и расчёт отпечатков оказывается лишней работой. Впрочем, rsync обрабатывает это корректно, просто первый запуск всегда дольше повторных.

Маляр и прораб. Прораб говорит маляру: «В квартире уже покрашены кухня и ванная, нужно только докрасить коридор и комнату». Маляр не красит заново всё подряд.

Где работает: флаг --delete в rsync удаляет с приёмника файлы, которые исчезли у отправителя — как маляр, который замазывает лишнее по команде.

Где ломается: маляр может ошибиться и замазать что-то нужное. Флаг --delete без осторожности удаляет данные навсегда — если источник потерял файлы (например, локальный диск умер), следующий rsync снесёт их и с сервера. Всегда делай бэкап перед --delete.

Как это работает

Упрощённо процесс синхронизации двух каталогов выглядит так:

Шаг 1. Построение списка. rsync на обеих сторонах строит список файлов — имена, размеры, временные метки, права доступа.

Шаг 2. Сравнение. По умолчанию rsync сравнивает размер и время последней модификации. Если совпадают — файл считается идентичным, пропускается. Флаг --checksum заставляет считать MD4/MD5 хэши, это точнее, но медленнее.

Шаг 3. Для изменившихся файлов — алгоритм rolling checksum. Приёмник делит свою версию файла на блоки по ~700 байт и для каждого блока вычисляет две контрольные суммы: быструю (Adler-32 / rolling) и точную (MD4). Эти «отпечатки» передаются отправителю.

Шаг 4. Поиск совпадений у отправителя. Отправитель «скользит» окном по своей версии файла. На каждом байте вычисляет rolling-сумму — это быстро. Если нашёл совпадение с каким-то блоком приёмника, проверяет MD4. Если совпало — блок у приёмника уже есть, можно не передавать. Так он находит, что изменилось.

Шаг 5. Передача дельты. Отправитель пересылает только: инструкции «возьми блок №N из своего файла» (для неизменившихся блоков) и сырые байты (для новых данных). Приёмник собирает новый файл из своих блоков и полученных байт.

Шаг 6. Финальное переименование. Новый файл записывается под временным именем, затем атомарно переименовывается в нужное. Незавершённая передача не оставит сломанного файла.

Типичная команда деплоя:

rsync -avz --delete \
  -e "ssh -i ~/.ssh/id_ed25519" \
  ./built/ \
  user@server:/var/www/blog/

Флаги:
- -a (archive) — рекурсивно, сохраняя права, симлинки, временные метки
- -v (verbose) — показать что передаётся
- -z (compress) — сжать данные при передаче
- --delete — удалить с сервера файлы, которых нет в источнике
- -e — задать команду для соединения (здесь SSH с конкретным ключом)

Важный момент: слеш в конце ./built/ значит «содержимое каталога». Без слеша (./built) — скопируется сам каталог built внутрь /var/www/blog/built/. Это частая ошибка новичков.

Где встречается в обычной жизни

Синхронизация фотографий. Приложения типа Synology Drive или Resilio Sync используют алгоритмы, похожие на rsync, чтобы синхронизировать фотоальбом между телефоном и NAS (сетевым хранилищем). Когда добавляешь 3 новых фото в альбом из 10 000 — приложение не закачивает все 10 000 снова.

Бэкапы в облаке. Time Machine на Mac, Backblaze, Arq Backup — все используют принцип инкрементального бэкапа. Первый бэкап большой, остальные — только «дельта». Это и есть идея rsync.

Обновление сайтов. Когда ты меняешь CSS-файл на своём сайте и деплоишь — в большинстве простых хостингов под капотом работает rsync или аналог. Только изменённый файл уходит на сервер.

CDN-распределение. Большие CDN (Cloudflare, Fastly) синхронизируют контент между точками присутствия по всему миру похожим образом — передают только то, что изменилось с последней синхронизации.

Зеркала Linux-дистрибутивов. Когда ты обновляешь Ubuntu через apt, пакеты приходят с зеркала — сервера, который синхронизирует репозиторий с мастером именно через rsync (или rrsync — его ограниченную версию).

Где встречается в IT и бизнесе

Деплой статических сайтов. Классическая связка: генератор статики (Hugo, Jekyll, Next.js в static-режиме) собирает HTML в папку built/, rsync синхронизирует её с веб-сервером. Быстро, надёжно, без лишних зависимостей.

Резервное копирование серверов. rsync + SSH + cron — простейший и надёжный рецепт бэкапа. Многие небольшие компании делают именно так. Скрипт запускается ночью, копирует /etc, /var/www, базу данных (предварительно дампленную в файл).

Инструмент CI/CD. В простых пайплайнах rsync заменяет сложные деплой-системы: GitHub Actions собрал → rsync отправил → готово. Это намного проще, чем Kubernetes, и для большинства небольших проектов этого хватает.

Зеркалирование репозиториев. Организации зеркалируют через rsync внешние пакетные репозитории внутрь корпоративной сети, чтобы разработчики не зависели от внешнего интернета.

Синхронизация между дата-центрами. Небольшие команды DevOps синхронизируют конфиги и медиафайлы между двумя серверами через rsync с флагом --checksum. Это дешевле, чем полноценная система репликации.

Кто пользуется

• Kernel.org — rsync-зеркала для исходников Linux-ядра. Тысячи серверов синхронизируют репозиторий через rsync-демон.
• Debian, Ubuntu, Fedora — официальные зеркала пакетов распространяются через rsync. Сеть зеркал Debian насчитывает более 300 серверов по всему миру.
• Wikimedia Foundation — синхронизация данных между дата-центрами (Ashburn, Amsterdam, Carrollton).
• Любая команда с VPS-деплоем — статистики нет, но по данным репозитория Homebrew rsync стабильно входит в топ-100 самых устанавливаемых пакетов.
• BackupPC — популярная open-source система бэкапа, использует rsync под капотом для снятия инкрементальных копий.

Цифры: типичный деплой статики (100 файлов, 5 МБ) через rsync занимает 1–3 секунды на второй и последующий запуск при изменении 1–2 файлов. Тот же деплой через scp — 5–15 секунд независимо от числа изменений.

Альтернативы и конкуренты

scp (Secure Copy)
- Плюсы: простой синтаксис, встроен в OpenSSH, нет зависимостей.
- Минусы: всегда копирует файлы целиком, нет дельта-передачи, медленнее на повторных запусках, нет фильтров.

rclone
- Плюсы: работает с облачными хранилищами (S3, Google Drive, Backblaze, 40+ провайдеров), дельта через checksums, двустороннее зеркало.
- Минусы: медленнее rsync для чисто файловых задач, требует конфигурации под каждый провайдер.

Unison
- Плюсы: двустороннее зеркало с обнаружением конфликтов, GUI, кроссплатформенный.
- Минусы: медленнее rsync, нужен на обоих концах, меньше распространён, сложнее в настройке.

rsnapshot
- Плюсы: инкрементальные бэкапы с хранением N версий через hard links, минимум дискового места.
- Минусы: только для бэкапов, не для деплоя, сложнее в настройке.

Когда НЕ стоит использовать

Когда нужна двусторонняя синхронизация. rsync зеркалирует от источника к приёмнику. Если ты изменил файл на сервере, а потом запустил rsync с локальной машины — сервер получит старую версию, а не наоборот. Для двусторонней синхронизации нужен Unison или git.

Когда деплой — это не просто файлы. Если твой деплой требует «перезапустить сервис», «применить миграции базы данных», «сбросить кэш» — rsync сам по себе не поможет. Это оркестрирует или CI/CD система (GitHub Actions, GitLab CI), или Ansible, или Capistrano. rsync может быть одним из шагов, но не заменяет оркестратор.

Когда файлов миллионы и они мелкие. rsync перечисляет каждый файл для сравнения. На 10 млн мелких файлов это займёт минуты только на построение списка. В этом случае лучше упаковать в архив и передавать архив целиком, или использовать специализированные системы (Amazon S3 Sync, который тоже вдохновлён rsync, но оптимизирован для object storage).

Связанные понятия

• SSH (Secure Shell) — протокол защищённого удалённого доступа, поверх которого rsync передаёт данные по умолчанию. Без SSH rsync ходил бы в открытом виде.
• delta encoding (дельта-кодирование) — общая концепция передачи только разницы между двумя состояниями; rsync — одна из реализаций.
• rolling checksum (скользящая контрольная сумма) — математический трюк, позволяющий вычислить хэш окна данных за O(1) при сдвиге на один байт; ключевой алгоритм rsync.
• hard links (жёсткие ссылки) — механизм файловой системы, когда два имени указывают на один инод; rsnapshot использует их для хранения N снимков без дублирования неизменившихся файлов.
• idempotency (идемпотентность) — свойство операции давать тот же результат при повторном выполнении; запуск rsync дважды подряд безопасен, второй раз ничего не изменит.
• deamon (демон) — фоновый процесс; rsync может работать в режиме демона (rsyncd), принимая соединения без SSH, например для публичных зеркал.

Литература и источники

1. Tridgell, A. & Mackerras, P. (1996). «The rsync algorithm» — оригинальная техническая статья. Искать: «rsync algorithm 1996 technical report Australian National University».
2. Официальная документация rsync — rsync.samba.org/documentation.html. Там же страница man-page с полным описанием всех флагов.
3. «The Art of Unix Programming», Eric S. Raymond (2003, en) — глава о small tools и Unix philosophy объясняет, почему rsync стал стандартом.
4. Wikipedia (en): «rsync» — подробная статья с историей и описанием алгоритма. Стабильная ссылка: en.wikipedia.org/wiki/Rsync
5. «Ansible for DevOps», Jeff Geerling (2020, en) — практическое использование rsync в деплой-пайплайнах.

Где встретилось у меня

В конфигурации ежедневного блога daily-digest деплой на VPS Fornex устроен ровно через rsync: скрипт deploy.sh синхронизирует папку built/ с /var/www/blog/ на удалённом сервере. В промте стоит явное напоминание не запускать rsync вручную из Claude — только через оркестратор run.sh.

Краткое резюме

• rsync — утилита 1996 года, которая синхронизирует файлы, передавая только отличающиеся блоки (дельта), а не файлы целиком.
• Работает поверх SSH, не требует ничего особенного на приёмнике, идемпотентен.
• Флаг --delete синхронизирует удаления; без бэкапа это опасно.
• Слеш в конце пути критически важен: built/ — содержимое, built — сам каталог.
• Отлично подходит для деплоя статики, бэкапов и зеркал; не подходит для двусторонней синхронизации или деплоя с побочными эффектами.