Hai modificato una singola riga in un file di configurazione da 2 GB. Eppure il tuo sistema di backup ha riscritto l'intero file sul cloud. Di nuovo. La colpa non è della connessione di rete, né del backend di storage. Il problema risiede nell'algoritmo che decide come suddividere i dati in blocchi prima di archiviarli: il cosiddetto chunking.
Come funziona la deduplicazione dei dati
Qualsiasi sistema di deduplicazione — da restic a Borg, passando per soluzioni enterprise — opera secondo lo stesso principio fondamentale: i dati vengono suddivisi in segmenti (chunk), ciascuno identificato da un hash crittografico. Se due chunk producono lo stesso hash, vengono archiviati una volta sola. Il risparmio di spazio dipende interamente dalla qualità di questa suddivisione.
Il metodo più semplice è il Fixed-Size Chunking (FSC): i dati vengono tagliati in blocchi di dimensione fissa, ad esempio ogni 4 MB. Questo approccio è veloce e prevedibile, ma presenta un difetto critico noto come boundary shift problem: se si inserisce anche un solo byte all'inizio di un file, tutti i blocchi successivi si spostano, rendendo irriconoscibili i chunk già archiviati. Il risultato? Il backup "incrementale" si comporta di fatto come un backup completo.
Content-Defined Chunking: tagliare dove ha senso
Il Content-Defined Chunking (CDC) — tecnica che determina i punti di taglio analizzando il contenuto stesso dei dati, anziché la loro posizione — risolve elegantemente questo problema. L'algoritmo scorre il flusso di byte calcolando un rolling hash (hash scorrevole: funzione che aggiorna il proprio valore in modo incrementale su una finestra mobile di byte) su una finestra mobile. Quando il valore dell'hash soddisfa una determinata condizione — tipicamente un pattern di bit specifico — viene identificato un punto di taglio naturale.
Il vantaggio è immediato: i punti di taglio dipendono dal contenuto locale, non dalla posizione assoluta nel file. Una modifica in testa al documento non sposta i boundary nelle sezioni successive. Solo i chunk effettivamente alterati vengono re-inviati al backend.
Algoritmi CDC a confronto
Esistono diverse implementazioni di CDC, ognuna con caratteristiche proprie:
- Rabin Fingerprinting: il capostipite, proposto negli anni '80. Utilizza polinomi in aritmetica modulare per calcolare il rolling hash. Robusto ma computazionalmente costoso.
- FastCDC: algoritmo moderno ottimizzato per throughput elevato. Riduce il numero di operazioni per byte e introduce un meccanismo di normalization per mantenere le dimensioni dei chunk entro range desiderati.
- Buzhash: alternativa basata su tabelle di lookup XOR, particolarmente efficiente su architetture moderne grazie alla semplicità delle operazioni bitwise.
La scelta dell'algoritmo influisce su tre parametri chiave: velocità di chunking, tasso di deduplicazione e dimensione media dei chunk (tipicamente configurabile tra 512 KB e 8 MB).
Implicazioni pratiche per i team DevOps e SRE
Per i professionisti che gestiscono pipeline di backup in ambienti Linux, la comprensione del CDC ha implicazioni concrete:
Ambienti con file grandi e modifiche parziali — database dump, immagini disco, repository di grandi dimensioni — beneficiano enormemente del CDC rispetto al FSC. Il risparmio di banda e storage può superare il 70% in scenari reali.
Container e immagini OCI: i layer di un'immagine Docker sono già strutturati in modo da favorire la deduplicazione, ma i tool di backup che operano a livello di filesystem raw possono vanificare questo vantaggio se usano FSC.
Tuning dei parametri: la dimensione minima, media e massima dei chunk è configurabile in tool come restic e Kopia. Un chunk medio troppo piccolo aumenta il metadata overhead; troppo grande riduce la granularità della deduplicazione.
Strumenti che implementano CDC oggi
Nell'ecosistema open source Linux, diversi tool adottano CDC in produzione:
- restic: usa una variante di Rabin CDC con chunk medi da 1 MB
- Kopia: supporta FastCDC con parametri configurabili
- Borg Backup: implementa un proprio algoritmo CDC ottimizzato per file system locali
- casync (di Lennart Poettering): progettato specificamente per la distribuzione di immagini sistema con CDC
Conclusione tecnica
Il boundary shift problem è silenzioso e devastante per l'efficienza dei backup. Adottare un sistema basato su Content-Defined Chunking non è un dettaglio implementativo: è una scelta architetturale che determina il costo reale dello storage nel tempo. Prima di ottimizzare la rete o negoziare tariffe con il provider cloud, vale la pena verificare quale algoritmo di chunking stia usando il proprio tool di backup — e se sia configurato correttamente per il proprio workload.