Je viens de faire une petite expérience où j'ai créé une archive tar avec des fichiers en double pour voir si elle serait compressée, à ma grande admiration, ce n'était pas le cas! Les détails suivent (résultats en retrait pour le plaisir de lire):

$ 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
$ 

J'ai d'abord créé un fichier 1 Mo de données aléatoires (a). Ensuite, je l'ai copié dans un fichier b et l'ai également lié à c. Lors de la création de l'archive tar, tar était apparemment au courant du lien dur, car l'archive tar n'était que de ~ 2 Mo et non de ~ 3Mib.

Maintenant, je m'attendais à ce que gzip réduise la taille de l'archive tar à ~ 1 Mo, car a et b sont des doublons, et il devrait y avoir 1 Mo de données continues répétées à l'intérieur de l'archive, mais cela ne s'est pas produit.

Pourquoi est-ce? Et comment pourrais-je compresser efficacement l'archive tar dans ces cas?

Gzip gzip est basé sur l'algorithme DEFLATE, qui est une combinaison du codage LZ77 et Huffman. Il s'agit d'un algorithme de compression de données sans perte qui fonctionne en transformant le flux d'entrée en symboles compressés à l'aide d'un dictionnaire créé à la volée et en surveillant les doublons. Mais il ne peut pas trouver de doublons séparés par plus de 32 Ko. Il n'est pas réaliste de s'attendre à repérer des doublons à 1 Mo d'intervalle.

Nicole Hamilton note correctement que gzipne trouvera pas de données en double éloignées en raison de la petite taille de son dictionnaire.

bzip2 est similaire, car il est limité à 900 Ko de mémoire.

Essayez plutôt:

Algorithme LZMA / LZMA2 ( xz, 7z)

L'algorithme LZMA appartient à la même famille que Deflate, mais utilise une taille de dictionnaire beaucoup plus grande (personnalisable; la valeur par défaut est d'environ 384 Mo). L' xzutilitaire, qui devrait être installé par défaut sur les distributions Linux les plus récentes, est similaire gzipet utilise LZMA.

Comme LZMA détecte une redondance à plus longue portée, il pourra dédupliquer vos données ici. Cependant, il est plus lent que Gzip.

Une autre option est 7-zip ( 7z, dans le p7zippackage), qui est un archiveur (plutôt qu'un compresseur à flux unique) qui utilise LZMA par défaut (écrit par l'auteur de LZMA). L'archiveur 7-zip exécute sa propre déduplication au niveau du fichier (en regardant les fichiers avec la même extension) lors de l'archivage à son .7zformat. Cela signifie que si vous êtes prêt à remplacer taravec 7z, vous obtenez des fichiers identiques dédupliquées. Cependant, 7z ne conserve pas les horodatages, les autorisations ou les xattrs en nanosecondes, il peut donc ne pas répondre à vos besoins.

lrzip

lrzipest un compresseur qui pré-traite les données pour supprimer la redondance longue distance avant de les alimenter à un algorithme conventionnel comme Gzip / Deflate, bzip2, lzop ou LZMA. Pour les exemples de données que vous donnez ici, ce n'est pas nécessaire; il est utile lorsque les données d'entrée sont plus grandes que ce qui peut tenir en mémoire.

Pour ce type de données (morceaux incompressibles dupliqués), vous devez utiliser la lzopcompression (très rapide) avec lrzip, car il n'y a aucun avantage à essayer plus fort de compresser des données complètement aléatoires une fois qu'elles sont dédupliquées.

Bup et Obnam

Depuis que vous avez marqué la sauvegarde de la question , si votre objectif ici est de sauvegarder des données, envisagez d'utiliser un programme de sauvegarde avec déduplication comme Bup ou Obnam .

Dans le cas d'une sauvegarde, éventuellement avec un ensemble plus large de fichiers plus petits, une astuce qui pourrait fonctionner pour vous est de trier les fichiers dans le tar par extension:

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

gzipne trouvera pas de doublons, même xzavec une énorme taille de dictionnaire. Ce que vous pouvez faire, c'est utiliser mksquashfs- cela permettra en effet d'économiser l'espace des doublons.

Quelques résultats de tests rapides avec xzet mksquashfsavec trois fichiers binaires aléatoires (64 Mo) dont deux identiques:

Installer:

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 ..

Squashfs:

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

Sur mon système, le lzma test.tarfichier test.tar.lzma de 106'3175 octets (1,1 Mo)

En complément de la réponse de l'escargot mécanique:

Même xz (ou lzma) ne trouvera pas de doublons si la taille du fichier unique non compressé (ou, plus précisément, la distance entre les doublons) dépasse la taille du dictionnaire. xz (ou lzma) même sur le réglage le plus élevé -9ene réserve que 64 Mo pour cela.

Heureusement, vous pouvez spécifier votre propre taille de dicton avec l'option --lzma2=dict=256MB (uniquement --lzma1=dict=256MBautorisé lorsque vous utilisez l'alias lzma pour la commande)

Malheureusement, lors de la substitution des paramètres avec des chaînes de compression personnalisées comme indiqué dans l'exemple ci-dessus, les valeurs par défaut pour tous les autres paramètres ne sont pas définies au même niveau qu'avec -9e. La densité de compression n'est donc pas aussi élevée pour des fichiers uniques.

gzip sans commutateurs de ligne de commande utilise l'algorithme le plus bas possible pour la compression.

Essayez d'utiliser:

gzip -9 test.tar

Vous devriez obtenir de meilleurs résultats