Ultimo aggiornamento: 20 Aug, 2026

GZIP vs BZIP2 vs XZ: Which Linux Compression Format Is Best?

GZIP vs BZIP2 vs XZ: Qual è il miglior formato di compressione per Linux?

Che tu stia comprimendo dump di database giornalieri, ruotando log di server web multi-gigabyte o distribuendo binari compilati a migliaia di nodi, la compressione è una realtà quotidiana nell’amministrazione Linux.

Quando invochi tar o elabori dati in streaming tramite lo standard input, tipicamente incontri tre utility standard: GZIP (.gz), BZIP2 (.bz2), e XZ (.xz).

Mentre tutti e tre gli strumenti mirano a comprimere i byte grezzi in archivi compatti, effettuano compromessi ingegneristici fondamentalmente diversi tra rapporto di compressione, tempo di esecuzione della CPU e utilizzo della memoria. Scegliere il formato sbagliato può creare silenziosamente colli di bottiglia nelle tue distribuzioni automatizzate, ritardare le finestre di backup programmate o sprecare prezioso spazio di archiviazione nel tempo.

Questa guida analizza come funziona ogni formato internamente, come si comportano con carichi di lavoro realistici e come scegliere quello giusto per la tua infrastruttura.

1. Profili tecnici rapidi: i tre contendenti

GZIP (GNU Zip)

  • Algoritmo di base: DEFLATE (combination of LZ77 and Huffman coding)
  • Estensione predefinita: .tar.gz, .tgz, .gz
  • Epoca di rilascio: 1992 (created by Jean-loup Gailly and Mark Adler as a patent-free alternative to compress)
  • Vantaggio principale: Velocità di esecuzione imbattibile e supporto quasi universale dell’ecosistema.
  • Svantaggio principale: Rapporto di compressione inferiore rispetto ai moderni encoder statistici e basati su dizionario.

GZIP è stato il cavallo di battaglia predefinito degli ambienti Unix per oltre tre decenni. Poiché il suo algoritmo DEFLATE opera con piccole finestre scorrevoli (32 KB), GZIP richiede un utilizzo di memoria trascurabile sia durante la compressione che durante la decompressione.

BZIP2

  • Algoritmo di base: Trasformazione Burrows-Wheeler (BWT) combinata con la trasformazione Move-to-Front (MTF) e la codifica Huffman
  • Estensione predefinita: .tar.bz2, .tbz2, .bz2
  • Epoca di rilascio: 1996 (creato da Julian Seward)
  • Vantaggio principale: Rapporti di compressione migliori su file ASCII ripetitivi e file di log strutturati rispetto a GZIP.
  • Svantaggio principale: Più lento in generale, soprattutto durante la decompressione, e in gran parte reso obsoleto da algoritmi più recenti.

BZIP2 elabora i dati in blocchi discreti (tipicamente 900 KB) utilizzando permutazioni reversibili che raggruppano caratteri simili prima della codifica. Sebbene fosse ampiamente celebrato alla fine degli anni ‘90 e nei primi 2000 per superare le dimensioni dei file GZIP, il suo costo computazionale è relativamente elevato.

XZ (LZMA2)

  • Algoritmo di base: LZMA2 (Algoritmo Lempel-Ziv-Markov chain, migliorato)
  • Estensione predefinita: .tar.xz, .txz, .xz
  • Epoca di rilascio: 2009 (introdotto per sostituire il vecchio formato lzma)
  • Vantaggio principale: Rapporti di compressione eccezionalmente alti e decompressione rapida e leggera.
  • Svantaggio principale: Elevato utilizzo di RAM e prolungata durata della CPU durante la compressione iniziale.

XZ sfrutta dimensioni variabili del dizionario (spesso fino a 32 MB o 64 MB per impostazione predefinita) per trovare pattern di byte duplicati su finestre di dati molto più ampie rispetto a GZIP. Questo lo rende estremamente efficace nel ridurre file grandi e ridondanti come i supporti di installazione del sistema operativo, gli alberi di sorgenti del kernel e le immagini del firmware.

2. Matrice di Confronto delle Prestazioni

La tabella seguente riassume le dinamiche pratiche delle prestazioni di ciascuna utility quando si eseguono configurazioni predefinite su hardware server standard:

Metrica / DimensioneGZIP (-6)BZIP2 (-9)XZ (-6)
Rapporto di compressioneModerato (~65-75% di riduzione)Buono (~75-80% di riduzione)Superiore (~80-88% di riduzione)
Velocità di compressioneMolto veloceLentoMolto lento
Velocità di decompressioneEstremamente veloceLento a moderatoVeloce
Utilizzo RAM per compressioneTrascurabile (~1–2 MB)Basso (~8–10 MB)Elevato (~100–700 MB+)
Utilizzo RAM per decompressioneTrascurabile (< 1 MB)Basso (~4 MB)Moderato (~10–65 MB)
Punto dolce principaleLog, pipeline CI/CD, flussi in tempo realeCompatibilità con archivi legacyRepository di pacchetti, ISO di OS, archiviazione a freddo

3. Approfondimenti sui Benchmark del Mondo Reale

Per capire come si comportano questi strumenti sotto carico realistico, considera un tipico registro di accesso al server grezzo da 1 GB e una directory di codice sorgente software non compressa da 500 MB.

Scenario A: Compressione di Grandi File di Log (Testo da 1 GB)

  • GZIP: Termina in meno di 12 secondi, producendo un archivio di circa 180 MB.
  • BZIP2: Termina in circa 45–50 secondi, riducendo il file a circa 130 MB.
  • XZ: Richiede 80–90 secondi con le impostazioni predefinite, producendo un archivio di circa 95 MB.

Scenario B: Carichi di Lavoro di Decompressione

Una metrica critica spesso trascurata è asimmetria.

  • GZIP si decomprime in 2–3 secondi con un utilizzo di memoria microscopico.
  • XZ si decomprime in 4–6 secondi. Sebbene la compressione iniziale fosse lenta, l’estrazione di .xz è quasi veloce quanto l’estrazione di .gz.
  • BZIP2 richiede circa 25–30 secondi solo per decomprimere, poiché invertire la Burrows‑Wheeler Transform è computazionalmente simmetrico alla sua codifica.

4. Perché BZIP2 Sta Perdendo Popolarità

Nelle infrastrutture moderne, BZIP2 si trova in una scomoda via di mezzo:

  1. Superato in velocità da GZIP: Se la latenza di elaborazione o il basso utilizzo della CPU sono importanti, GZIP è notevolmente più veloce.
  2. Superato in densità da XZ: Se la conservazione della larghezza di banda e l’efficienza di archiviazione sono importanti, XZ genera archivi notevolmente più piccoli.
  3. Superato in velocità di decompressione da entrambi: Nei sistemi di distribuzione software, i client subiscono una penalità CPU misurabile durante l’estrazione dei file .tar.bz2 rispetto a .tar.gz o .tar.xz.

Di conseguenza, le principali distribuzioni Linux (inclusi Debian, Arch e Fedora) hanno spostato la distribuzione ufficiale dei pacchetti e i tarball del kernel da BZIP2 verso XZ (e più recentemente, Zstandard per le operazioni di runtime).

5. Uso Pratico della Linea di Comando

Integrazione Tar (Il Flusso di Lavoro più Comune)

Le implementazioni moderne di GNU tar riconoscono automaticamente il formato di compressione in base all’estensione del file, ma l’uso di flag espliciti è ancora una pratica standard:

# GZIP: Fast archive creation
tar -czvf project-backup.tar.gz /var/www/project/

# BZIP2: Legacy high-ratio archive
tar -cjvf project-backup.tar.bz2 /var/www/project/

# XZ: Maximum space savings
tar -cJvf project-backup.tar.xz /var/www/project/

# Generic extraction (tar auto-detects the format)
tar -xvf archive-name.tar.*

Compressione di file autonoma

Per comprimere file individuali senza raggrupparli:

# Compress keeping the original file intact (-k)
gzip -k access.log      # Output: access.log.gz
bzip2 -k access.log     # Output: access.log.bz2
xz -k access.log        # Output: access.log.xz

# Decompress individual files
gzip -d access.log.gz
bzip2 -d access.log.bz2
xz -d access.log.xz

Utilizzo di sistemi multicore

Per impostazione predefinita, le implementazioni monothread di questi strumenti utilizzano solo un core CPU. Se si comprimono archivi multi-gigabyte su server moderni multicore, l’elaborazione monothread può richiedere ore.

  • Multithreading XZ: Supporto nativo tramite -T o --threads:
    xz -T0 -k database_dump.sql   # Uses all available CPU cores
    
  • GZIP parallelo (pigz): Un sostituto drop-in che utilizza tutti i core CPU per le operazioni GZIP:
    pigz -k database_dump.sql
    
  • BZIP2 parallelo (pbzip2): Implementazione multithread per BZIP2:
    pbzip2 -k database_dump.sql
    

6. Come scegliere: quadro decisionale pratico

Scegli lo strumento in base al vincolo principale del tuo flusso di lavoro:

Usa GZIP se:

  • Stai configurando la compressione in tempo reale di flussi o la trasmissione di rete dove la larghezza di banda è il fattore limitante.
  • Stai gestendo la rotazione automatica dei log (logrotate) sui server di produzione dove le risorse CPU devono essere riservate per i carichi di lavoro delle applicazioni.
  • È richiesta la massima portabilità tra sistemi embedded legacy e immagini di base standard.

Usa XZ se:

  • Stai pubblicando artefatti di rilascio, build del kernel, immagini di base dei container o repository di pacchetti statici scaricati frequentemente da terze parti.
  • Stai preparando archivi freddi a lungo termine (backup settimanali/mensili fuori sede) dove i costi di archiviazione superano il tempo di compressione una tantum.
  • Hai bisogno di file di piccole dimensioni, ma i tuoi utenti richiedono comunque download rapidi e tempi di estrazione veloci.

Mantieni BZIP2 solo se:

  • Stai mantenendo la retrocompatibilità con script legacy, routine di ripristino backup esistenti o appliance software che non forniscono un decompressore XZ.

7. Domande frequenti (FAQ)

Q1. Quale formato fornisce la dimensione di archivio più piccola? XZ produce costantemente la dimensione di archivio più piccola tra i tre grazie alle sue finestre di dizionario LZMA2 più ampie.

Q2. XZ è più lento di GZIP nella decompressione dei file? XZ è solo leggermente più lento di GZIP nella decompressione, ma è sostanzialmente più veloce di BZIP2.

Q3. GZIP e XZ possono sfruttare più core CPU? XZ supporta il multi-threading nativo usando il flag -T0, mentre GZIP può essere parallelizzato sui core usando l’utilità pigz.

Q4. Perché le distribuzioni Linux stanno eliminando BZIP2? Le distribuzioni hanno in gran parte abbandonato BZIP2 perché XZ comprime di più e decomprime più velocemente, mentre GZIP rimane più veloce per operazioni rapide.

Q5. Un livello di compressione più alto come -9 fa una differenza notevole? Impostare il livello -9 produce solo una riduzione marginale della dimensione dell'1% al 3% in media, aumentando drasticamente il consumo di cicli CPU e l’overhead di memoria.

Vedi anche