Ho appena fatto un piccolo esperimento in cui ho creato un archivio tar con file duplicati per vedere se sarebbe stato compresso, con mio stupore, non lo era! Seguono i dettagli (risultati rientrati per piacere di lettura):

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

Innanzitutto ho creato un file 1MiB di dati casuali (a). Quindi l'ho copiato in un file b e l'ho anche collegato a c. Durante la creazione del tarball, tar apparentemente era a conoscenza del collegamento fisico, poiché il tarball era solo ~ 2MiB e non ~ 3Mib.

Ora mi aspettavo che gzip riduca la dimensione del tarball a ~ 1MiB poiché aeb sono duplicati e ci dovrebbero essere 1MiB di dati continui ripetuti all'interno del tarball, ma ciò non è avvenuto.

Perchè è questo? E come potrei comprimere il tarball in modo efficiente in questi casi?

Gzip gzip si basa sull'algoritmo DEFLATE, che è una combinazione di LZ77 e codifica Huffman. È un algoritmo di compressione dei dati senza perdita di dati che funziona trasformando il flusso di input in simboli compressi utilizzando un dizionario incorporato al volo e cercando duplicati. Ma non riesce a trovare duplicati separati da più di 32 KB. Aspettarsi di individuare duplicati a 1 MB di distanza non è realistico.

Nicole Hamilton osserva correttamente che gzipnon troverà dati duplicati distanti a causa delle sue piccole dimensioni del dizionario.

bzip2 è simile perché è limitato a 900 KB di memoria.

Invece, prova:

Algoritmo LZMA / LZMA2 ( xz, 7z)

L'algoritmo LZMA appartiene alla stessa famiglia di Deflate, ma utilizza una dimensione del dizionario molto più ampia (personalizzabile; l'impostazione predefinita è qualcosa come 384 MB). L' xzutilità, che dovrebbe essere installata per impostazione predefinita sulle distribuzioni Linux più recenti, è simile gzipe utilizza LZMA.

Poiché LZMA rileva ridondanza a lungo raggio, sarà in grado di deduplicare i dati qui. Tuttavia, è più lento di Gzip.

Un'altra opzione è 7-zip ( 7z, nel p7zippacchetto), che è un archiviatore (anziché un compressore a flusso singolo) che utilizza LZMA per impostazione predefinita (scritto dall'autore di LZMA). L'archiviatore a 7 zip esegue la propria deduplicazione a livello di file (guardando i file con la stessa estensione) durante l'archiviazione nel suo .7zformato. Ciò significa che se si desidera sostituire tarcon 7z, si ottengono deduplicati file identici. Tuttavia, 7z non conserva i timestamp, i permessi o gli xattr di nanosecondi, quindi potrebbe non essere adatto alle tue esigenze.

lrzip

lrzipè un compressore che preelabora i dati per rimuovere la ridondanza a lunga distanza prima di inviarli a un algoritmo convenzionale come Gzip / Deflate, bzip2, lzop o LZMA. Per i dati di esempio forniti qui, non è necessario; è utile quando i dati di input sono più grandi di quelli che possono stare in memoria.

Per questo tipo di dati (blocchi duplicati incomprimibili), dovresti usare la lzopcompressione (molto velocemente) con lrzip, perché non c'è alcun vantaggio nel provare di più a comprimere i dati completamente casuali dopo che sono stati deduplicati.

Bup e Obnam

Dato che hai taggato il backup della domanda , se il tuo obiettivo qui è il backup dei dati, prendi in considerazione l'utilizzo di un programma di backup deduplicato come Bup o Obnam .

Nel caso di un backup, possibilmente con un set ampio di file più piccoli, un trucco che potrebbe funzionare per te è quello di ordinare i file nel tar per estensione:

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

gzipnon troverà duplicati, anche xzcon una dimensione del dizionario enorme non lo farà. Quello che puoi fare è usare mksquashfs- questo risparmierà davvero lo spazio dei duplicati.

Alcuni risultati di test rapidi con xze mksquashfscon tre file binari casuali (64 MB) di cui due uguali:

Impostare:

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

Sul mio sistema lzma test.tarrisulta un file test.tar.lzma di 106'3175 byte (1.1M)

In aggiunta alla risposta della 'lumaca meccanica:

Anche xz (o lzma) non troverà duplicati se la dimensione del file singolo non compresso (o, più precisamente, la distanza tra i duplicati) supera la dimensione del dizionario. xz (o lzma) anche con l'impostazione più alta -9eriserva solo 64 MB per questo.

Fortunatamente puoi specificare la tua dimensione dittonaria con l'opzione --lzma2=dict=256MB ( --lzma1=dict=256MBè consentito solo quando si usa l'alias lzma per il comando)

Sfortunatamente, quando si sovrascrivono le impostazioni con catene di compressione personalizzate come indicato nell'esempio sopra, i valori predefiniti per tutti gli altri parametri non sono impostati allo stesso livello di -9e. Quindi la densità di compressione non è così alta per i singoli file.

gzip senza opzioni della riga di comando utilizza l'algoritmo più basso possibile per la compressione.

Prova a usare:

gzip -9 test.tar

Dovresti ottenere risultati migliori