Posted by Questo articolo è stato ispirato da una discussione avvenuta nel forum di Macrium sulla “robustezza” dei file di immagine di Macrium. Post originale al seguente indirizzo https://forum.macrium.com/Topic24929.aspx
I file di backup di Reflect sono robusti? Perché non viene utilizzata la correzione degli errori?
I file di backup Macrium hanno un rilevamento degli errori molto efficace ma non contengono alcuna capacità di correzione degli errori.
Questa è una decisione progettuale pragmatica sia per i file di backup Macrium sia per la maggior parte dei file system (NTFS non corregge o rileva errori presenti nei settori del disco). Il luogo più efficace per rilevare e correggere gli errori è il più vicino possibile al supporto di archiviazione sottostante. Gli errori di superficie tendono a verificarsi a raffica (“burst”) e per evitare questa sequenza superi il numero di errori di bit massimi che lo schema di correzione degli errori può risolvere, i dati di un settore sono sparpagliati su altri settori (“interleaving”). Questa operazione può essere effettuata in modo efficace solo dal firmware del disco poiché la vera posizione dei dati viene occultata dal firmware stesso. Anche i protocolli di comunicazione come ADSL e DVB utilizzano l'”interleaving” per superare i “bust” di errore.
Abbiamo condotto uno studio sull’uso della codifica RS per aumentare la robustezza dei file Macrium. Tuttavia, risulta che la correzione degli errori del firmware del disco è così efficace che, in genere, una volta che la correzione degli errori non riesce per un settore, si è vicini a un errore generale o una percentuale significativa del disco diventa illeggibile; in altre parole, quando un disco inizia a segnalare errori, esiste un’alta probabilità che l’intero file di backup o una grande porzione siano irrecuperabili. Inoltre, come precedentemente evidenziato, la mancanza di spazio di archiviazione all’esterno del dispositivo riduce gravemente l’efficacia di qualsiasi correzione degli errori da parte del sistema operativo a o da parte di una applicazione. In sintesi, l’aggiunta della correzione degli errori renderebbe i backup ed i ripristini più impegnativi per la CPU e si otterrebbero file di backup più grandi offrendo solo un miglioramento illusorio della loro robustezza.
Quanti errori di bit non corretti possono essere rilevati prima che i dati di backup siano compromessi.
La stragrande maggioranza di un file di backup contiene i dati dal sistema di backup. Un piccolo errore in quella parte del file avrà un impatto solo su quella parte dei dati ripristinati. Tuttavia un piccolo errore nel file dei meta-dati potrebbe essere più generale.
Non utilizzare la compressione al momento del backup riduce il rischio?
L’uso della compressione può effettivamente ridurre il rischio poiché, riducendo il numero di settori utilizzati nella memorizzazione del file, si riduce la possibilità che uno di questi settori non funzioni. Il file è segmentato in modo tale che un errore di bit abbia solo effetto su un singolo blocco di dati e non sull’intero file. Inoltre, sebbene la compressione aumenti l’impatto di un errore di un singlo bit, a causa dell’effetto della correzione dell’errore del firmware del disco, questo non restituisce mai un errore per un singolo bit ma, o gli errori del settore sono interamente corretti, o risulterà illeggibile l’intero settore.
Che dire della divisione del file di backup su più dispositivi?
Ciò comporterebbe un reale miglioramento della “robustezza” contro la perdita dei dati. Tuttavia, rappresenterebbe una re-invenzione poco flessibile e limitata dei comuni sistemi di memorizzazione RAID nati prorpio per diminuire il rischio di perdita di dati in caso di guasto di un disco.
In conclusione
L’implementazione della correzione degli errori per i file di backup Macrium risulterebbe inefficace perché è troppo distante dal supporto di archiviazione sottostante.
Il metodo più efficace per proteggere i file di backup è la replica su più di un dispositivo, meglio se conservati in luoghi diversi. Il rilevamento degli errori è comunque sempre fondamentale per avvisare di utilizzare il percorso alternativo di backup.
Aggiungiamo come suggerimento, dato che la durata del processo di backup è direttamente proporziale alla banda disponibile verso l’unità di backup, di effettuare il primo backup su un disposivo locale che ne garantisca una elevata veocità di esecuzione e, successivamente, replicare il file di backup su un dispositivo remoto sfruttando magari la funzione di sincronizzazione remota offerta dalla stessa console di amministrazione gratuita “Macrium Site Manager” come spiegato nel seguente articolo “remote-repository-sync-con-macrium-site-manager”