RAID 1 protegge dalla corruzione?

Raid 1 protegge dalla corruzione dei dati? Ad esempio, supponiamo che sto conservando tutti i miei file importanti su un NAS che utilizza 2 dischi in un RAID 1. Se un disco rigido ha qualche tipo di problema interno e i dati vengono danneggiati, il RAID lo riconosce automaticamente e corregge usando i dati dall'altro buon disco?

Potrebbe anche sapere quale copia è quella buona?

RAID 5 protegge dalla corruzione?

So che RAID non è una soluzione di backup. Sto cercando di capire come assicurarmi di non eseguire il backup dei dati corrotti!

RAID-1 protegge dal guasto completo di una delle due unità. Se l'unità non è contrassegnata come guasta, si presume che il suo contenuto sia accurato. Ma se, per qualsiasi motivo, una delle due unità restituisse dati incoerenti, quell'errore non verrebbe rilevato dal sistema RAID e l'applicazione otterrebbe dati errati.

Molti controller hanno un processo di verifica che viene eseguito periodicamente, ma lo scopo è verificare l'errore del disco, non l'integrità dei dati. I dischi rigidi implementano i propri test e checksum di integrità dei dati che utilizzano per individuare settori danneggiati, ma l'algoritmo è progettato per essere veloce e compatto, non accurato, quindi possono fuoriuscire errori.

Mentre la corruzione dei dati è l'eccezione piuttosto che la regola, non è nemmeno inaudita. Un membro del team di ZFS, ad esempio, ha riferito in un'intervista di aver visto dati corrotti essere inviati loro dal loro dispositivo RAID-5 di fascia alta che hanno individuato in virtù del fatto che ZFS implementa checksum a quel livello del file system.

Dipende da dove proviene la corruzione. Se un'unità in un mirror RAID 1 è instabile e sta scrivendo delle sciocchezze, il mirror RAID si degraderà e l'unità in uso verrà utilizzata e avrai i file validi. Nel caso di RAID 5, questo viene fatto con 2 unità di dati e un'unità di parità (nella forma più semplice) e se una delle 3 unità non riesce a scrivere i file corretti, fallirà e rimarrai con 2 dati unità o 1 unità dati e un'unità di parità.

Ora vediamo cosa succede se la corruzione è causata da un virus o un bug in un programma. In RAID 1 e RAID 5 nessuna unità verrà messa fuori servizio perché le unità scrivono correttamente. Niente è fallito. Tuttavia, i file verranno distrutti perché il virus o il bug sta scrivendo spazzatura e lo scriverà su entrambe le unità in un mirror RAID 1 e su tutte e 3 le unità in un sistema RAID 5.

Ecco perché RAID non è un backup. Previene l'errore più probabile, ovvero un errore del disco, ma non tiene conto di molti altri scenari.

Come altri hanno già notato, un sistema raid1 non ha modo di dire quale dei due settori è danneggiato.

I sistemi di raid di fascia alta eseguono un'operazione di scrub in background per confrontare sia le copie che le differenze di flag. Meglio ancora è un sistema che legge entrambi i blocchi dall'unità ogni volta e li confronta al momento della lettura. Risolvere tali differenze è tuttavia impossibile per il controller dell'incursione.

Sui sistemi Unix con mdadm, è possibile avviare un controllo scrub con "sync_action":

Le md array possono essere cancellate scrivendo check o repair nel file md / sync_action nella directory sysfs per il dispositivo.

La richiesta di uno scrub farà sì che md legga ogni blocco su ogni dispositivo dell'array e verifichi che i dati siano coerenti. Per RAID1 e RAID10, ciò significa che le copie sono identiche. Per RAID4, RAID5, RAID6 questo significa verificare che il blocco di parità sia (o blocchi) corretti.

raid1 significa proteggere dall'improvviso guasto totale dell'unità. Cerca altrove la protezione dalla corruzione. Oltre a ciò, Raid1 non offre "cronologia", quindi non è possibile recuperare da errori umani o software. Cerca i filesystem come ZFS o una cronologia che preservi il filesystem come Hammer per proteggerti dalla corruzione.

In pratica si. La stragrande maggioranza dei guasti del disco rigido si verificano tutto o niente. (A) il cavo è scollegato o il microcontrollore dell'unità non è riuscito, quindi il controller RAID non riceve alcuna risposta - evidente unità guasta. Oppure (b) Il microcontrollore del cavo e dell'unità è buono, ma quando tenta di leggere un settore, il microcontrollore dell'unità interna rileva la corruzione dei dati perché il checksum ECC interno non è riuscito e ripetuti tentativi di leggere quel settore (nel caso si tratti di un problema di lettura temporaneo ) alla fine del timeout, quindi il controller RAID riceve una risposta "scusa" educata - evidente unità guasta. In entrambi i casi, è ovvio per il controller RAID-1 o RAID-5 che l'unità non funziona.

In linea di principio, no. Se qualcosa è andato così male che un disco rigido sta scrivendo sciocchezze, eppure in qualche modo funziona abbastanza bene da scrivere il codice ECC interno corretto per quella sciocchezza, allora RAID-1 non può dire quale unità è corretta. Il sistema RAID-1 probabilmente sovrascriverà i dati corretti con i dati corrotti su una risincronizzazione. RAID-5 non è migliore. L'interruzione dell'alimentazione "RAID-5 write hole" durante la scrittura attiva è un caso particolare raro ma non impossibile.

Per quanto ne so, l'unico modo per evitare tale corruzione è utilizzare checksum end-to-end oltre al mirroring dei file, automaticamente come parte del file system (ZFS o Btrfs) o periodicamente o manualmente (ricalcolo dei checksum rsync, semplice verifica dei file, set di file Parchive, ecc.); idealmente con un hash crittografico come SHA-256.