Я просто зробив невеликий експеримент, де створив архів дьогтю з дублікатами файлів, щоб побачити, чи не стиснеться він, на превеликий жаль, це не так! Деталі наступні (результати з відступом для задоволення від читання):

$ dd if=/dev/urandom bs=1M count=1 of=a
  1+0 records in
  1+0 records out
  1048576 bytes (1.0 MB) copied, 0.114354 s, 9.2 MB/s
$ cp a b
$ ln a c
$ ll
  total 3072
  -rw-r--r-- 2 guido guido 1048576 Sep 24 15:51 a
  -rw-r--r-- 1 guido guido 1048576 Sep 24 15:51 b
  -rw-r--r-- 2 guido guido 1048576 Sep 24 15:51 c
$ tar -c * -f test.tar
$ ls -l test.tar 
  -rw-r--r-- 1 guido guido 2109440 Sep 24 15:51 test.tar
$ gzip test.tar 
$ ls -l test.tar.gz 
  -rw-r--r-- 1 guido guido 2097921 Sep 24 15:51 test.tar.gz
$ 

Спочатку я створив 1MiB файл випадкових даних (a). Потім я скопіював його у файл b, а також з'єднав його з c. Створюючи тарбол, смола, мабуть, знала про жорстке посилання, оскільки тарбол був лише ~ 2MiB, а не ~ 3Mib.

Тепер я очікував, що gzip зменшить розмір тарболу до ~ 1MiB, оскільки a і b є дублікатами, і має бути 1MiB безперервних даних, що повторюються всередині тарболу, але цього не сталося.

Чому це? І як я міг би ефективно стискати тарбол у цих випадках?

Gzip gzip заснований на алгоритмі DEFLATE, який є комбінацією кодування LZ77 та Хаффмана. Це алгоритм стиснення даних без втрат, який працює, трансформуючи вхідний потік у стислі символи, використовуючи словник, побудований під час руху та перегляд дублікатів. Але він не може знайти дублікати, розділені на більш ніж 32 К. Очікувати, що він помітить копії 1 Мб один від одного, не реально.

Ніколь Гамільтон правильно зазначає, що gzipне знайде віддалених дублікатів даних через невеликий розмір словника.

bzip2 подібний, оскільки обмежений на 900 КБ пам'яті.

Натомість спробуйте:

Алгоритм LZMA / LZMA2 ( xz, 7z)

Алгоритм LZMA знаходиться в тому ж сімействі, що і Deflate, але використовує набагато більший розмір словника (налаштовується; за замовчуванням - це щось на зразок 384 Мб). xzУтиліта, яка повинна бути встановлена за замовчуванням в більшості останніх дистрибутивів Linux, аналогічна gzipі використовує LZMA.

Оскільки LZMA виявить надмірність надмірної дальності, тут можна буде дублювати ваші дані. Однак він повільніше, ніж Gzip.

Інший варіант - це 7-zip ( 7zв p7zipупаковці), що є архіватором (а не однопотоковим компресором), який використовує LZMA за замовчуванням (написаний автором LZMA). 7-zip-архіватор виконує власну дедупликацію на рівні файлу (дивлячись на файли з тим же розширенням) при архівуванні у його .7zформат. Це означає , що якщо ви готові замінити tarз 7z, ви отримуєте ідентичні файли дедупліцірованних. Однак 7z не зберігає наносекундні часові позначки, дозволи або xattrs, тому це може не відповідати вашим потребам.

lrzip

lrzipявляє собою компресор, який попередньо обробляє дані для видалення надмірних надмірностей перед подачею до звичайного алгоритму, як Gzip / Deflate, bzip2, lzop або LZMA. Для наведених тут зразків даних це не обов'язково; це корисно, коли вхідні дані більше, ніж те, що може вміститися в пам'яті.

Для такого роду даних (дублюються нестисливі шматки), ви повинні використовувати lzopстиснення (дуже швидко) lrzip, оскільки немає ніякої користі намагатися складніше стискати цілком випадкові дані після їх дублювання.

Буп і Обнам

Оскільки ви позначили резервне копіювання запитань , якщо ваша мета - це резервне копіювання даних, спробуйте скористатись програмою резервного копіювання, наприклад, Bup чи Obnam .

У разі створення резервної копії, можливо, з великим набором менших файлів, один фокус, який може працювати для вас, - це сортування файлів у тарі за розширенням:

find archive_dir -type f | rev | sort | rev | tar czf my_archive.tar.gz -I -

gzipне знайде дублікатів, навіть xzз великим розміром словника не буде. Що ви можете зробити - це скористатися mksquashfs- це дійсно заощадить простір дублікатів.

Деякі швидкі результати випробувань з xzі mksquashfsз трьома випадковими двійковими файлами (64MB) , з яких два є однаковими:

Налаштування:

mkdir test
cd test
dd if=/dev/urandom of=test1.bin count=64k bs=1k
dd if=/dev/urandom of=test2.bin count=64k bs=1k
cp test{2,3}.bin
cd ..

Кабачки:

mksquashfs test/ test.squash
> test.squash - 129M

xz:

XZ_OPT='-v --memlimit-compress=6G --memlimit-decompress=512M --lzma2=preset=9e,dict=512M --extreme -T4 ' tar -cJvf test.tar.xz test/
> test.tar.xz - 193M

У моїй системі lzma test.tarз'являється файл test.tar.lzma 106'3175 байт (1,1 М)

Як додаток до "відповіді механічної равлики:

Навіть xz (або lzma) не знайде дублікатів, якщо розмір файлу нестисненого єдиного файлу (або, точніше, відстань між дублікатами) перевищує розмір словника. xz (або lzma), навіть на найвищому рівні, -9eдля цього залишається лише 64 Мб.

На щастя, ви можете вказати свій власний розмір дикторію за допомогою параметра --lzma2=dict=256MB ( --lzma1=dict=256MBдозволено лише при використанні псевдоніма lzma для команди)

На жаль, при переосмисленні параметрів за допомогою спеціальних ланцюгів стиснення, як наведено у наведеному вище прикладі, значення за замовчуванням для всіх інших параметрів не встановлюються на такому ж рівні, як у -9e. Тож щільність стиснення не така висока для одиночних файлів.

gzip без комутаторів командного рядка використовує найменший можливий алгоритм для стиснення.

Спробуйте скористатися:

gzip -9 test.tar

Ви повинні отримати кращі результати