Pocas cifras de marketing generan tantas expectativas —y tantas decepciones— como los ratios de reducción de datos. "Hasta 10:1", "reduce tu almacenamiento un 90%"… La realidad es más matizada: la compresión y la deduplicación son tecnologías distintas, con costes distintos, y su eficacia depende casi por completo del tipo de dato que guardes.
Entender la diferencia no es un ejercicio académico: determina cuántos TB necesitas contratar para tus repositorios de backup, cuánta RAM debe tener tu servidor de almacenamiento y cuánto tardarás en restaurar cuando algo falle. También explica por qué dos proveedores que anuncian "el mismo precio por TB" pueden costarte cantidades muy distintas a final de mes.
En este artículo desmontamos las dos tecnologías, damos ratios realistas por tipo de dato, analizamos el coste oculto en CPU y RAM, y repasamos cómo las aplican en la práctica Veeam, Proxmox Backup Server y las cabinas de almacenamiento.
Compresión y Deduplicación: Qué Hace Cada Una
La compresión actúa dentro de cada bloque de datos: busca redundancia local (secuencias repetidas, símbolos frecuentes) y la codifica de forma más compacta. Cada bloque se reduce de manera independiente, sin necesidad de conocer el resto del almacenamiento. Es un proceso puramente de CPU, sin estado global, y por eso escala bien y es fácil de razonar.
La deduplicación actúa entre bloques: calcula una huella criptográfica (hash) de cada bloque y, si ya existe otro idéntico en el repositorio, guarda solo una referencia en lugar de una segunda copia. No reduce cada bloque; elimina bloques repetidos. Para funcionar necesita mantener un índice de todas las huellas conocidas, y ese índice es precisamente el origen de su coste oculto.
Son complementarias y casi siempre se aplican juntas: primero la deduplicación descarta los bloques repetidos y después la compresión encoge los bloques únicos que sí hay que escribir. Un backup de 20 máquinas virtuales Windows es el ejemplo perfecto: la deduplicación elimina las 19 copias redundantes de los ficheros del sistema operativo, y la compresión reduce lo que queda.
Tipos de Deduplicación: Inline, Post-Proceso, Fichero y Bloque
No todas las deduplicaciones son iguales. Hay tres ejes que definen cómo trabaja cada implementación:
- check_circle Inline vs post-proceso: la dedup inline compara y descarta los bloques antes de escribirlos en disco (menos espacio necesario, más CPU y RAM en el momento del backup). La dedup post-proceso escribe primero todo y deduplica después en segundo plano (necesita espacio temporal extra, pero no penaliza la ventana de backup).
- check_circle A nivel de fichero vs a nivel de bloque: la dedup por fichero solo detecta ficheros completos idénticos (útil en servidores de ficheros, inútil en imágenes de VM). La dedup por bloque trocea los datos y encuentra redundancia aunque los ficheros contenedores sean distintos, que es lo habitual en backup.
- check_circle Chunking fijo vs variable: con bloques de tamaño fijo, insertar un byte al principio de un fichero desplaza todos los bloques siguientes y rompe la dedup. El chunking variable (basado en el contenido, con técnicas tipo Rabin fingerprinting) corta los bloques en fronteras naturales del dato y resiste esos desplazamientos, a cambio de más CPU.
La combinación más eficaz para backup suele ser dedup inline, a nivel de bloque y con chunking variable. Es también la más cara computacionalmente, y por eso muchos productos optan por soluciones intermedias: bloques fijos grandes, dedup solo dentro de cada job, o dedup delegada al sistema de ficheros del repositorio.
LZ4, zstd y gzip: Elegir Algoritmo de Compresión
En backup y almacenamiento hay tres familias de algoritmos que cubren prácticamente todos los casos:
- arrow_right LZ4: velocidad extrema (varios GB/s por núcleo) con ratio moderado. Es la opción cuando la CPU es el cuello de botella o cuando comprimes en el propio host de producción. Descomprime tan rápido que su impacto en restauraciones es despreciable.
- arrow_right zstd: el equilibrio moderno. Con niveles bajos se acerca a la velocidad de LZ4 con bastante mejor ratio, y sus niveles altos compiten con los compresores pesados. Es el estándar de facto actual: lo usan ZFS, Proxmox Backup Server, btrfs y cada vez más herramientas de backup.
- arrow_right gzip (DEFLATE): el veterano universal. Ratios correctos pero mucho más lento que zstd a igualdad de compresión. Hoy solo tiene sentido por compatibilidad; para almacenamiento nuevo, zstd lo supera en casi todos los frentes.
La regla práctica: LZ4 cuando prima la velocidad, zstd para casi todo lo demás, y niveles altos de zstd solo en datos fríos que se escriben una vez y se leen rara vez.
Ratios Realistas por Tipo de Dato
El ratio de reducción no lo decide el software: lo decide la redundancia que exista en tus datos. Estos son los rangos que vemos de forma consistente en entornos reales:
| Tipo de dato | Compresión | Deduplicación | Reducción total típica |
|---|---|---|---|
| VMs con SO similares | 1.5–2x | Alta (bloques de SO repetidos) | 2–4x |
| Bases de datos activas | 1.5–2.5x | Baja–media | 1.5–2.5x |
| Ficheros ofimáticos modernos (docx, xlsx, PDF) | 1.2–1.5x (ya van comprimidos) | Media (versiones repetidas) | 1.3–2x |
| Logs y texto plano | 3–8x | Media | 3–8x |
| Media: vídeo, imágenes, ZIP | ~1x | ~1x (salvo copias exactas) | ~1x |
| Datos cifrados en origen | ~1x | ~1x | ~1x |
Dos matices importantes. Primero: el vídeo, las imágenes JPEG y los archivos comprimidos ya han pasado por un compresor; volver a comprimirlos gasta CPU para ganar prácticamente nada, y no tiene sentido insistir. Segundo: donde la deduplicación brilla de verdad es en la dimensión temporal — las copias incrementales de la misma VM día tras día comparten la inmensa mayoría de bloques, y ahí los ratios acumulados sobre la cadena de retención sí pueden ser de dos dígitos.
El Coste Oculto: CPU, RAM y Tiempos de Restauración
La compresión cuesta CPU, y con LZ4 o zstd en niveles bajos ese coste es hoy casi irrelevante frente al ahorro. La deduplicación es otra historia: su índice de huellas debe consultarse en cada escritura, y si no cabe en RAM, cada bloque escrito provoca lecturas aleatorias adicionales a disco.
El ejemplo canónico es ZFS. Su tabla de deduplicación (DDT) guarda una entrada de varios cientos de bytes por cada bloque único del pool; la regla clásica habla de unos 5 GB de RAM por cada TB deduplicado. Cuando la DDT desborda la memoria, el rendimiento de escritura se desploma de forma dramática. Por eso la recomendación general —recogida en la propia documentación de OpenZFS— es que la dedup de ZFS casi nunca compensa fuera de casos muy concretos. La compresión con zstd, en cambio, casi siempre sí: coste mínimo, sin estado global y con beneficio incluso en el rendimiento de lectura, porque se leen menos bytes del disco. Si quieres profundizar en cómo ZFS protege la integridad de tus datos, lo tratamos en nuestro artículo sobre el sistema de archivos ZFS.
El otro coste que se olvida en las comparativas es la restauración. Un repositorio muy deduplicado convierte una lectura secuencial en miles de lecturas dispersas: los bloques de tu VM están repartidos por todo el almacén, y "rehidratar" los datos castiga especialmente a los repositorios sobre discos mecánicos. Un ratio de reducción excelente no sirve de nada si el RTO se dispara el día que de verdad necesitas restaurar.
Cifrado y Orden de Operaciones: el Error que Destruye los Ratios
Un buen cifrado produce salida indistinguible de datos aleatorios: sin patrones, sin repeticiones, sin redundancia. Si cifras antes de deduplicar o comprimir, no queda nada que reducir — dos bloques idénticos cifrados con claves o vectores de inicialización distintos ya no se parecen en nada, y el ratio cae a ~1x de golpe.
El orden correcto:
1) Deduplicar → 2) Comprimir → 3) Cifrar. Deja que sea el software de backup quien cifre después de reducir. Si envías al repositorio datos ya cifrados en origen (discos con BitLocker/LUKS volcados en bruto, archivos cifrados por aplicación), asume ratio ~1x y dimensiona el almacenamiento en consecuencia.
Este es el motivo por el que las herramientas serias integran el cifrado en su propia cadena: Veeam cifra los bloques después de comprimirlos, y Proxmox Backup Server cifra los chunks ya deduplicados. La seguridad no se resiente y los ratios sobreviven.
Dónde Ocurre en la Práctica: Veeam, Proxmox Backup Server y Cabinas
Veeam aplica compresión y deduplicación por job: los bloques se deduplican dentro de la cadena de backup de cada trabajo y se comprimen con un algoritmo configurable (el nivel "optimal", basado en LZ4, es el equilibrio recomendado). Además, sobre repositorios ReFS o XFS aprovecha el block cloning del sistema de ficheros: los synthetic full se construyen como referencias a bloques ya existentes, ocupando una fracción del espacio y sin mover datos. Es una de las razones por las que un repositorio bien diseñado importa tanto como el software; en nuestro servicio de backup offsite con Veeam Cloud Connect los repositorios están dimensionados precisamente con esto en mente.
Proxmox Backup Server lleva la deduplicación al núcleo de su diseño: todo backup se trocea en chunks identificados por su hash y almacenados una sola vez para todo el datastore, con compresión zstd por chunk. Cada copia nueva de una VM solo aporta los chunks que no existían, así que la dedup es global y entre máquinas, no solo dentro de un job.
Las cabinas y appliances de deduplicación (Data Domain, StoreOnce y similares) aplican dedup inline con chunking variable a todo lo que reciben, y de ahí salen los ratios de dos dígitos de sus fichas técnicas — medidos sobre semanas de fulls repetidos, no sobre el primer backup. Los sistemas de almacenamiento de objetos, como nuestro almacenamiento S3, suelen facturar por el dato ya reducido que finalmente ocupas, lo que nos lleva al último punto.
Consejo al comparar proveedores:
Cuando compares precios por TB, pregunta siempre si el TB facturado es antes o después de la reducción de datos (front-end vs back-end). Un precio por TB "más caro" sobre datos ya deduplicados y comprimidos puede salir bastante más barato que uno "económico" sobre datos en bruto. Haz números con tu caso real en nuestra calculadora de backup Veeam.
Preguntas Frecuentes
¿Qué ratio de reducción puedo esperar en mis backups?
Depende del tipo de dato: VMs con sistemas operativos similares alcanzan 2–4x combinando dedup y compresión; bases de datos activas, 1.5–2.5x; logs y texto plano, 3–8x solo con compresión; y vídeo, imágenes o ficheros ya comprimidos apenas se reducen (~1x).
¿Debo activar la deduplicación de ZFS?
Casi nunca. La tabla de deduplicación debe residir en RAM (del orden de varios GB por TB deduplicado) y, si no cabe, el rendimiento de escritura se desploma. La compresión con zstd o LZ4, en cambio, tiene un coste mínimo y compensa en casi todos los casos: actívala siempre.
¿Por qué mis backups cifrados no se deduplican?
El cifrado convierte los datos en bloques estadísticamente aleatorios: dos bloques idénticos cifrados con distinta clave o distinto vector de inicialización dejan de parecerse, y ni la dedup ni la compresión encuentran redundancia. Reduce primero y cifra después, dejando el cifrado en manos del software de backup.
Conclusión
La deduplicación y la compresión ahorran espacio real, pero ni tanto como promete el marketing ni gratis. Lo que conviene recordar:
- arrow_right La compresión reduce cada bloque; la deduplicación elimina bloques repetidos. Se complementan y el orden importa: dedup, después compresión, después cifrado.
- arrow_right Los ratios dependen del dato: 2–4x en VMs con SO similares, moderado en bases de datos y ofimática, ~1x en media, ficheros comprimidos y datos cifrados en origen.
- arrow_right zstd casi siempre compensa; la dedup de ZFS casi nunca. La dedup exige RAM para su índice y penaliza las restauraciones al dispersar los bloques.
- arrow_right Al comparar proveedores, pregunta si el TB facturado es antes o después de la reducción: cambia por completo la comparativa de precios.
Si quieres dimensionar tus repositorios de backup con ratios realistas en lugar de cifras de folleto, contacta con nuestro equipo: analizamos tu caso y te preparamos una estimación sin compromiso.