In che modo la dimensione dei blocchi di backup influisce sulla velocità di ripristino e sui risparmi derivanti dalla deduplicazione?

Blocchi di backup più piccoli migliorano solitamente il risparmio ottenuto dalla deduplicazione, mentre blocchi più grandi riducono i metadati e spesso rendono i ripristini più sequenziali e prevedibili.

Consideriamo un server domestico che protegge immagini di macchine virtuali, foto di famiglia e documenti modificati frequentemente su un unico array di dischi. Suddividere ogni flusso in parti minuscole individua più regioni ripetute, ma crea anche più hash, voci di indice e letture sparse durante il ripristino. Parti più grandi semplificano la ricostruzione, ma individuano meno somiglianze di piccole dimensioni; pertanto, la dimensione migliore dipende dal tipo di dati e dal percorso di ripristino, non da un obiettivo universale di risparmio dello spazio di archiviazione.

La dimensione dei blocchi stabilisce la granularità del rilevamento dei duplicati

Un backup con deduplicazione memorizza un blocco una sola volta e sostituisce le copie successive con riferimenti alla stessa impronta digitale. Se una piccola modifica si trova all’interno di un blocco fisso molto grande, l’intero blocco può apparire nuovo. Blocchi più piccoli isolano la regione modificata, consentendo alle aree circostanti invariate di corrispondere ai backup precedenti e aumentando la quantità di dati che può essere referenziata anziché memorizzata nuovamente.

I blocchi più piccoli generalmente producono una deduplicazione migliore perché confrontano i dati a una granularità più fine, una relazione analizzata nel backup di file basato su blocchi. Il meccanismo non è una compressione magica. Ogni confine aggiuntivo crea un’altra possibilità di isolare byte ripetuti, soprattutto tra documenti versionati, immagini di macchine virtuali e archivi software con piccole modifiche interne.

Questo vantaggio presenta rendimenti decrescenti. Dimezzare la dimensione media dei blocchi raddoppia approssimativamente il numero di record dei blocchi per lo stesso volume di dati logici, aumentando il calcolo delle impronte digitali, la memoria dell’indice, i manifest e il lavoro di ricerca. Un numero maggiore di blocchi consente di risparmiare capacità solo quando il dataset contiene sottoaree riutilizzabili; foto già compresse e archivi cifrati spesso offrono poca deduplicazione aggiuntiva rispetto ai metadati extra.

I confini definiti dal contenuto proteggono il risparmio quando i byte si spostano

La suddivisione a dimensione fissa taglia agli offset dei byte, quindi l’inserimento di pochi byte vicino all’inizio sposta tutti i confini successivi e può far apparire interamente nuovo un file altrimenti simile. La suddivisione definita dal contenuto sceglie i confini in base al flusso di byte stesso. Dopo un inserimento locale, i punti di riferimento successivi possono riallinearsi, consentendo al contenuto seguente di corrispondere ai blocchi già memorizzati.

La suddivisione definita dal contenuto risolve il problema dello spostamento dei confini, ma richiede comunque tempo di CPU per individuarli. Questo è importante perché “blocchi da 8 MB” descrive una dimensione media obiettivo in molti sistemi CDC, non parti identiche. I limiti minimo, medio e massimo influenzano sia la probabilità di corrispondenza sia il sovraccarico di elaborazione, mentre l’algoritmo scelto determina quanta potenza di calcolo consuma la ricerca dei confini.

Il metodo di suddivisione può quindi essere importante quanto la dimensione nominale. Un flusso CDC di dimensioni moderate può conservare somiglianze che blocchi fissi più piccoli perdono dopo gli inserimenti, producendo al contempo meno record. Tuttavia, la CDC non rende deduplicabili in modo efficace i dati ad alta entropia o cifrati: la modifica di un blocco di testo cifrato può alterare ampie regioni, mentre la compressione rimuove intenzionalmente i pattern ripetuti prima che il motore di backup li analizzi.

La velocità di ripristino dipende dalla località, non solo dal numero di blocchi

Un ripristino legge i blocchi referenziati nell’ordine necessario a ricostruire i file. Se tali blocchi sono distribuiti tra molti contenitori e dischi, il sistema può eseguire piccole letture casuali anziché trasferimenti sequenziali prolungati. I blocchi minuscoli aumentano il numero di riferimenti, ma il rallentamento reale si verifica quando la loro posizione fisica diverge dall’ordine di ripristino e i mancati riscontri nella cache obbligano a recuperare ripetutamente i contenitori.

La frammentazione può ridurre drasticamente il throughput di ripristino nel corso della vita di un repository, come dimostrano le misurazioni della velocità di ripristino con deduplicazione. Le tecniche di mitigazione possono sacrificare parte della deduplicazione o aggiungere lavoro di assemblaggio per migliorare la località del ripristino. Questo separa la granularità dei blocchi dalla loro disposizione: due repository con un numero simile di blocchi possono avere velocità di ripristino molto diverse se uno raggruppa i blocchi correlati.

I blocchi più grandi spesso migliorano la località perché ogni riferimento recupera una quantità maggiore di dati contigui utili e i manifest contengono meno oggetti. Tuttavia, più grande non significa automaticamente più veloce. Se un ripristino richiede solo un file piccolo o un intervallo limitato, un contenitore compresso di grandi dimensioni può causare amplificazione delle letture; sugli SSD veloci, la decompressione e il calcolo degli hash possono diventare più importanti del tempo di ricerca. Le prestazioni di ripristino comprendono l’intera pipeline di ricerca, lettura, verifica, decompressione e scrittura.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

$799.00 - $2,499.00

Buy Now

La pressione su indice e cache crea una via di mezzo spesso trascurata

I blocchi piccoli richiedono un indice delle impronte digitali più grande, che su un server domestico modesto può fuoriuscire dalla RAM e finire sull’archiviazione. Quando l’indice non rientra più nella cache prevista, l’acquisizione del backup e le ricerche durante il ripristino competono con i dati dei file per l’I/O. I blocchi grandi riducono le dimensioni dell’indice ma diminuiscono le opportunità di corrispondenza, creando una fascia intermedia in cui i metadati restano nella cache senza sacrificare le regioni duplicate più comuni.

La CDC vettorializzata può aumentare notevolmente il throughput della suddivisione in blocchi, preservando gran parte del risparmio di spazio. Questo risultato evidenzia una variabile spesso trascurata nei test domestici: l’implementazione dell’algoritmo. Modificare contemporaneamente la dimensione dei blocchi e il suddivisore impedisce di arrivare a una conclusione chiara, perché l’individuazione più rapida dei confini può nascondere il costo in CPU di una granularità più fine.

Gli hash dei contenuti sono utili anche oltre l’archiviazione dei backup. La guida di ZimaSpace sull’hashing dei contenuti mostra lo stesso principio delle impronte digitali utilizzato per saltare i materiali RAG invariati. In entrambi i flussi di lavoro, i metadati devono rimanere più economici da memorizzare e interrogare rispetto al lavoro che consentono di evitare; altrimenti, un tracciamento più dettagliato diventa un sovraccarico anziché un risparmio.

Valuta la dimensione dei blocchi con una matrice di test che dia priorità al ripristino

Crea un dataset rappresentativo con tre classi: documenti versionati o immagini di macchine virtuali, contenuti multimediali compressi e numerosi file piccoli. Esegui almeno tre profili di suddivisione mantenendo costanti compressione, cifratura, anzianità del repository, hardware di archiviazione e concorrenza. Registra i byte fisici scritti, il numero di blocchi, la memoria massima utilizzata dall’indice, il throughput del backup e il throughput del ripristino completo, invece di valutare soltanto il rapporto di deduplicazione visualizzato.

Le prestazioni di ripristino devono essere considerate un risultato di primaria importanza, senza presumere che la deduplicazione massima sia ottimale. Lo schema di eliminazione della ridondanza consapevole della frammentazione utilizza informazioni sulla disposizione dei blocchi per analizzare il comportamento del ripristino. Ripeti il test domestico dopo diverse generazioni incrementali, perché un repository appena creato può sembrare sequenziale, mentre mesi di riferimenti incrociati tra backup rivelano il reale costo del ripristino.

Seleziona il profilo più piccolo il cui tempo di ripristino rientra ancora nell’obiettivo di recupero e il cui indice rimane comodamente entro la memoria disponibile durante l’esecuzione peggiore. Se due profili rispettano questi limiti, preferisci quello con meno blocchi e operazioni più semplici. Ripeti il test dopo aver modificato la cifratura del repository, la dimensione dei pacchetti, il tipo di disco o la composizione del carico di lavoro; la dimensione media dei blocchi è una variabile di ottimizzazione, non una misura permanente della qualità del backup.