Estrategias de deduplicación de archivos en la nube

La deduplicación de ficheros reduce el almacenamiento en la nube entre un 20 y un 90% según la carga de trabajo, mediante una de tres técnicas: a nivel de fichero (almacena ficheros idénticos una sola vez, indexados por hash SHA-256), a nivel de bloque (divide los ficheros en bloques de 4-128 KB y deduplica por bloque), o mediante fragmentación de longitud variable con Content-Defined Chunking (CDC) y huellas Rabin. Las copias de seguridad de máquinas virtuales obtienen reducciones de 10:1; los ficheros de oficina generales, 2:1; las bibliotecas multimedia, casi nada. Elige la técnica que se ajuste a tus datos — ejecutar dedup a nivel de bloque sobre una biblioteca de ficheros .mp4 ya únicos consume CPU sin ningún beneficio.

Dedup a nivel de fichero: la mejora más sencilla

La deduplicación a nivel de fichero compara los hashes del fichero completo. Dos ficheros con el mismo SHA-256 son idénticos; se conserva uno y el otro apunta a él. La implementación lleva un fin de semana:

1. Inventariar el contenido del bucket (S3 Inventory, Azure Inventory, listado de bucket de GCS)
2. Calcular el SHA-256 de cada objeto (o usar los ETags del proveedor, con matices)
3. Agrupar por hash, elegir una clave canónica por grupo, actualizar las referencias y eliminar los duplicados

Matices: los ETags de S3 coinciden con SHA-256 solo para cargas de una sola parte de menos de 5 GB. Las cargas multiparte usan una fórmula distinta (hash de hashes). Para una deduplicación fiable, calcula tu propio hash con aws s3 cp s3://bucket/key - | sha256sum o calcúlalo en el momento de la carga y guárdalo en los metadatos.

La dedup a nivel de fichero destaca cuando los usuarios cargan rutinariamente los mismos ficheros: PDFs de proveedores, plantillas corporativas, imágenes compartidas. Espera ahorros del 10-30% en cargas de trabajo de oficina típicas.

Dedup a nivel de bloque: el gran multiplicador

El nivel de bloque divide cada fichero en fragmentos de tamaño fijo (4 KB, 16 KB, 64 KB) y hace hash de cada fragmento. Dos ficheros que comparten el 80% de sus bloques almacenan solo el 20% único más una copia de los bloques compartidos. Productos de copia de seguridad (Veeam, Rubrik, Commvault), sistemas de ficheros (ZFS con dedup=on, Btrfs) y algunas nubes de backup (Backblaze B2 con dedup en el cliente) usan este enfoque.

Ventajas: compresión masiva en imágenes de VM, copias de seguridad de bases de datos y archivos de registros donde los ficheros comparten grandes rangos. Desventajas: alto consumo de memoria (el índice de dedup reside en RAM), coste de CPU en el momento de la escritura y amplificación catastrófica si el índice se corrompe.

Para el almacenamiento de objetos en la nube, la dedup a nivel de bloque ocurre habitualmente dentro de un producto de backup más que como característica nativa. S3 no deduplica; Backblaze B2 deduplica en el momento de la carga cuando el cliente envía primero los hashes de bloque (b2_start_large_file con partes pre-hasheadas).

Content-Defined Chunking (CDC)

La fragmentación de tamaño fijo falla cuando se inserta un byte al principio de un fichero — todos los bloques posteriores tienen un hash diferente. El Content-Defined Chunking usa un hash rodante (huella Rabin-Karp) para definir los límites de los fragmentos según los patrones del contenido. Inserta un byte y solo cambia el fragmento inmediato.

CDC es la base de restic, BorgBackup, Duplicacy y Kopia. Estas herramientas de código abierto deduplicant en el cliente con fragmentos variables que promedian entre 1 y 4 MB. Para hacer copia de seguridad de 500 GB de ficheros que cambian de forma incremental, los backups basados en CDC suelen usar menos de 50 GB de almacenamiento único.

Si estás construyendo un sistema de backup o sincronización, CDC a través de una biblioteca como fastcdc-rs o chunky es la opción moderna. No implementes tu propio hash rodante desde cero — los casos límite son sutiles.

Dedup inline frente a post-proceso

La dedup inline se ejecuta en el momento de la escritura — antes de que los datos lleguen al disco, el sistema comprueba si el bloque ya existe. Si es así, escribe una referencia; si no, escribe el bloque. La usan ZFS, la mayoría de los dispositivos de backup y algunos niveles de almacenamiento en la nube.

La dedup post-proceso escribe primero y luego ejecuta un trabajo en segundo plano para encontrar duplicados y recuperar espacio. La usa la deduplicación de datos de Windows Server, SnapVault de NetApp y la mayoría de las herramientas en el espacio de usuario. El post-proceso tiene menor latencia de escritura pero necesita más almacenamiento pico (los duplicados existen brevemente antes de ser recuperados).

Para cargas de trabajo en la nube, la dedup inline suele no estar disponible — S3 no la ofrece. El post-proceso con un trabajo programado (inventario diario, ejecución diaria de dedup) es el patrón práctico.

Dónde la dedup no ayuda

Los datos ya comprimidos o cifrados se deduplan mal. Dos ficheros .mp4 diferentes, incluso de contenido similar, comparten casi ningún byte. Dos ficheros .zip cifrados del mismo texto en claro no comparten ningún byte tras el cifrado — ese es precisamente el objetivo del cifrado.

Esto significa que el almacenamiento de ficheros cifrado de extremo a extremo no puede deduplicar entre usuarios. El cifrado convergente (hashear el texto en claro y usar el hash como clave) fue un intento de habilitar la dedup en E2EE, pero tiene problemas de seguridad — permite ataques de confirmación de fichero. En los servicios de ficheros E2EE, acepta que la dedup ocurre dentro de los propios ficheros de un usuario, no entre usuarios.

El lado de la seguridad en la dedup

La dedup entre usuarios en sistemas sin E2EE crea un canal lateral: si un fichero que cargas deduplica a un bloque existente, el servidor sabe que otra persona ya tenía ese fichero. Dropbox lo expuso en 2011; otros servicios también. Para cuentas empresariales compartidas está bien, pero para servicios que afirman privacidad, es una filtración.

Si la confidencialidad importa, deduplica solo dentro de los datos de un mismo usuario (con sal de una clave específica del usuario), no en todo el sistema. O acepta que E2EE implica no dedup y dimensiona el almacenamiento en consecuencia. Las herramientas que priorizan la privacidad — HexaTransfer para transferencias ad hoc cifradas, por ejemplo — intercambian eficiencia de dedup por la garantía de que nadie más (incluido el servicio) puede saber si dos usuarios tienen el mismo fichero.

Medir la eficacia de la dedup

No actives la dedup y esperes lo mejor. Mide el ratio:

dedup_ratio = logical_bytes / physical_bytes

Un ratio de 2:1 significa que almacenas 2 bytes lógicos por cada 1 byte físico. Herramientas de informe: zpool get dedupratio en ZFS, Get-DedupStatus en Windows Server, estadísticas por repositorio en restic/Borg.

Ratios saludables por carga de trabajo:

• Imágenes de VM: 8-20:1
• Copias de seguridad de bases de datos: 10-30:1
• Servidor de ficheros (documentos de oficina): 1,5-3:1
• Archivos de correo: 2-5:1
• Bibliotecas multimedia: 1,0-1,1:1 (no merece la pena)
• Archivos cifrados: 1,0:1 (imposible)

Si el ratio de una carga de trabajo está por debajo de 1,5:1, desactiva la dedup — la CPU y la memoria no se están pagando solas.

Integración con productos de backup

La mayoría de las empresas no implementan la dedup desde cero — usan un producto de backup que ya la incluye. Puntos de comparación al seleccionar:

• Veeam: Dedup de bloque inline, bloques por defecto de 512 KB, compresión tras la dedup
• Rubrik: Fragmentos variables definidos por contenido, dedup sub-bloque
• Commvault: Dedup en el cliente con grupos por cliente y globales
• restic/Borg/Kopia: CDC de código abierto, en el cliente, backends S3/B2/Azure
• BackupPC: A nivel de fichero con hardlinks, sencillo pero anticuado

Para una pequeña empresa que hace copia de seguridad de 2 TB en S3 Glacier, restic a Glacier Instant Retrieval cuesta unos 15 USD/mes con una dedup de 5:1. Para un patrimonio de datos empresarial de 500 TB, una plataforma de backup adecuada con dedup se paga sola en el primer año de ahorro en almacenamiento.

Cuándo añadir compresión encima

La dedup elimina bytes duplicados; la compresión elimina redundancia dentro de los bytes únicos. Se acumulan. Tras la dedup, aplica compresión zstd para otra reducción de 1,5-2x en datos con mucho texto. BorgBackup admite --compression zstd; restic tiene --compression max; AWS EFS tiene compresión transparente para OneZone-IA.

El orden importa: primero la dedup (para exponer los bloques duplicados), luego comprimir los bloques únicos. Comprimir primero suele anular la dedup porque pequeños cambios en la entrada se propagan a lo largo de la salida comprimida. Todos los productos de backup serios gestionan esto correctamente — solo hay que elegir las opciones.

La dedup es aburrida, poco glamurosa, y el mayor palanca individual sobre el coste de almacenamiento para cargas de trabajo mixtas. Haz el inventario de los datos, elige la técnica que se ajuste al contenido, mide el ratio y recupera el presupuesto.

Pruébalo en hexatransfer.com — gratis, sin cuenta, máximo 10 GB.