Відповіді:
Багато, але я наведу кілька з верхівки голови.
Що робити, якщо 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, мої проблеми пішли.
Клієнту не потрібно знати компонування файлової системи тощо на сервері, на який він / вона натискає / тягне до / з
rsyncSSH?
Загальне використання для rsync - це дзеркальне відображення архівів загальнодоступних файлів. Оператор первинної копії не хоче дозволити віддалений доступ до оболонки до архіву, але хоче, щоб волонтери, які працюють на віддалених дзеркалах, змогли ефективно отримати повну копію архівів. Rsync працює надзвичайно добре для створення дзеркала, оскільки він завантажуватиме лише змінені біти, і якщо буде невелика перерва в мережі, він не завантажить повторно весь великий файл (зображення CD / DVD).
Протокол бітових торрентів насправді може бути кращим вибором для цього, але rsync був випущений на багато років раніше.
Навіть зараз багато великих архівів досі використовують rsync для дзеркал.
Дивіться: http://www.debian.org/mirror/ftpmirror
Протокол дзеркального відображення, який ми рекомендуємо, є rsync.
Ви можете надати rsync-послуги екстранету і дозволяти синхронізувати таким чином, не піддаючи ssh.
У демонстраційному режимі rsync швидше розраховуватиме місцеві контрольні суми і, таким чином, краще підходить, якщо ви очікуєте декількох паралельних клієнтів. За допомогою автономних команд контрольні суми потрібно перерахувати для кожного сеансу.
SSH надає накладні витрати за рахунок, наприклад, використання шифрування. Тож теоретично вам слід отримати більшу пропускну здатність за допомогою демон-сервера rsync.