У мене є відносні невеликі файли даних, але вони займають близько 50 ГБ, і мені потрібно їх перенести на іншу машину. Я намагався придумати найбільш ефективний спосіб зробити це.
Думав, що я мав зібрати всю річ, а потім rsync і розпакувати її, покластися на rsync -z для стиснення, gzip потім використовувати rsync -z. Я не впевнений, що було б найбільш ефективно, оскільки я не впевнений, як саме реалізовано rsync -z. Будь-які ідеї, який варіант був би найшвидшим?
Відповіді:
Ви не можете "gzip все це", оскільки gzip стискає лише один файл, ви можете створити файл tar і gzip, щоб "gzip вся справа", але ви втратите можливість rsync копіювати лише модифікований файл.
Отже, питання: чи краще зберігати файл, який мені потрібно rsync gziped, або покластись на -z варіант rsync.
Відповідь, ймовірно, ви не хочете, щоб файл розпаковувався на вашому сервері? Я думаю, що так, тому я не бачу, як ви могли б управляти файлом gzip, перш ніж робити rsync.
Можливо, вам не потрібна можливість rsync копіювати лише модифікований файл? У цьому випадку, чому використовувати rsync замість того, щоб робити копію файлу tar.gz, що містить ваші речі?
У будь-якому випадку, щоб відповісти на питання, rsync gzip буде трохи менш ефективним, ніж gziping файл з gzip. Чому? оскільки rsync буде gzip фрагменти даних за допомогою фрагмента, тому менший набір даних буде використаний для створення таблиці, яку gzip використовує для стиснення, більший набір даних (gzip використовує весь файл одразу) дасть кращу таблицю стиснення. Але різниця в більшості випадків буде дуже маленькою, але в дуже рідкісному випадку різниця може бути важливішою (якщо у вас дуже великий файл з дуже довгим партерном повторенням багато разів у файлі, але далеко один від одного) (Це дуже спрощений приклад)
Якщо ви копіюєте дані лише один раз, rsync не стане великою виграшею сама по собі. Якщо вам подобається gzip, (або tar + gzip, оскільки у вас є багато файлів), ви можете спробувати щось на кшталт:
tar -cz /home/me/source/directory | ssh target tar -xz --directory /home/you/target/directory
Це дозволить отримати потрібне стиснення та просто скопіювати безпосередньо, не залучаючи rsync.
@radius, незначна нитка, про яку можна зрозуміти, як gzipпрацює - gzipце алгоритм стиснення на основі блоків, і досить простий у цьому. Весь файл не враховується для таблиці стиснення - лише кожен блок. Інші алгоритми можуть використовувати весь вміст файлу, і є декілька, які використовують вміст декількох блоків або навіть блоків із змінним розміром. Один із захоплюючих прикладів - це lrzipтой самий автор, що і rsync!
Отже, підсумовуючи, використання rsync -z, ймовірно, призведе до того ж стиснення, що gzipі перше - і якщо ви робите диференційну передачу, краще через rsyncрізний алгоритм.
З цього приводу , я думаю, що ви знайдете, що регулярно scpвлучно б'ється rsyncза недиференційовані передачі - тому що у нього буде набагато менше накладних витрат, ніж rsyncу алгоритму алгоритму (який би scpв будь-якому разі використовувався під капотом!)
Якщо ваша мережа дійсно стає вузьким місцем, то ви хочете використовувати компресію на дроті.
Якщо ваші диски - це вузьке місце, саме тоді потокове передавання в стислий файл було б найкращим. (наприклад, netcatз однієї машини на іншу, потокове в gzip -c)
Зазвичай, якщо швидкість є ключовою, стискання наявного файлу до початку є марним.
TIMTOWTDI, YMMV, IANAL тощо.
За словами цього хлопця, можливо, просто скористатися швидше rsync -z, хоча я б припустив, що це буде наближеним до настільки ж ефективного, як стиснення кожного файлу спочатку перед передачею. Це має бути швидше, ніж стиснення дьогтю, як це пропонують інші.
На чоловіковій сторінці:
Note that this option typically achieves better compression
ratios than can be achieved by using a compressing remote shell
or a compressing transport because it takes advantage of the
implicit information in the matching data blocks that are not
explicitly sent over the connection.
Оскільки і scp стисненого файлу, і rsync потребуватимуть дуже схожих часів передачі, "найефективнішим способом зробити це" було б передача на ходу, а не стиснення, передача.
Окрім "швидкості", інші міркування включають:
rsync можна легко перезапустити, якщо не всі файли будуть передані.
rsync можна використовувати для підтримки файлів на віддаленій машині.
місцевий дьоготь або gzip вимагає місцевого простору.
Міркування щодо використання портів і для цільової машини, і для брандмауерів: 1) scp використовує порт 22 (за замовчуванням), який може бути неприйнятним. 2) порт rsync користувачів 873 (за замовчуванням)
Я не впевнений, чому радіус очікує, що оригінальний плакат НЕ хоче зберігати розпаковані файли.