Гайд по выбору 2026rsyncopenrsyncУдалённая синхронизация сборок Mac

2026 Mac rsync vs openrsync / Гайд по удалённой синхронизации сборок

В macOS Sequoia системный rsync заменён на openrsync — для команд, которые используют rsync для удалённой синхронизации сборок и доставки артефактов CI, это заметно сказывается. В этом материале: отличия между ними, когда брать rsync из Homebrew или Docker, как диагностировать ENOSPC/ECONNREFUSED и чек-лист выбора по размеру команды и версии ОС; в конце — почему хостинг с SFTP на удалённом Mac часто стабильнее и проще в управлении.

rsyncopenrsyncmacOS SequoiaУдалённый MacСинхронизация сборокSFTP
1. Почему в macOS Sequoia используют openrsync и что это значит для удалённой синхронизации сборок2. Сравнение возможностей rsync и openrsync3. Рекомендуемые схемы синхронизации артефактов сборки на удалённом Mac4. Частые сбои синхронизации: диагностика и решение5. Чек-лист выбора и CTA
rsync и openrsync на Mac для удалённой синхронизации сборок — выбор и устранение неполадок

Почему в macOS Sequoia используют openrsync и что это значит для удалённой синхронизации сборок

Apple заменила в macOS Sequoia прежний rsync на openrsync; причины связаны в основном с политикой лицензии GPLv3. Поставляемый с системой rsync 2.6.9 устарел, а rsync 3.x под GPLv3 — Apple выбрала openrsync с лицензией BSD, чтобы избежать ограничений распространения. Для разработчиков openrsync легче и быстрее, но в режиме удалённого демона (rsync daemon), ACL и части синхронизации прав ведёт себя иначе, чем rsync 3.x. Если ваш пайплайн от этого зависит, нужно заранее решить: продолжать использовать rsync 3.x через Homebrew или принять ограничения openrsync и поправить скрипты.

Для удалённой синхронизации сборок важны три вещи: совместимость инкрементной проверки и delta-передачи, степень сохранения прав и меток времени на стороне назначения, совместимость с существующими командами rsync в CI (GitHub Actions, Jenkins и т.д.). Для сценария «только синхронизация локально → каталог на удалённой машине» openrsync часто достаточно; как только нужны режим демона, сложные ACL или синхронизация между несколькими узлами, лучше оставаться на полном rsync.

Сравнение rsync и openrsync: права, ACL, удалённый демон

Таблица возможностей, важных для удалённой синхронизации сборок — системный openrsync и rsync 3.x из Homebrew.

ВозможностьСистемный openrsync (Sequoia)Homebrew rsync 3.xВлияние на синхронизацию сборок
Инкремент / deltaдадаОба поддерживают инкрементную синхронизацию, разница небольшая
Удалённый демонограничен или иначеполная поддержкаЕсли CI забирает артефакты по rsync:// — лучше rsync из Homebrew
ACL / расширенные атрибутычастичнополная поддержкаДля строгого сохранения прав — rsync 3.x
--fake-superв планах (дорожная карта openrsync)даНужно, если без root требуется сохранять полные права
Обслуживание / обновлениевместе с ОСbrew upgrade rsyncВ долгосрочной перспективе гибче с Homebrew

Итог: если делаете только инкрементный push «локально/CI → каталог на удалённом Mac» без демона и сложных ACL, можно сначала попробовать системный openrsync. Иначе на узлах сборки единообразно ставьте brew install rsync и явно используйте /opt/homebrew/opt/rsync/bin/rsync или настройте PATH так, чтобы не смешивать с системным openrsync.

Рекомендуемые схемы: rsync Homebrew / rsync в Docker / SFTP

Три распространённых подхода и когда они уместны.

  1. rsync Homebrew: На удалённом Mac выполнить brew install rsync, CI или локальная машина вызывают этот rsync по SSH. Подходит, если доступ по SSH уже стандартизирован и нужна полная функциональность rsync. Следите, чтобы в PATH использовалась версия из Homebrew, а не системный openrsync.
  2. rsync в Docker: Запускать rsync 3.x в контейнере на удалённом Mac — версия и поведение фиксированы. Удобно в смешанной среде с несколькими узлами и ОС, но добавляет поддержку образов и сети.
  3. Шлюз SFTP + изоляция каталогов: Без демона rsync загружать и скачивать артефакты сборки по SFTP с чёткими правами на каталоги и аудитом. Подходит, когда важнее границы прав, аудит и доставка с разными ролями; при необходимости инкрементную синхронизацию можно добавить в «разрешённых» каталогах через rsync over SSH поверх SFTP.

На практике многие команды комбинируют: SFTP для доступа и прав, rsync для крупных инкрементных синхронизаций — SFTP гарантирует, что только авторизованные учётные записи получают доступ к заданным каталогам, rsync внутри них обеспечивает эффективную инкрементную передачу.

ENOSPC, ECONNREFUSED и другие частые сбои синхронизации

Пять шагов для диагностики и исправления.

# 1. Проверить, какой rsync используется (избежать смешивания с openrsync)
which rsync
/opt/homebrew/bin/rsync --version

# 2. Проверить SSH и место на диске назначения (избежать ENOSPC)
ssh user@remote-mac "df -h /path/to/dest"
ssh user@remote-mac "df -i /path/to/dest"   # исчерпаны ли inode

# 3. Проверить, слушает ли назначение (избежать ECONNREFUSED)
# При демоне rsync: netstat -an | grep 873
# При rsync over SSH: sshd запущен, файрвол разрешает 22

# 4. Пробный прогон — что будет передано
rsync -avzn --delete ./build/ user@remote-mac:/path/to/dest/

# 5. Реальный запуск с логом
rsync -avz --delete ./build/ user@remote-mac:/path/to/dest/ 2>&1 | tee rsync.log

ENOSPC: диск или inode на стороне назначения переполнены — очистите цель, архивируйте старые артефакты или увеличьте объём; при необходимости добавьте в CI шаг «проверить место на диске перед синхронизацией».
ECONNREFUSED: удалённая служба не слушает или блокируется файрволом — при SSH проверьте sshd и порт 22; при демоне rsync — порт 873 и rsyncd.conf.
Permission denied / права: владелец каталога назначения должен совпадать с пользователем SSH; при использовании ACL/--fake-super для полного сохранения прав предпочтительнее rsync из Homebrew и его документация.

Чек-лист выбора: rsync/openrsync или SFTP-хостинг по команде и ОС

  • Одна машина / один узел, хватает openrsync из Sequoia: используйте системный rsync, в скриптах не полагайтесь на демон и сложные ACL.
  • CI с несколькими узлами, нужен демон или строгие права: установите rsync из Homebrew на всех узлах и используйте его путь единообразно.
  • Важнее границы прав, аудит и доставка с разными ролями: внедрите шлюз SFTP и изоляцию каталогов, при необходимости rsync over SSH в разрешённых каталогах.
  • Хотите меньше зависеть от одной машины и версии rsync: рассмотрите передачу хостинга артефактов сборки провайдеру удалённого Mac с SFTP — он обеспечивает доступность и политику прав, локально/в CI остаётся только загрузка, выгрузка и проверка.

rsync и openrsync покрывают большинство сценариев «инкрементная синхронизация на уровне каталога»; на практике важны единая версия, согласованный путь и быстрая диагностика при сбоях. Когда команда растёт и растут требования по соответствию и аудиту, одного rsync часто недостаточно — нужен явный слой доступа (например SFTP) и стабильная удалённая среда.

Почему в macOS Sequoia системный rsync заменили на openrsync?

Из-за несовместимости лицензии GPLv3 с политикой Apple компания заменила прежний rsync на openrsync (лицензия BSD) в macOS Sequoia. openrsync легче и быстрее, но ведёт себя иначе, чем rsync 3.x, в режиме удалённого демона, ACL и части синхронизации прав — при удалённой синхронизации сборок это нужно учитывать.

Rsync или SFTP для синхронизации артефактов сборки на удалённом Mac?

Если команда уже единообразно использует rsync и нужны инкремент и контрольные суммы, можно продолжать использовать rsync 3.x через Homebrew. Если важнее границы прав, аудит и доставка с разными ролями, шлюз SFTP с изоляцией каталогов часто проще в эксплуатации. Оба варианта можно совмещать: SFTP для доступа и прав, rsync для крупных инкрементных синхронизаций.

При синхронизации ENOSPC или ECONNREFUSED — как диагностировать?

ENOSPC означает переполнение диска или inode на стороне назначения — очистите цель или увеличьте объём. ECONNREFUSED означает, что удалённая служба не слушает или блокируется файрволом — проверьте sshd, демон rsync или порт SFTP, а также сеть и файрвол между локальной машиной и удалённым Mac.

Поддержка версий rsync/openrsync и отладка сети и диска на своих Mac или узлах CI отнимают время. Если вы предпочитаете сосредоточиться на доставке продукта, можно передать синхронизацию артефактов сборки и управление правами хостингу удалённого Mac: SFTPMAC предоставляет стабильный SFTP и изоляцию каталогов, совместим с инкрементной синхронизацией rsync over SSH — мы обеспечиваем доступность и политику прав, вы сосредотачиваетесь на сборке и релизе.