Perché i backup deduplicati sembrano più piccoli rispetto allo spazio occupato dal ripristino?
I backup deduplicati sembrano più piccoli perché i blocchi ripetuti vengono memorizzati una sola volta, mentre un ripristino ricostruisce ogni file logico e ogni copia indipendente.
Dieci immagini di macchine virtuali possono condividere gigabyte di blocchi identici del sistema operativo in un repository di backup. Il ripristino su un filesystem ordinario ricrea dieci spazi di indirizzamento, a meno che anche la destinazione non supporti la condivisione compatibile, la sparsità o la compressione. Le dimensioni del repository e la capacità necessaria per il ripristino descrivono quindi rappresentazioni diverse, con regole di allocazione e overhead differenti sul filesystem di destinazione selezionato in modo sicuro.
La deduplicazione memorizza l’identità una volta e la referenzia molte volte
Il software di backup suddivide i dati in blocchi, ne calcola le impronte digitali e memorizza solo quelli non ancora presenti. I manifesti conservano l’associazione tra blocchi, file e punti di ripristino. Il repository può rappresentare molte copie logiche con un unico contenuto fisico più i relativi riferimenti.
Una panoramica sulla deduplicazione dei backup spiega come le copie ridondanti vengano eliminate dallo storage di backup. Il risparmio dipende dai contenuti ripetuti, non semplicemente dal numero di file.
Il ripristino inverte questa mappatura. Ogni file riceve i propri byte nell’ordine corretto nella destinazione richiesta. Se la destinazione non supporta la condivisione dei blocchi, i blocchi ripetuti occupano nuovamente extent separati. La riduzione dei dati era una proprietà del repository, non una garanzia che ogni destinazione di ripristino rimanga altrettanto compatta.
Compressione, sparsità e metadati ampliano la differenza
La compressione riduce i byte memorizzati in base all’entropia dei contenuti. I file sparsi omettono lunghe regioni di zeri, ma un’opzione di ripristino potrebbe materializzare questi buchi. Le unità di allocazione, i checksum, gli attributi estesi e i metadati del filesystem aggiungono overhead alla destinazione che i riepiloghi del repository potrebbero escludere.
Una spiegazione dello storage distingue i file sparsi dalle dimensioni allocate: un file può indicare una lunghezza logica elevata consumando al contempo meno blocchi fisici. Gli strumenti di ripristino devono preservare esplicitamente i buchi per mantenere questo risparmio.
Può verificarsi anche il contrario. Una destinazione compressa o un clone copy-on-write può mantenere i dati ripristinati più piccoli delle loro dimensioni logiche. Non esiste un moltiplicatore universale per convertire i byte del repository in byte ripristinati, perché contano la rappresentazione, l’insieme di conservazione e il filesystem di destinazione.
Quando la deduplicazione non è la causa principale
La spiegazione non è valida quando un singolo file non duplicato si espande in modo imprevisto. In tal caso potrebbero prevalere la cifratura, i contenuti multimediali già compressi, i formati di esportazione dei database o una modifica del thin provisioning. Un catalogo di backup potrebbe inoltre mostrare solo i dati unici per un determinato ambito, mentre il ripristino include diverse snapshot selezionate.
Una discussione tecnica sul rapporto di deduplicazione sottolinea che le dimensioni logiche e fisiche devono essere distinte quando si riportano i rapporti di deduplicazione. I rapporti privi di ambito possono fuorviare la pianificazione della capacità.
Il meccanismo smette inoltre di essere applicabile se gli hash o il numero dei file ripristinati differiscono dal backup selezionato. In tal caso il problema riguarda la selezione o l’integrità, non un’espansione prevista. Dimensioni di backup inferiori non giustificano una sottostima dello spazio temporaneo prima della verifica.
Misura un ripristino invece di fidarti del rapporto
Scegli un insieme rappresentativo di dati da ripristinare e registra i byte logici di origine, i byte unici del repository, i byte compressi, gli extent sparsi, il numero di file e l’unità di allocazione della destinazione. Esegui il ripristino in una destinazione isolata usando sia le opzioni che preservano la sparsità sia quelle predefinite, quindi verifica gli hash e lo spazio allocato.
Utilizza un piano di storage con storage condiviso dei modelli, così la destinazione del test non potrà sottrarre risorse ai servizi attivi. Mantieni fisse la conservazione del repository e le impostazioni di compressione della destinazione durante il confronto delle esecuzioni.
Dimensiona il ripristino in base al valore maggiore tra l’output allocato misurato e le dimensioni logiche del dataset, aggiungendo un margine operativo, non in base al numero di byte del repository deduplicato. Se la preservazione della sparsità modifica il risultato, documenta questa dipendenza. Se cambiano l’identità o il numero dei file, interrompi il processo e risolvi i problemi di correttezza del ripristino prima di ottimizzare la capacità.
Prodotti consigliati
Hub Tecnologico e AI
Altro da leggere
Perché il calore dell’IA locale si percepisce diversamente su uno scaffale aperto rispetto a un mobile chiuso?
Traccia la generazione di calore, il ricambio d’aria e il ricircolo nelle configurazioni aperte e chiuse, quindi misura le variabili che le distinguono.
Perché un server domestico sembra più silenzioso di notte anche alla stessa velocità della ventola?
Scopri perché una velocità della ventola invariata non garantisce una rumorosità percepita invariata e come distinguere tra mascheramento, condizioni dell’ambiente e un reale cambiamento...
Perché l’utilizzo dello spazio di archiviazione appare diverso nell’interfaccia del NAS e nel file system?
Scopri cosa misura ciascun numero relativo allo spazio di archiviazione, perché i totali effettivi differiscono e come conciliare la capacità senza eliminare dati basandoti...
