Чи дозволяє параметр стиснення -z з rsync прискорити резервне копіювання

В rsync, -zбуде стискати дані файлу під час передачі.

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

Чи залежить відповідь на питання, чи я створюю резервну копію на зовнішній hdd через usb (2.0 або 3.0) або на сервер через ssh через Інтернет?

Це загальне питання. Чи покращують компресію та декомпресію в кінцевих точках ефективну пропускну здатність зв'язку?

Ефективна смуга пропускання зв'язку, що робить стиснення та декомпресію в кінцевих точках, є функцією:

1. як швидко ви можете стиснути (швидкість вашого процесора)
2. фактична пропускна здатність вашої мережі

Функція описана у цьому 3D графіку, з яким ви можете порадитись для вашої конкретної ситуації:

Графік бере початок із статті " Інструменти стиснення порівняно" 2005 року від http://www.linuxjournal.com/ .

Якщо у вас дуже повільне з'єднання (думаю, GPRS), ви напевно хочете максимально стиснути ваші дані, інакше ваш зв’язок сповільнить роботу.

Якщо у вас дуже повільний процесор і швидке з'єднання (наприклад, вбудований мережевий пристрій), ви зазвичай не хочете стискати свої дані, інакше ваш процесор сповільнить роботу.

Залежить від того, наскільки стислими є ваші дані та потужність обробки вашого джерела та місця призначення. По моєму досвіду, повна резервна копія диска скоротить приблизно 30-50% від початкового розміру, тому, можливо, варто сфотографувати його. Інакше не турбуйтеся стисканням. Можливо, варто перевірити свій рівень стиснення pigz -c <your file> | wc -cі порівняти повернутий розмір з початковим розміром.

Так, швидкість з'єднання визначає, чи прискорюється швидкість. Це буде накладними лише для резервного копіювання через USB, оскільки дані не надувають дані, а процес, який записує дані. Тож та сама машина, яка її читає і знижує, має також надувати і записувати. Я думаю, що Rsync - це ще два процеси, але вашій пам’яті для передачі даних з одного процесу в інший досить швидко, і процесору потрібно більше часу для його стиснення (під час читання в тій самій пам'яті, що згодом передає його :).

Стиснення допомагає лише тоді, коли у вас є rsync відправника та одержувача та деяка повільна мережа між ними. 1Gbit може бути вже досить швидким, якщо у вас є, наприклад, локальний NAS, 10Gbit - це вже сира швидкість SATA. Тому стиснення потрібне лише тоді, коли у вас є 100 Мбіт або менше підключення, і це має сенс лише тоді, коли стислі дані є стислими.

Я думаю, rsync може помітити, що він працює не на двох машинах, а на одній і пропускає стиснення, але не впевнений.

tl; dr Над повільними передачевими зв’язками стискайте, інакше не робіть. Нижче - тест на швидкість стиснення, посилання на інструмент перетворення пропускної здатності та деяку інформацію.

Використання стиснення за допомогою rsyncприскорить роботу лише тоді, коли проміжна ланка "досить повільна", тобто якщо машина в одному кінці здатна виробляти стислий потік даних досить швидко, щоб наситити зв'язок зв'язку.

Отже, яка найповільніша ланка, за якою я повинен використовувати стиснення, щоб отримати щось?

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

Вхідні дані сильно змінять результат тесту . Я використовую некомпресований (!) Звичайний файл на своєму комп’ютері, який може відображати тип даних, які я зазвичай передаю по мережах. Використання /dev/zero(отримання необмежених нулів) було б оманливим, оскільки потік нулів було б дуже легко стиснути, а використання /dev/randomбуло б введено в оману з протилежної причини. Тож замість цього я використовую файл смоли мого $HOME/localкаталогу, який містить програмне забезпечення, яке я встановив у своєму $HOME. Файл не стискається сам по собі, але містить суміш бінарних файлів, невеликих стислих файлів та вихідних / текстових файлів, і я б стиснув його з налаштуваннями за замовчуванням, оскільки gzipвін скоротиться на 67% з 64 МБ до 22 МБ.

$ gzip -c local.tar | dd of=/dev/null
43092+4 records in
43093+1 records out
22063854 bytes transferred in 2.819 secs (7825741 bytes/sec)

Я роблю це кілька разів, щоб зрозуміти, яким може бути середній показник, і це доходить до приблизно 7800000 байт / с.

Потім я використовую мережевий калькулятор пропускної здатності, щоб побачити, в що це перетворюється. У цьому конкретному випадку трапляється просто за допомогою провідного каналу "100 Мбіт Ethernet", просто швидшого, ніж "Вхід на скачування VDSL" в Інтернеті, трохи швидшого, ніж бездротового зв'язку "802.11 [а / г]", і десь між "Bluetooth v3.0" (повільніше) та "USB 2.0" (швидше).

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

rsyncне може бути з допомогою точних же бібліотек , як gzipзробити стиснення, але вище дасть вам трохи натяку , по крайней мере.

rsyncробить більше, ніж стиснення, хоча, як відомо, і реальне збільшення швидкості відбувається лише через передачу [біт] файлів, які змінилися.

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

Для здійснення додаткових резервних копій я б напевно рекомендував дослідити --link-destваріант (це не має нічого спільного з тим, що передається, лише з тим, як зберігаються речі в цілі). Крім того, якщо ви робите це через SSH, не використовуйте стиснення, якщо ваше з'єднання SSH вже стиснене, а стискайте лише SSH-з'єднання (тунелі тощо), які перебувають через повільні зв'язки, з тих же причин, що і вище.