RAID-5: due dischi sono falliti contemporaneamente?

Abbiamo un server Dell PowerEdge T410 in esecuzione CentOS, con una matrix RAID-5 contenente 5 dischi SATA Seagate Barracuda 3 TB. Ieri il sistema si è schiantato (non so esattamente e non ho log).

Al momento dell'avvio del BIOS del controller RAID, ho visto che nei 5 dischi il disco 1 è stato contrassegnato come "mancante" e il disco 3 è stato contrassegnato come "degradato". Ho forzato il disco 3 in su e sostituito il disco 1 con un nuovo disco rigido (della stessa dimensione). Il BIOS ha rilevato questo problema e ha iniziato a ribuild il disco 1 – tuttavia è rimasto bloccato a% 1. L'indicatore di spinning non è passato tutta la notte; totalmente congelati.

quali sono le mie opzioni? C'è qualche modo per tentare di ribuild, oltre a utilizzare un servizio professionale di recupero dati? Come potrebbe due dischi rigidi fallire contemporaneamente? Sembra troppo coincidente. È ansible che il disco 1 non sia riuscito, e di conseguenza il disco 3 "non sia stato sincronizzato?" In caso affermativo, ci sono utilità che posso utilizzare per ripristinarlo in sincronia?

9 Solutions collect form web for “RAID-5: due dischi sono falliti contemporaneamente?”

Avete un doppio errore del disco. Ciò significa che i tuoi dati sono spariti e dovrai ripristinare da un backup. Questo è il motivo per cui non dovremmo utilizzare raid 5 su grandi dischi. Volete impostare il tuo raid in modo da avere sempre la capacità di sopportre due errori di disco, in particolare con i grandi dischi lenti.

Le tue opzioni sono:

  1. Ripristino dai backup.
    • Hai dei backup, vero? RAID non è un backup.
  2. Recupero dati professionali
    • È ansible, anche se molto costoso e non garantito, che un servizio di recupero professionale potrà recuperare i tuoi dati.
  3. Accettare la tua perdita di dati e imparare dall'esperienza.
    • Come indicato nei commenti, i dischi SATA di grandi size non sono raccomandati per una configuration RAID 5 a causa della possibilità di un doppio errore durante la ricostruzione causando l'errore dell'arrays.
      • Se deve essere RAID di parità, RAID 6 è migliore e la prossima volta utilizzare anche un ricambio caldo.
      • I dischi SAS sono migliori per una serie di motivi, tra cui più affidabilità, resilienza e minori tassi di errori di bit non recuperabili che possono causare URE (errori di lettura non recuperabili)
    • Come detto sopra, RAID non è un backup. Se i dati sono importnti, assicurati che sia eseguito il backup e che i tuoi backup siano testati di ripristino.

Dopo aver accettato una brutta risposta, mi dispiace veramente per il mio parere eretico (che ha già salvato tali arrays già più volte).

Il secondo disco fallito ha probabilmente un problema minore, forse un guasto di block. Questa è la causa, perché l'attrezzo cattivo di sincronizzazione del tuo software firmato raid5 è stato bloccato.

Puoi facilmente creare una copia a livello di settore con uno strumento di clonazione a disco a basso livello (ad esempio, è probabilmente molto utile il gddrescue ) e utilizzare questo disco come nuovo disco3. In questo caso, la tua matrix è sopravvissuta con una minore danneggiamento dei dati.

Mi dispiace, probabilmente è troppo tardi, perché l'essenza della risposta ortodossa in questo caso: "il fallimento multiplo in un raid5, ecco l'apocalisse!"

Se si desidera un ottimo attacco ridondante, utilizzare raid software in Linux. Ad esempio, il suo raid superblock data layout è pubblico e documentato … mi dispiace veramente, per la mia altra opinione eretica.

Un errore simultaneo è ansible, anche probabile, per i motivi che altri hanno dato. L'altra possibilità è che uno dei dischi fosse fallito un po 'di tempo prima e non l'avevi triggersmente controllato.

Assicurarsi che il tuo monitoraggio richieda tempestivamente un volume RAID in modalità degradata. Forse non hai avuto un'opzione, ma non è mai bello wherer imparare queste cose dal BIOS.

Per rispondere "Come potrebbe due dischi rigidi fallire contemporaneamente?" esattamente, vorrei citare da questo articolo :

Il punto cruciale dell'argomento è questo. Poiché le unità disco sono diventate più grandi e grandi (circa raddoublendo in due anni), l'URE (errore di lettura non recuperabile) non è migliorato allo stesso tasso. URE misura la frequenza di un errore di lettura irrecuperabile e viene misurato in genere per errori per bit letto. Ad esempio, un tasso URE di 1E-14 (10 ^ -14) implica che un errore di lettura irrecuperabile si verifichi una volta each bit di 1E14 letto (1E14 bit = 1.25E13 byte o circa 12TB).

L'argomento è che quando le capacità del disco crescono e il tasso URE non migliora allo stesso tasso, la possibilità di un fallimento di RAID5 ricostruzione aumenta nel tempo. Statisticamente dimostra che nel 2009 le capacità dei dischi sarebbero cresciute abbastanza per rendere inutile utilizzare RAID5 per qualsiasi matrix significativa.

Quindi, nel 2009 RAID5 era in pericolo. Anche il RAID6 sarà presto. Quanto a RAID1, ho iniziato a farli su tre dischi. RAID10 con 4 dischi è anche precario.

Tipicamente quando si acquista unità in un sacco da un rivenditore stimabile, è ansible richiedere che le unità provengano da batch diversi, che è importnte per i motivi di cui sopra. Avanti, è proprio per questo che esiste RAID 1 + 0. Se aveste utilizzato 6 unità in RAID 1 + 0 avreste avuto 9TB di dati con ridondanza immediata in cui non è necessaria alcuna ricostruzione di un volume.

Se il controller è riconosciuto da dmraid (ad esempio qui ) su Linux, potrebbe essere ansible utilizzare ddrescue per recuperare il disco fallito in un nuovo e utilizzare dmraid per creare l'arrays, anziché il controller hardware.

La discussione è vecchia ma se stai leggendo, capisci quando un'unità non riesce in un arrays di raid, controlla l'età delle unità. Se si dispone di più dischi in un raid arrays e hanno più di 4-5 anni, le probabilità sono buone che un'altra unità non riesca. *** FACCIAMO UN IMMAGINE o il backup ** prima di procedere. Se pensi di avere un backup, prova a verificare che sia ansible leggerlo e ripristinarlo.

La ragione è che stai mettendo anni di usura normale sulle unità rimanenti mentre spinano la piena velocità per ore e ore. Maggiore è il numero di azionamenti di 6 anni, la maggiore probabilità che un altro azionista fallisca dallo stress. Se si tratta di RAID5 e si esegue l'esplosione, è necessario avere un backup, ma un disco da 2 TB richiede 8 – 36 ore per ripristinare in base al tipo di controller di raid e di altri componenti hardware.

Riponiamo regolarmente l'intera nave di raid sui server di produzione se tutti i drive sono vecchi. Perché era tempo di sostituire un'unità, quindi attendere che il successivo non riesca in un giorno, una settimana, un mese o due. Come scarabocchi come azionamenti, la sua semplicemente non vale la pena.

È ansible ribuild l'arrays ma solo una volta. LEGGETTO, salva i tuoi dati e fai attenzione per il futuro che ho fatto per HP Storage MSA, quindi penso che questa opzione abbia anche su altri dispositivi NAS, quindi vale la pena farlo: questo è il command magico e le informazioni su come riportre la tua matrix alla vita:

Login: manage Password: ******* HP StorageWorks MSA2012i System Name: External 7TB System Location: Server 7TB Version: W421R37 # show vdisk Name Size Free Own RAID Dsk Spr Chk Stat Jobs Serial# ----------------------------------------------------------------------------- BIGFOOT 7001.3GB 393.2KB A RAID5 8 0 64 OFFL 00c0ffd5e923000023fb344900000000 ----------------------------------------------------------------------------- # trust enable bigfoot Error: The command has an invalid parameter or unreceachzed parameter # show vdisk Name Size Free Own RAID Dsk Spr Chk Stat Jobs Serial# ----------------------------------------------------------------------------- BIGFOOT 7001.3GB 393.2KB A RAID5 8 0 64 OFFL 00c0ffd5e923000023fb344900000000 ----------------------------------------------------------------------------- # trust enable Success: Command completed successfully # trust vdisk bigfoot Success: Command completed successfully # show vdisk Name Size Free Own RAID Dsk Spr Chk Stat Jobs Serial# ----------------------------------------------------------------------------- BIGFOOT 7001.3GB 393.2KB A RAID5 8 0 64 OFFL 00c0ffd5e923000023fb344900000000 ----------------------------------------------------------------------------- # trust vdisk bigfoot Success: Command completed successfully # help trust DESCRIPTION Enables an offline virtual disk to be brought online for emergency data collection only. It must be enabled before each use. Caution: This command can cause unstable operation and data loss if used improperly. It is intended for disaster recovery only. The trust command resynchronizes the time and date stamp and any other metadata on a bad disk drive. This makes the disk drive an active member of the virtual disk again. You might need to do this when: - One or more disks of a virtual disk start up more slowly or were powered on after the rest of the disks in the virtual disk. This causes the date and time stamps to differ, which the system interprets as a problem with the "late" disks. In this case, the virtual disk functions normally after being trusted. - A virtual disk is offline because a drive is failing, you have no data backup, and you want to try to recover the data from the virtual disk. In this case, trust may work, but only as long as the failing drive continues to operate. When the "trusted" virtual disk is back online, back up its data and audit the data to make sure that it is intact. Then delete that virtual disk, create a new virtual disk, and restore data from the backup to the new virtual disk. Using a trusted virtual disk is only a disaster-recovery measure; the virtual disk has no tolerance for any additional failures. INPUT trust enable trust vdisk <vdisk> enable Enables the trust command before use. vdisk <vdisk> Specifies the virtual disk by name or serial number. For the syntax to use, type "help syntax". EXAMPLE Enable the trust command and then trust virtual disk VD1. # trust enable Trust Virtual-disk Enabled. # trust vdisk VD1 Are you sure? yes Virtual-disk VD1 has been trusted. Success: Command completed successfully # show vdisk Name Size Free Own RAID Dsk Spr Chk Stat Jobs Serial# ----------------------------------------------------------------------------- BIGFOOT 7001.3GB 393.2KB A RAID5 8 0 64 OFFL 00c0ffd5e923000023fb344900000000 ----------------------------------------------------------------------------- # trust vdisk BIGFOOT Success: Command successful on local controller, but other controller is not up # show vdisk Name Size Free Own RAID Dsk Spr Chk Stat Jobs Serial# ----------------------------------------------------------------------------- BIGFOOT 7001.3GB 393.2KB A RAID5 8 0 64 FTOL 00c0ffd5e923000023fb344900000000 ----------------------------------------------------------------------------- 
Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.