In che modo il chunking basato sul contenuto riduce i dati di backup duplicati?

Il chunking definito dal contenuto migliora la deduplicazione dei backup scegliendo i confini dei chunk in base al contenuto dei file, consentendo alle regioni invariate di rimanere riutilizzabili dopo inserimenti o eliminazioni.

I backup incrementali contengono spesso file di grandi dimensioni che rimangono in gran parte invariati tra una versione e l'altra: immagini di dischi virtuali, archivi di posta, database copiati come file, pacchetti di progetti e librerie multimediali esportate. Se ogni chunk inizia a un offset di byte fisso, l'inserimento di una piccola intestazione all'inizio può spostare ogni confine successivo, anche se i byte seguenti sono identici. Il chunking definito dal contenuto fa sì che la segmentazione segua i pattern locali dei byte invece delle posizioni assolute, così il backup può riallinearsi ai vecchi chunk dopo la regione modificata.

I confini di dimensione fissa possono trasformare una piccola modifica in molti nuovi chunk

Un chunker a dimensione fissa suddivide i dati in posizioni come ogni 1 MiB, indipendentemente dal contenuto dei byte. Quando i byte vengono inseriti vicino all'inizio, i flussi vecchio e nuovo risultano sfalsati, quindi ogni chunk fisso successivo contiene una combinazione diversa di byte, anche se quasi tutto il contenuto sottostante è rimasto invariato.

Il chunking definito dal contenuto è stato sviluppato per la deduplicazione perché i punti di taglio derivati dal contenuto rilevano ridondanze che gli offset fissi possono non individuare dopo modifiche locali. Il vantaggio non consiste nel prevedere quali file siano simili; il CDC fornisce al deduplicatore una segmentazione in grado di tollerare lo spostamento delle posizioni.

Se un intero file viene sostituito con byte non correlati, nessun algoritmo di chunking può creare contenuti duplicati dal nulla. Il CDC è più utile quando le versioni condividono ampie regioni di byte invariati, ma tali regioni si sono spostate rispetto all'inizio del file.

Un'impronta mobile cerca punti di taglio locali nel flusso di byte

Il CDC sposta una finestra sull'input e aggiorna un'impronta mentre i byte entrano ed escono dalla finestra. Viene dichiarato un confine quando l'impronta soddisfa una condizione configurata, nel rispetto di regole sulla dimensione minima e massima dei chunk che impediscono la creazione di chunk patologicamente piccoli o grandi.

Il chunker di Borg usa un'impronta mobile del contenuto, così il costo di valutazione del confine candidato successivo non richiede di calcolare nuovamente l'hash dell'intera finestra. Poiché l'impronta dipende dai byte vicini, la stessa sequenza locale può attivare lo stesso punto di taglio anche quando il suo offset assoluto nel file è cambiato.

L'impronta mobile è quindi un meccanismo per trovare i confini, non l'identità finale dei dati di backup memorizzati. Trattare questi due hash come intercambiabili renderebbe meno chiara la spiegazione di dove venga effettivamente decisa la riutilizzabilità nella deduplicazione.

Anche le dimensioni minima, massima e media dei chunk influenzano la ricerca dei confini. Controllano la frequenza con cui vengono valutati i punti di taglio candidati e la quantità di metadati che il repository deve gestire.

Il CDC si riallinea dopo una modifica invece di rimanere sfalsato per sempre

Dopo un inserimento o un'eliminazione, la finestra mobile vede inizialmente byte diversi e produce confini differenti intorno alla modifica. Quando entra completamente in una regione sufficientemente lunga e invariata, può incontrare gli stessi pattern di contenuto locali e riprendere a creare tagli in posizioni allineate con la versione precedente.

Borg osserva che i confini definiti dal contenuto possono rimanere stabili rispetto al contenuto invariato anche quando altrove vengono inseriti o rimossi byte. È questo riallineamento a confinare molte modifiche a un numero ridotto di nuovi chunk, invece di invalidare il resto del file.

Anche Restic suddivide i file in blob di lunghezza variabile usando un'impronta scorrevole, così i blob invariati di lunghezza variabile possono essere nuovamente referenziati tra gli snapshot. Il repository necessita comunque di un indice per riconoscere i blob già memorizzati.

La distanza di riallineamento dipende dai parametri di chunking e dal pattern dei byte modificati, quindi il CDC non garantisce che per ogni modifica compaia esattamente un nuovo chunk. Il suo vantaggio è la località statistica: è meno probabile che le modifiche spostino ogni confine successivo.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

$799.00 - $2,499.00

Buy Now

Un identificatore robusto del chunk decide il riutilizzo dopo la scelta del confine

Individuare un confine risponde solo alla domanda su dove termini un chunk candidato; il repository deve ancora decidere se il contenuto completo del chunk esista già. Questa seconda decisione usa un identificatore del contenuto più robusto o un hash autenticato calcolato sul chunk completo, quindi lo cerca nell'indice del repository.

Borg separa esplicitamente l'hash utilizzato per il confine dall'identità crittografica del chunk usata come criterio di deduplicazione. Allo stesso modo, Restic identifica i blob memorizzati tramite un hash forte del contenuto, invece di trattare l'impronta mobile come prova che due chunk siano identici.

Questo design a due fasi chiarisce il flusso di archiviazione: l'hash mobile sceglie la segmentazione candidata; l'hash del contenuto identifica il chunk risultante; la ricerca nel repository decide se memorizzarlo o riutilizzarlo. Il risparmio di spazio avviene solo nelle ultime due fasi, anche se il CDC rende molto più probabile che queste corrispondenze sopravvivano alle modifiche.

La dimensione dei chunk e la trasformazione dei dati definiscono il compromesso tra calcolo e risparmio

Chunk medi più piccoli isolano le modifiche con maggiore precisione, ma aumentano il numero di impronte, voci dell'indice, ricerche, oggetti di metadati e riferimenti di archiviazione. Chunk più grandi riducono il sovraccarico dell'indicizzazione, ma consentono a una piccola modifica di invalidare un'unità più grande di dati riutilizzabili.

FastCDC punta a ridurre il sovraccarico della CPU per l'hash mobile mantenendo una forte capacità di rilevamento delle ridondanze, dimostrando che il chunking può diventare un costo significativo prima ancora che vengano eliminati byte duplicati. I parametri migliori bilanciano il lavoro di chunking, le dimensioni dell'indice e il pattern di similarità dell'insieme di backup.

La trasformazione prima del chunking può inoltre eliminare la similarità tra byte da cui dipende il CDC. La crittografia con nonce diversi, i formati che riscrivono gran parte di un file dopo una piccola modifica logica o alcuni schemi di compressione possono far apparire non correlate a livello di byte due versioni logicamente simili.

L'analisi di ZimaSpace sul sovraccarico della memoria dell'indice di deduplicazione esamina l'altro lato di questo compromesso: un riutilizzo più preciso richiede più metadati e memoria per tenere traccia di ciò che esiste già. Il CDC è utile quando lo spazio di archiviazione recuperato supera il costo aggiuntivo del chunking e dell'indice, non semplicemente perché i chunk di dimensione variabile sembrano più sofisticati.