Última actualización: 20 de ago., 2026

GZIP vs BZIP2 vs XZ: ¿Cuál formato de compresión de Linux es el mejor?
Ya sea que estés empaquetando volcados diarios de bases de datos, rotando registros de servidores web de varios gigabytes, o distribuyendo binarios compilados a miles de nodos, la compresión es una realidad cotidiana en la administración de Linux.
Al invocar tar o procesar datos en streaming a través de la entrada estándar, normalmente te encuentras con tres utilidades estándar: GZIP (.gz), BZIP2 (.bz2), y XZ (.xz).
Mientras los tres herramientas buscan comprimir bytes crudos en archivos compactos, hacen compromisos de ingeniería fundamentalmente diferentes entre la relación de compresión, el tiempo de ejecución de la CPU y el consumo de memoria. Elegir el formato incorrecto puede crear cuellos de botella silenciosos en sus implementaciones automatizadas, retrasar las ventanas de respaldo programadas o desperdiciar valioso espacio de almacenamiento con el tiempo.
Esta guía desglosa cómo funciona cada formato internamente, cómo rinden bajo cargas de trabajo realistas y cómo elegir el adecuado para su infraestructura.
1. Perfiles técnicos rápidos: los tres contendientes
GZIP (GNU Zip)
- Algoritmo subyacente: DEFLATE (combination of LZ77 and Huffman coding)
- Extensión predeterminada:
.tar.gz,.tgz,.gz - Época de lanzamiento: 1992 (created by Jean-loup Gailly and Mark Adler as a patent-free alternative to
compress) - Ventaja principal: Velocidad de ejecución inigualable y soporte casi universal en el ecosistema.
- Desventaja principal: Relación de compresión más baja en comparación con los codificadores estadísticos y basados en diccionario modernos.
GZIP ha sido el caballo de batalla predeterminado de los entornos Unix durante más de tres décadas. Debido a que su algoritmo DEFLATE opera con pequeñas ventanas deslizantes (32 KB), GZIP requiere un consumo de memoria insignificante tanto durante la compresión como la descompresión.
BZIP2
- Algoritmo subyacente: Transformada de Burrows-Wheeler (BWT) combinada con la transformación Move-to-Front (MTF) y codificación Huffman
- Extensión predeterminada:
.tar.bz2,.tbz2,.bz2 - Época de lanzamiento: 1996 (creado por Julian Seward)
- Ventaja principal: Mejores ratios de compresión en archivos ASCII repetitivos y logs estructurados que GZIP.
- Desventaja principal: Más lento en general, especialmente durante la descompresión, y en gran parte obsoleto por algoritmos más nuevos.
BZIP2 procesa datos en bloques discretos (normalmente 900 KB) usando permutaciones reversibles que agrupan caracteres similares antes de codificar. Aunque fue ampliamente celebrado a finales de los años 90 y en los 2000 por superar los tamaños de archivo de GZIP, su costo computacional es relativamente alto.
XZ (LZMA2)
- Algoritmo subyacente: LZMA2 (Algoritmo de cadena de Markov Lempel-Ziv, mejorado)
- Extensión predeterminada:
.tar.xz,.txz,.xz - Era de lanzamiento: 2009 (introducido para reemplazar el formato
lzmamás antiguo) - Ventaja principal: Ratios de compresión excepcionalmente altos y descompresión rápida y ligera.
- Desventaja principal: Alto consumo de RAM y tiempo de CPU prolongado durante la compresión inicial.
XZ aprovecha tamaños de diccionario variables (a menudo hasta 32 MB o 64 MB por defecto) para encontrar patrones de bytes duplicados en ventanas de datos mucho más amplias que GZIP. Esto lo hace devastadoramente eficaz para reducir archivos grandes y redundantes como medios de instalación del SO, árboles de código del kernel y imágenes de firmware.
2. Matriz de Comparación de Rendimiento
La tabla a continuación resume la dinámica de rendimiento práctico de cada utilidad al ejecutar configuraciones predeterminadas en hardware de servidor estándar:
| Métrica / Dimensión | GZIP (-6) | BZIP2 (-9) | XZ (-6) |
|---|---|---|---|
| Relación de compresión | Moderado (~65-75% reducción) | Bueno (~75-80% reducción) | Superior (~80-88% reducción) |
| Velocidad de compresión | Muy rápido | Lento | Muy lento |
| Velocidad de descompresión | Extremadamente rápido | Lento a moderado | Rápido |
| Uso de RAM de compresión | Despreciable (~1–2 MB) | Bajo (~8–10 MB) | Alto (~100–700 MB+) |
| Uso de RAM de descompresión | Despreciable (< 1 MB) | Bajo (~4 MB) | Moderado (~10–65 MB) |
| Punto óptimo principal | Registros, canalizaciones CI/CD, flujos en tiempo real | Compatibilidad con archivos heredados | Repositorios de paquetes, ISOs del SO, almacenamiento en frío |
3. Información de Benchmark del Mundo Real
Para entender cómo se comportan estas herramientas bajo una carga realista, considere un registro de acceso al servidor sin procesar de 1 GB representativo y un directorio de código fuente de software sin comprimir de 500 MB.
Escenario A: Compresión de Grandes Archivos de Registro (Texto de 1 GB)
- GZIP: Finaliza en menos de 12 segundos, entregando un archivo de aproximadamente 180 MB.
- BZIP2: Finaliza en aproximadamente 45–50 segundos, reduciendo el archivo a alrededor de 130 MB.
- XZ: Toma 80–90 segundos con la configuración predeterminada, produciendo un archivo de aproximadamente 95 MB.
Escenario B: Cargas de Trabajo de Descompresión
Una métrica crítica a menudo pasada por alto es asimetría.
- GZIP descomprime en 2–3 segundos con un uso de memoria microscópico.
- XZ descomprime en 4–6 segundos. Aunque la compresión inicial fue lenta, extraer
.xzes casi tan rápido como extraer.gz. - BZIP2 requiere aproximadamente 25–30 segundos solo para desempaquetar, porque invertir la Transformada de Burrows-Wheeler es computacionalmente simétrica a codificarla.
4. Por Qué BZIP2 Está Perdiendo Popularidad
En la infraestructura moderna, BZIP2 se encuentra atrapado en un incómodo punto medio:
- Superado en velocidad por GZIP: Si la latencia de procesamiento o el bajo uso de CPU son importantes, GZIP es significativamente más rápido.
- Superado en densidad por XZ: Si la conservación del ancho de banda y la eficiencia de almacenamiento son importantes, XZ genera archivos considerablemente más pequeños.
- Superado en velocidad de descompresión por ambos: En los sistemas de entrega de software, los clientes pagan una penalización de CPU medible al extraer archivos
.tar.bz2en comparación con.tar.gzo.tar.xz.
Consecuentemente, las principales distribuciones de Linux (incluyendo Debian, Arch y Fedora) han desplazado sus paquetes oficiales y tarballs del kernel de BZIP2 a XZ (y más recientemente, Zstandard para operaciones en tiempo de ejecución).
5. Uso Práctico de la Línea de Comandos
Integración de Tar (El Flujo de Trabajo Más Común)
Las implementaciones modernas de GNU tar reconocen automáticamente el formato de compresión según la extensión del archivo, pero el uso de banderas explícitas sigue siendo una práctica estándar:
# 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.*
Compresión de archivos independiente
Para comprimir archivos individuales sin empaquetarlos:
# 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
Utilizando sistemas multinúcleo
Por defecto, las implementaciones de un solo hilo de estas herramientas utilizan solo un núcleo de CPU. Si está comprimiendo archivos de varios gigabytes en servidores modernos de múltiples núcleos, el procesamiento de un solo hilo puede tardar horas.
- Multi-hilo XZ: Soporte nativo mediante
-To--threads:xz -T0 -k database_dump.sql # Uses all available CPU cores - GZIP paralelo (
pigz): Un reemplazo directo que utiliza todos los núcleos de CPU para operaciones GZIP:pigz -k database_dump.sql - BZIP2 paralelo (
pbzip2): Implementación multi-hilo para BZIP2:pbzip2 -k database_dump.sql
6. Cómo elegir: Marco de decisión práctico
Elija su herramienta en función de la restricción principal de su flujo de trabajo:
Usar GZIP si:
- Está configurando compresión de flujo en tiempo real o transmisión de red donde el rendimiento es el factor limitante.
- Está gestionando la rotación automática de registros (
logrotate) en servidores de producción donde los recursos de CPU deben reservarse para las cargas de trabajo de las aplicaciones. - Se requiere la máxima portabilidad entre sistemas embebidos heredados y imágenes base estándar.
Usar XZ si:
- Está publicando artefactos de lanzamiento, compilaciones del kernel, imágenes base de contenedores o repositorios de paquetes estáticos descargados frecuentemente por terceros.
- Está preparando archivos fríos a largo plazo (copias de seguridad semanales/mensuales fuera del sitio) donde los costos de almacenamiento superan el tiempo de compresión único.
- Necesita tamaños de archivo pequeños, pero sus usuarios aún exigen descargas rápidas y tiempos de extracción breves.
Mantener BZIP2 solo si:
- Está manteniendo la compatibilidad retroactiva con scripts heredados, rutinas de restauración de copias de seguridad existentes o dispositivos de software que no proporcionan un descompresor XZ.
7. Preguntas frecuentes (FAQ)
Q1. ¿Qué formato proporciona el tamaño de archivo más pequeño? XZ produce consistentemente el tamaño de archivo más pequeño entre los tres debido a sus ventanas de diccionario LZMA2 más grandes.
Q2. ¿Es XZ más lento que GZIP al descomprimir archivos? XZ es solo ligeramente más lento que GZIP al descomprimir, pero es sustancialmente más rápido que BZIP2.
Q3. ¿Pueden GZIP y XZ aprovechar múltiples núcleos de CPU? XZ admite multihilo nativo usando la bandera -T0, mientras que GZIP puede paralelizarse entre núcleos usando la utilidad de reemplazo pigz.
Q4. ¿Por qué las distribuciones Linux están eliminando BZIP2? Las distribuciones han eliminado en gran medida BZIP2 porque XZ comprime a un tamaño menor y descomprime más rápido, mientras que GZIP sigue siendo más rápido para operaciones rápidas.
Q5. ¿Hace una diferencia notable un nivel de compresión más alto como -9? Establecer el nivel -9 produce solo una reducción marginal del 1 % al 3 % del tamaño en promedio, mientras que aumenta dramáticamente el consumo de ciclos de CPU y la sobrecarga de memoria.