Ответы:
Многие, но я буду приводить несколько из верхней части моей головы.
Что если ssh / rsh недоступны на удаленном сервере или если они нарушены с точки зрения конфигурации или более строгих сетевых правил? Использование rsh / ssh все равно потребует клиента (зависит от роли отправителя или получателя), однако удаленная сторона должна будет локально разветвить двоичный файл rsync и установить соединение с процессом rsync, работающим на локальной стороне. rsh / ssh просто предоставил бы туннель соединения; Что касается rsync, то rsync связывается с другим процессом rsync по каналу (-ам).
Наличие процесса rsync в режиме демона сделает сервер действительно похожим на ftp-сервером, где некоторые файловые системы могут быть доступны через модули rsync. Всего остального можно избежать. Скажем, я хочу сделать доступными только / usr / local и / var для загрузки и отклонить запрос любого клиента rsync на другие загрузки. Я могу использовать конфиденциальность на уровне хоста или на уровне файловой системы (модулей), чтобы разрешить либо загрузку, либо загрузку (только чтение).
Может управлять модулями доступа на уровне хоста / пользователя, аутентификации, авторизации, регистрации и файловой системы (структуры) для загрузки / выгрузки, в частности, через файл конфигурации. Каждый раз, когда вносятся изменения в файл конфигурации, rsyncd --daemonнет необходимости перезапускать или HUPped. Может также контролировать количество клиентов, которые могут одновременно подключаться к процессу сервера rsync. Это хорошо, так как я не хочу, чтобы процесс моего сервера rsyncd полностью загружал хост из-за операций ввода-вывода на базе процессора или диска.
Функцию chroot можно сделать доступной через конфигурацию для rsyncd в режиме демона. Я могу использовать это как довольно аккуратную функцию безопасности, если я хочу избежать подключения клиентов к моему rsyncd для любой из файлов / файловых систем, которые должны быть защищены на хосте и не должны иметь внешнего доступа.
Я могу прямо отрицать некоторые опции, используемые клиентом rsync, и не развлекать их на стороне сервера, например, не разрешать эту --deleteопцию.
Может иметь возможность запускать некоторые команды / сценарии до и после процесса rsync. Примером может служить сообщение и сохранение статистики rsync в режиме после передачи.
Вот некоторые из них, но я уверен, что опытные пользователи rsync могут пролить больше света на это.
У меня возникла проблема при попытке синхронизировать большую папку между машиной linux и машиной Windows с помощью cygwin. После отказа от SSH-туннеля в пользу использования демона rsync мои проблемы исчезли.
Клиенту не нужно знать структуру файловой системы и т. Д. Сервера, который он / она перемещает / извлекает из / в
rsyncиспользовании SSH?
Обычно rsync используется для зеркалирования публичных архивов файлов. Оператор основной копии не хочет разрешать удаленный доступ оболочки к архиву, но хочет, чтобы добровольцы, работающие с удаленными зеркалами, могли эффективно получить полную копию архивов. Rsync очень хорошо работает для создания зеркала, так как он загружает только измененные биты, и если в сети есть небольшое прерывание, он не будет повторно загружать весь большой файл (образы CD / DVD).
Протокол Bit Torrent на самом деле может быть лучшим выбором для этого сейчас, но rsync был выпущен много лет назад.
Даже сейчас многие крупные архивы все еще используют rsync для зеркал.
Смотрите: http://www.debian.org/mirror/ftpmirror
Протокол зеркалирования, который мы рекомендуем, это rsync.
Вы можете предоставлять rsync-сервисы для экстрасети и разрешать синхронизацию таким образом, не выставляя ssh.
В режиме демона rsync, вероятно, будет быстрее вычислять локальные контрольные суммы и, следовательно, лучше подходит, если вы ожидаете нескольких параллельных клиентов. С помощью автономной команды контрольные суммы необходимо пересчитывать для каждого сеанса.
SSH дает издержки, например, из-за использования шифрования. Таким образом, теоретически вы должны повысить пропускную способность с помощью демона rsync-сервера.