Strategie di deduplicazione file per il cloud storage

La deduplicazione dei file riduce lo storage cloud dal 20 al 90% a seconda del workload, usando una di tre tecniche: a livello di file (archivia file identici una volta sola, con chiave hash SHA-256), a livello di blocco (suddivide i file in blocchi da 4-128 KB e deduplica per blocco), o con chunking a lunghezza variabile tramite content-defined chunking (CDC) con fingerprint Rabin. I backup VM vedono riduzioni di 10:1; i file office generici vedono 2:1; le librerie media non vedono quasi nulla. Scegli la tecnica che corrisponde ai tuoi dati — eseguire dedup a livello di blocco su una libreria di .mp4 già unici spreca CPU senza alcun guadagno.

Dedup a livello di file: la vittoria più semplice

La dedup a livello di file confronta gli hash dell'intero file. Due file con lo stesso SHA-256 sono identici; tienine uno, punta l'altro su di esso. L'implementazione richiede un weekend:

1. Inventaria il contenuto del bucket (S3 Inventory, Azure Inventory, lista bucket GCS)
2. Calcola SHA-256 per ogni oggetto (o usa gli ETag forniti dal provider, con avvertenze)
3. Raggruppa per hash, scegli una chiave canonica per gruppo, aggiorna i riferimenti, elimina i duplicati

Avvertenze: gli ETag S3 corrispondono a SHA-256 solo per gli upload monoparte sotto i 5 GB. Gli upload multipart usano una formula diversa (hash degli hash). Per una dedup affidabile, calcola il tuo hash con aws s3 cp s3://bucket/key - | sha256sum o calcolalo al momento dell'upload e conservalo nei metadati.

La dedup a livello di file brilla quando gli utenti caricano abitualmente gli stessi file — PDF di fornitori, template aziendali, immagini condivise. Aspettati un risparmio del 10-30% sui workload office tipici.

Dedup a livello di blocco: il moltiplicatore potente

Il livello di blocco suddivide ogni file in chunk di dimensione fissa (4 KB, 16 KB, 64 KB) e calcola l'hash di ogni chunk. Due file che condividono l'80% dei loro chunk archiviano solo il 20% unico più una copia dei blocchi condivisi. I prodotti di backup (Veeam, Rubrik, Commvault), i filesystem (ZFS con dedup=on, Btrfs) e alcuni cloud di backup (Backblaze B2 con dedup lato client) usano questo approccio.

Vantaggi: compressione massiccia su immagini VM, backup di database e archivi di log dove i file condividono grandi intervalli. Svantaggi: utilizzo elevato di memoria (l'indice di dedup vive in RAM), costo CPU al momento della scrittura e amplificazione catastrofica se l'indice si corrompe.

Per lo storage a oggetti cloud, la dedup a livello di blocco avviene di solito all'interno di un prodotto di backup piuttosto che come funzionalità nativa. S3 non deduplica; Backblaze B2 deduplica al momento dell'upload quando il client invia prima gli hash dei blocchi (b2_start_large_file con parti pre-hashate).

Content-Defined Chunking (CDC)

Il chunking a dimensione fissa si rompe quando si inserisce un byte all'inizio di un file — ogni blocco successivo ha un hash diverso. Il Content-Defined Chunking usa un rolling hash (fingerprint Rabin-Karp) per definire i confini dei chunk in base ai pattern del contenuto. Inserisci un byte e cambia solo il chunk immediato.

Il CDC è la base di restic, BorgBackup, Duplicacy e Kopia. Questi strumenti open-source deduplicano lato client con chunk variabili che fanno in media 1-4 MB. Per il backup di 500 GB di file che cambiano incrementalmente, i backup basati su CDC spesso usano meno di 50 GB di storage unico.

Se stai costruendo un sistema di backup o sync, il CDC tramite una libreria come fastcdc-rs o chunky è la scelta moderna. Non scrivere il tuo rolling hash — i casi limite sono sottili.

Dedup inline vs post-process

La dedup inline funziona al momento della scrittura — prima che i dati tocchino il disco, il sistema verifica se il blocco esiste già. Se sì, scrive un riferimento; se no, scrive il blocco. Usata da ZFS, la maggior parte degli appliance di backup e alcuni livelli di storage cloud.

La dedup post-process scrive prima, poi esegue un job in background per trovare i duplicati e recuperare spazio. Usata dalla deduplicazione dei dati di Windows Server, SnapVault di NetApp e la maggior parte degli strumenti user-space. Il post-process ha una latenza di scrittura inferiore ma necessita di più storage di picco (i duplicati esistono brevemente prima del recupero).

Per i workload cloud, la dedup inline è solitamente non disponibile — S3 non la offre. Il post-process con un job pianificato (inventario giornaliero, esecuzione dedup giornaliera) è il pattern pratico.

Dove la dedup non aiuta

I dati già compressi o cifrati si deduplicano male. Due file .mp4 diversi, anche di contenuto simile, condividono quasi nessun byte. Due file .zip cifrati dello stesso testo in chiaro condividono zero byte dopo la cifratura — è proprio questo il punto della cifratura.

Questo significa che lo storage file cifrato end-to-end non può deduplicare tra utenti. La cifratura convergente (hasha il testo in chiaro, usa l'hash come chiave) era un tentativo di abilitare la dedup tra E2EE ma ha problemi di sicurezza — abilita gli attacchi di conferma del file. Per i servizi file E2EE, accetta che la dedup avviene all'interno dei file di un utente, non tra utenti.

Il lato sicurezza della dedup

La dedup cross-user in sistemi non E2EE crea un canale laterale: se un file che carichi viene deduplicato a un blocco esistente, il server sa che qualcun altro aveva già quel file. Dropbox lo aveva esposto nel 2011; altri servizi anche. Per gli account aziendali condivisi va bene, ma per i servizi che affermano la privacy è una perdita.

Se la riservatezza conta, deduplica solo all'interno dei dati di un utente (salati con una chiave specifica dell'utente), non nell'intero sistema. Oppure accetta che E2EE significa nessuna dedup e dimensiona lo storage di conseguenza. Gli strumenti che danno priorità alla privacy — HexaTransfer per i trasferimenti ad-hoc cifrati, ad esempio — scambiano l'efficienza della dedup con la garanzia che nessun altro (incluso il servizio) possa stabilire se due utenti hanno lo stesso file.

Misurare l'efficacia della dedup

Non abilitare semplicemente la dedup e sperare. Misura il rapporto:

dedup_ratio = byte_logici / byte_fisici

Un rapporto di 2:1 significa che stai archiviando 2 byte logici per ogni byte fisico. Strumenti di reporting: zpool get dedupratio su ZFS, Get-DedupStatus su Windows Server, statistiche per-repo su restic/Borg.

Rapporti sani per workload:

• Immagini VM: 8-20:1
• Backup di database: 10-30:1
• File server (documenti office): 1,5-3:1
• Archivi email: 2-5:1
• Librerie media: 1,0-1,1:1 (non vale la pena)
• Archivi cifrati: 1,0:1 (impossibile)

Se il rapporto di un workload è sotto 1,5:1, disattiva la dedup — CPU e memoria non si ripagano.

Integrazione con i prodotti di backup

La maggior parte delle aziende non implementa la dedup da zero — usa un prodotto di backup che la gestisce. Punti di confronto nella selezione:

• Veeam: Dedup a blocchi inline, chunk di default da 512 KB, compressione dopo la dedup
• Rubrik: Chunk variabili a contenuto definito, dedup sub-blocco
• Commvault: Dedup lato client con pool per-client e globali
• restic/Borg/Kopia: CDC open-source, lato client, backend S3/B2/Azure
• BackupPC: A livello di file con hardlink, semplice ma datato

Per una piccola azienda che esegue il backup di 2 TB su S3 Glacier, restic su Glacier Instant Retrieval costa circa 15 €/mese con dedup 5:1. Per un patrimonio dati aziendale da 500 TB, una piattaforma di backup adeguata con dedup si ripaga nel primo anno di risparmio sullo storage.

Quando aggiungere la compressione sopra

La dedup rimuove i byte duplicati; la compressione rimuove la ridondanza all'interno dei byte unici. Si sommano. Dopo la dedup, applica la compressione zstd per un'ulteriore riduzione da 1,5 a 2 volte sui dati ricchi di testo. BorgBackup supporta --compression zstd; restic ha --compression max; AWS EFS ha compressione trasparente per OneZone-IA.

L'ordine conta: prima la dedup (per esporre i blocchi duplicati), poi comprimi i blocchi unici. Comprimere prima di solito vanifica la dedup perché piccole modifiche all'input si propagano attraverso l'output compresso. Tutti i prodotti di backup seri gestiscono questo correttamente — scegli solo i parametri.

La dedup è noiosa, poco attraente e la leva singola più potente sui costi di storage per i workload misti. Inventaria i dati, scegli la tecnica che corrisponde al contenuto, misura il rapporto e recupera il budget.

Provalo su hexatransfer.com — gratuito, senza account, max 10 GB.