Мені часто доводиться надсилати папки з 10 К - 100 К файлів на віддалену машину (в межах однієї мережі в кампусі).

Мені було просто цікаво, чи є причини вважати,

 tar + rsync + untar

Або просто

 tar (from src to dest) + untar

на практиці може бути швидше, ніж

rsync 

при першому перенесенні файлів .

Мене цікавить відповідь, яка стосується вищезазначеного у двох сценаріях: використання стиснення та не використання.

Оновлення

Я щойно провів кілька експериментів, переміщаючи 10 000 невеликих файлів (загальний розмір = 50 МБ), і tar+rsync+untarбув стабільно швидшим, ніж rsyncбезпосередньо запуск (обидва без стиснення).

Коли ви надсилаєте один і той же набір файлів, rsyncкраще підходить, оскільки він надсилатиме лише відмінності. tarзавжди надсилатиме все, і це марна трата ресурсів, коли багато даних вже є. При tar + rsync + untarцьому втрачається ця перевага, а також перевага підтримувати синхронізацію папок rsync --delete.

Якщо ви копіюєте файли вперше, спочатку пакуєте, потім відправляєте, а потім розпаковувати (AFAIK rsyncне приймає трубопровідний вхід) є громіздким і завжди гіршим, ніж просто rsyncing, тому що rsyncне доведеться виконувати жодне завдання більше, ніж tarвсе одно.

Порада: rsync версії 3 або пізнішої версії виконує поступову рекурсію, це означає, що вона починає копіювати майже одразу, перш ніж підраховувати всі файли.

Порада 2: Якщо ви використовуєте rsyncбільше ssh, ви можете також використовувати будь-якийtar+ssh

tar -C /src/dir -jcf - ./ | ssh user@server 'tar -C /dest/dir -jxf -'

або просто scp

scp -Cr srcdir user@server:destdir

Загальне правило, нехай це буде просто.

ОНОВЛЕННЯ:

Я створив 59 млн демо-даних

mkdir tmp; cd tmp
for i in {1..5000}; do dd if=/dev/urandom of=file$i count=1 bs=10k; done

і кілька разів перевіряли передачу файлів на віддалений сервер (не в одному ланцюзі), використовуючи обидва способи

time rsync -r  tmp server:tmp2

real    0m11.520s
user    0m0.940s
sys     0m0.472s

time (tar cf demo.tar tmp; rsync demo.tar server: ; ssh server 'tar xf demo.tar; rm demo.tar'; rm demo.tar)

real    0m15.026s
user    0m0.944s
sys     0m0.700s

зберігаючи окремі журнали від відправлених пакетів трафіку ssh

wc -l rsync.log rsync+tar.log 
   36730 rsync.log
   37962 rsync+tar.log
   74692 total

У цьому випадку я не бачу жодної переваги в меншій кількості мережевого трафіку, використовуючи rsync + tar, який очікується, коли mtu за замовчуванням становить 1500, а файли розміром 10 к. rsync + tar отримував більше трафіку, був повільнішим на 2-3 секунди і залишив два файли сміття, які довелося прибрати.

Я робив ті ж тести на двох машинах на одному ланцюзі, і там rsync + tar робив набагато кращі часи та набагато менше мережевого трафіку. Я припускаю, що причини джамбо кадрів.

Можливо, rsync + tar буде кращим, ніж просто rsync у набагато більшому наборі даних. Але, чесно кажучи, я не думаю, що це вартує клопоту, вам потрібно подвійне місце в кожній стороні для упаковки та розпакування, і є кілька інших варіантів, як я вже згадував вище.

rsyncтакож робить стиснення. Використовуйте -zпрапор. Якщо sshви переходите , ви також можете використовувати режим стиснення ssh. Я відчуваю, що повторний рівень стиснення не корисний; це просто спалить цикли без значного результату. Я рекомендую експериментувати зі rsyncстисненням. Це здається досить ефективним. І я б запропонував пропустити використання tarабо будь-яке інше стиснення до / після публікації.

Я зазвичай використовую rsync як rsync -abvz --partial....

Мені довелося сьогодні створити резервну копію домашнього каталогу в NAS і наткнувся на цю дискусію, думав, що я додам свої результати. Коротше кажучи, орієнтування по мережі до цільової файлової системи в моєму середовищі швидше, ніж rsyncing до того самого пункту призначення.

Навколишнє середовище: робочий стіл i7 на робочому столі за допомогою жорсткого диска SSD. Машина призначення Synology NAS DS413j на гігабітному лан-з'єднанні з вихідною машиною.

Точна специфікація цього комплекту вплине на продуктивність, природно, і я не знаю деталей моєї точної настройки щодо якості мережевого обладнання на кожному кінці.

Вихідні файли - це моя папка ~ / .cache, яка містить 1,2 Гб здебільшого дуже малих файлів.

1a/ tar files from source machine over the network to a .tar file on remote machine

$ tar cf /mnt/backup/cache.tar ~/.cache

1b/ untar that tar file on the remote machine itself

$ ssh admin@nas_box
[admin@nas_box] $ tar xf cache.tar

2/ rsync files from source machine over the network to remote machine

$ mkdir /mnt/backup/cachetest
$ rsync -ah .cache /mnt/backup/cachetest

Я дотримувався 1a та 1b як цілком окремі кроки, щоб проілюструвати завдання. Для практичних застосувань я б рекомендував те, що Gilles розміщував вище, що стосується виведення дьогтю по каналу через ssh для нерозбірливого процесу на приймачі.

Терміни:

1a - 33 seconds

1b - 1 minutes 48 seconds

2 - 22 minutes

Цілком очевидно, що rsync працював напрочуд погано порівняно з операцією tar, що, імовірно, можна віднести як до згаданих вище продуктивності мережі.

Я рекомендую всім, хто хоче створити резервну копію великої кількості в основному невеликих файлів, наприклад, резервного копіювання домашнього каталогу, використовувати метод tar. rsync здається дуже поганим вибором. Я повернусь до цієї публікації, якщо здається, що я був неточним у будь-якій моїй процедурі.

Нік

Використання rsync для надсилання архіву дьогтю за запитом насправді буде марною витратою або ресурсами, оскільки ви додасте в процес верифікаційний шар. Rsync перевіряє сумму файлу tar на правильність, коли ви бажаєте перевірити окремі файли. (Це не допомагає знати, що файл tar, який, можливо, був несправний на стороні відправки, вже демонструє той же ефект на кінці отримання). Якщо ви надсилаєте архів, ssh / scp - все, що вам потрібно.

Однією з причин, з якою вам доведеться обрати надсилання архіву, було б, якщо за вашим вибором дьоготь міг зберегти більше спеціальних файлових систем, таких як Список контролю доступу чи інші метадані, які часто зберігаються в розширених атрибутах (Solaris) або Ressource Forks (MacOS ). У роботі з такими речами, ваша основна проблема буде полягати в тому, які інструменти здатні зберігати всю інформацію, пов’язану з файлом у вихідній файловій системі, за умови, що цільова файлова система має можливість також відстежувати їх.

Коли швидкість є вашою основною турботою, це дуже залежить від розміру ваших файлів. Взагалі, безліч крихітних файлів буде сильно масштабуватись над rsync або scp, оскільки всі вони витрачають окремі мережеві пакети, де файл tar повинен містити декілька з них у межах завантаження даних одного мережевого пакету. Ще краще, якби файл tar був стислий, оскільки малі файли, швидше за все, стискатимуться краще в цілому, ніж окремо. Наскільки я знаю, і rsync, і scp не вдається оптимізуватись при відправці цілих окремих файлів, як при початковій передачі, при цьому кожен файл займає цілий кадр даних з усім протоколом накладних витрат (і витрачає більше на перевірку вперед і назад). Однак Janecekзаявляє, що це стосується лише scp, детально описуючи, що rsync оптимізував би мережевий трафік, але ціною побудови величезних структур даних в пам'яті. Дивіться статтю Ефективна передача файлів, Janecek 2006 . Тому, за його словами, все-таки вірно, що і scp, і rsync погано масштабуються на невеликих файлах, але з зовсім інших причин. Здогадуюсь, мені доведеться копатись до джерел у ці вихідні, щоб дізнатись.

Для практичної актуальності, якщо ви знаєте, що ви надсилаєте в основному більші файли, різниця в швидкості не буде великою, а використання rsync має додаткову перевагу від того, що можна перебратися там, де він залишився, коли його перервали.

Postscriptum: Цього дня rdist, здається, занурився у забуття, але до днів rsync це був дуже спроможний інструмент і широко застосовувався (безпечно, коли використовується над ssh, інакше небезпечно). Я б не працював так добре, як rsync, хоча, оскільки він не оптимізував лише передачу зміненого вмісту. Основна його відмінність від rsync полягає в тому, як вона налаштована, і в тому, як прописано правила оновлення файлів.

Для невеликих каталогів (невеликих, як у використаному просторі на диску), це залежить від накладних витрат перевірки інформації про файли для синхронізованих файлів. З одного боку, це rsyncекономить час передачі немодифікованих файлів, а з іншого - воно справді має передавати інформацію про кожен файл.

Я точно не знаю внутрішніх справ Росії rsync. Від того, чи статистика файлів викликає відставання, залежить від способу rsyncпередачі даних - якщо статистика файлів передається одна за одною, то RTT може зробити tar + rsync + untar швидше.

Але якщо у вас є, скажімо, 1 Гб даних, rsync буде набагато швидшим, якщо тільки ваш зв’язок справді не швидкий!

Мені довелося перенести кілька терабайт даних по всій країні, рівно один раз. В якості експерименту я провів два передачі, використовуючи rsyncта ssh/tarпобачивши, як вони порівнюються.

Результати:

• rsync передав файли із середньою швидкістю 2,76 мегабайт в секунду.
• ssh/tar передав файли із середньою швидкістю 4,18 мегабайт в секунду.

Деталі: Мої дані складаються з мільйонів стислих файлів .gz, середній розмір яких становить 10 мегабайт, але деякі - понад гігабайт. Існує структура каталогів, але вона обмежена розміром даних всередині файлів. Якби у мене було майже все інше, я б тільки використовував, rsyncале в цьому випадку ssh/tarце функціональне рішення.

Моя робота з rsync:

rsync --compress --stats --no-blocking-io --files-from=fileList.txt -av otherSystem:/the/other/dir/ dest/

де fileList.txt - це великий довгий список відносних імен файлів з іншого боку. (Я помітив, що --compressпісля запуску файли не є продуктивними для стислих файлів, але я не збираюся повертатися до перезавантаження.)

Я почав ще одне з ssh та tar:

ssh otherSystem "cd /the/other/dir/;  tar cf - ." | tar xvf -

Ви будете спостерігати за цими копіями все, вибачте, це не 100% порівняння яблук з яблуками.

Додам, що, використовуючи внутрішню мережу компанії, мені потрібно пройти посередника, щоб потрапити на комп'ютер джерела даних. Час ping від мого цільового комп'ютера до посередника становить 21 мс, а від посередника до джерела даних - 26 мс. Це було однаково для обох передач.

Підключення SSL через посередника здійснюється через ~/.ssh/configзапис:

Host otherSystem
    Hostname dataSource.otherSide.com
    User myUser
    Port 22
    ProxyCommand ssh -q -W %h:%p intermediary.otherSide.com
    IdentityFile   id_rsa.priv

Час цей:

tar cf - ~/.cache | ssh admin@nas_box "(cd /destination ; tar xf -)"