Come recuperare un array RAID md RAID5 in crash?

17

Qualche tempo fa avevo un sistema RAID5 a casa. Uno dei 4 dischi non è riuscito, ma dopo averlo rimosso e rimesso sembrava che fosse OK, quindi ho avviato una risincronizzazione. Alla fine mi sono reso conto, con mio orrore, che 3 dischi su 4 hanno fallito. Tuttavia non credo che sia possibile. Esistono più partizioni sui dischi ogni parte di un diverso array RAID.

  • md0 è un array RAID1 composto da sda1, sdb1, sdc1 e sdd1.
  • md1 è un array RAID5 composto da sda2, sdb2, sdc2 e sdd2.
  • md2 è un array RAID0 composto da sda3, sdb3, sdc3 e sdd3.

md0 e md2 riportano tutti i dischi attivi mentre md1 riporta 3 falliti (sdb2, sdc2, sdd2). Ho capito che quando i dischi rigidi si guastano, tutte le partizioni vanno perse, non solo quelle centrali.

A quel punto ho spento il computer e ho scollegato le unità. Da allora stavo usando quel computer con un nuovo disco più piccolo.

C'è qualche speranza di recuperare i dati? Posso in qualche modo convincere mdadm che i miei dischi funzionano davvero? L'unico disco che può davvero avere un problema è sdc ma anche quello è segnalato dagli altri array.

Aggiornare

Ho finalmente avuto la possibilità di collegare i vecchi dischi e avviare questa macchina da SystemRescueCd. Tutto quanto sopra è stato scritto dalla memoria. Ora ho alcuni dati concreti. Ecco l'output dimdadm --examine /dev/sd*2

/dev/sda2:
          Magic : a92b4efc
        Version : 0.90.00
           UUID : 53eb7711:5b290125:db4a62ac:7770c5ea
  Creation Time : Sun May 30 21:48:55 2010
     Raid Level : raid5
  Used Dev Size : 625064960 (596.11 GiB 640.07 GB)
     Array Size : 1875194880 (1788.33 GiB 1920.20 GB)
   Raid Devices : 4
  Total Devices : 4
Preferred Minor : 1

    Update Time : Mon Aug 23 11:40:48 2010
          State : clean
 Active Devices : 3
Working Devices : 4
 Failed Devices : 1
  Spare Devices : 1
       Checksum : 68b48835 - correct
         Events : 53204

         Layout : left-symmetric
     Chunk Size : 64K

      Number   Major   Minor   RaidDevice State
this     0       8        2        0      active sync   /dev/sda2

   0     0       8        2        0      active sync   /dev/sda2
   1     1       8       18        1      active sync   /dev/sdb2
   2     2       8       34        2      active sync   /dev/sdc2
   3     3       0        0        3      faulty removed
   4     4       8       50        4      spare   /dev/sdd2
/dev/sdb2:
          Magic : a92b4efc
        Version : 0.90.00
           UUID : 53eb7711:5b290125:db4a62ac:7770c5ea
  Creation Time : Sun May 30 21:48:55 2010
     Raid Level : raid5
  Used Dev Size : 625064960 (596.11 GiB 640.07 GB)
     Array Size : 1875194880 (1788.33 GiB 1920.20 GB)
   Raid Devices : 4
  Total Devices : 4
Preferred Minor : 1

    Update Time : Mon Aug 23 11:44:54 2010
          State : clean
 Active Devices : 2
Working Devices : 3
 Failed Devices : 1
  Spare Devices : 1
       Checksum : 68b4894a - correct
         Events : 53205

         Layout : left-symmetric
     Chunk Size : 64K

      Number   Major   Minor   RaidDevice State
this     1       8       18        1      active sync   /dev/sdb2

   0     0       0        0        0      removed
   1     1       8       18        1      active sync   /dev/sdb2
   2     2       8       34        2      active sync   /dev/sdc2
   3     3       0        0        3      faulty removed
   4     4       8       50        4      spare   /dev/sdd2
/dev/sdc2:
          Magic : a92b4efc
        Version : 0.90.00
           UUID : 53eb7711:5b290125:db4a62ac:7770c5ea
  Creation Time : Sun May 30 21:48:55 2010
     Raid Level : raid5
  Used Dev Size : 625064960 (596.11 GiB 640.07 GB)
     Array Size : 1875194880 (1788.33 GiB 1920.20 GB)
   Raid Devices : 4
  Total Devices : 4
Preferred Minor : 1

    Update Time : Mon Aug 23 11:44:54 2010
          State : clean
 Active Devices : 1
Working Devices : 2
 Failed Devices : 2
  Spare Devices : 1
       Checksum : 68b48975 - correct
         Events : 53210

         Layout : left-symmetric
     Chunk Size : 64K

      Number   Major   Minor   RaidDevice State
this     2       8       34        2      active sync   /dev/sdc2

   0     0       0        0        0      removed
   1     1       0        0        1      faulty removed
   2     2       8       34        2      active sync   /dev/sdc2
   3     3       0        0        3      faulty removed
   4     4       8       50        4      spare   /dev/sdd2
/dev/sdd2:
          Magic : a92b4efc
        Version : 0.90.00
           UUID : 53eb7711:5b290125:db4a62ac:7770c5ea
  Creation Time : Sun May 30 21:48:55 2010
     Raid Level : raid5
  Used Dev Size : 625064960 (596.11 GiB 640.07 GB)
     Array Size : 1875194880 (1788.33 GiB 1920.20 GB)
   Raid Devices : 4
  Total Devices : 4
Preferred Minor : 1

    Update Time : Mon Aug 23 11:44:54 2010
          State : clean
 Active Devices : 1
Working Devices : 2
 Failed Devices : 2
  Spare Devices : 1
       Checksum : 68b48983 - correct
         Events : 53210

         Layout : left-symmetric
     Chunk Size : 64K

      Number   Major   Minor   RaidDevice State
this     4       8       50        4      spare   /dev/sdd2

   0     0       0        0        0      removed
   1     1       0        0        1      faulty removed
   2     2       8       34        2      active sync   /dev/sdc2
   3     3       0        0        3      faulty removed
   4     4       8       50        4      spare   /dev/sdd2

Sembra che le cose siano cambiate dall'ultimo avvio. Se sto leggendo correttamente sda2, sdb2 e sdc2 funzionano e contengono dati sincronizzati e sdd2 è di riserva. Ricordo distintamente di aver visto 3 dischi guasti ma questa è una buona notizia. Tuttavia l'array continua a non funzionare:

Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
md125 : inactive sda2[0](S) sdb2[1](S) sdc2[2](S)
      1875194880 blocks

md126 : inactive sdd2[4](S)
      625064960 blocks

md127 : active raid1 sda1[0] sdd1[3] sdc1[2] sdb1[1]
      64128 blocks [4/4] [UUUU]

unused devices: <none>

md0 sembra essere stato rinominato in md127. md125 e md126 sono molto strani. Dovrebbero essere un array non due. Si chiamava md1. md2 è completamente sparito ma quello è stato il mio scambio quindi non mi interessa.

Riesco a capire i diversi nomi e non importa. Ma perché un array con 3 dischi di "sincronizzazione attiva" è illeggibile? E che succede con sdd2 in un array separato?

Aggiornare

Ho provato quanto segue dopo aver eseguito il backup dei superblocchi:

root@sysresccd /root % mdadm --stop /dev/md125
mdadm: stopped /dev/md125
root@sysresccd /root % mdadm --stop /dev/md126
mdadm: stopped /dev/md126

Fin qui tutto bene. Poiché sdd2 è di riserva, non voglio ancora aggiungerlo.

root@sysresccd /root % mdadm --assemble /dev/md1 /dev/sd{a,b,c}2 missing 
mdadm: cannot open device missing: No such file or directory
mdadm: missing has no superblock - assembly aborted

Apparentemente non posso farlo.

root@sysresccd /root % mdadm --assemble /dev/md1 /dev/sd{a,b,c}2        
mdadm: /dev/md1 assembled from 1 drive - not enough to start the array.
root@sysresccd /root % cat /proc/mdstat 
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
md1 : inactive sdc2[2](S) sdb2[1](S) sda2[0](S)
      1875194880 blocks

md127 : active raid1 sda1[0] sdd1[3] sdc1[2] sdb1[1]
      64128 blocks [4/4] [UUUU]

unused devices: <none>

Neanche quello ha funzionato. Proviamo con tutti i dischi.

mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@sysresccd /root % mdadm --assemble /dev/md1 /dev/sd{a,b,c,d}2
mdadm: /dev/md1 assembled from 1 drive and 1 spare - not enough to start the array.
root@sysresccd /root % cat /proc/mdstat                           
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
md1 : inactive sdc2[2](S) sdd2[4](S) sdb2[1](S) sda2[0](S)
      2500259840 blocks

md127 : active raid1 sda1[0] sdd1[3] sdc1[2] sdb1[1]
      64128 blocks [4/4] [UUUU]

unused devices: <none>

Senza fortuna. Sulla base di questa risposta ho intenzione di provare:

mdadm --create /dev/md1 --assume-clean --metadata=0.90 --bitmap=/root/bitmapfile --level=5 --raid-devices=4 /dev/sd{a,b,c}2 missing
mdadm --add /dev/md1 /dev/sdd2

È sicuro?

Aggiornare

Pubblico la sceneggiatura superblocco parser ho usato per fare quel tavolo nel mio commento. Forse qualcuno lo troverà utile. Grazie per tutto il vostro aiuto.

linux  software-raid  data-recovery  raid5 
— stribika
fonte
Immagino mdadm --re-addnon sia quello che stai cercando. Hai fatto un test di memoria di recente? Hai qualche messaggio di log relativo al fallimento dell'array?
— Gilles 'SO-smetti di essere malvagio' il
@Gilles: Non ho registri da prima dell'incidente poiché sono stati memorizzati sull'array non funzionante. E non credo di poterlo risolvere con l'interfaccia mdadm standard. Qualsiasi tipo di operazione che comporta una risincronizzazione è impossibile con 1 di 4 dischi. Penso che i 3 dischi "falliti" contengano abbastanza informazioni per ripristinare tutto. Ad esempio, posso leggerli con dd. Quello "buono" potrebbe non essere sincronizzato. Farò un memtest ma quella macchina ora funziona perfettamente con un nuovo disco.
— stribika,
2
Hai provato a fermare l'array e riassemblare uno nuovo con mdadm -A /dev/md1 /dev/sd{b,c,d}2(forse --force)? (Se non lo hai fatto, esegui prima il backup dei superblocchi.)
— Gilles 'SO- smetti di essere malvagio'
@Gilles: ho aggiornato la mia domanda con informazioni aggiornate. Di cosa ho bisogno per eseguire il backup esattamente? I primi blocchi di dischi o esiste uno strumento specifico per questo?
— stribika,
@stribika: il superblocco è l'ultimo blocco completo da 64 kB allineato su un limite di 64 kB sulla partizione. Non ho idea di come /dev/sdd2possa essere in un array separato nonostante abbia lo stesso UUID di sd{a,b,c}2.
— Gilles 'SO-smetti di essere malvagio'

Risposte:

12

Prima controlla i dischi, prova a eseguire smart selftest

for i in a b c d; do
    smartctl -s on -t long /dev/sd$i
done

Il completamento potrebbe richiedere alcune ore, ma controllare lo stato di test di ogni unità ogni pochi minuti, ad es

smartctl -l selftest /dev/sda

Se lo stato di un disco non viene completato a causa di errori di lettura, questo disco deve essere considerato non sicuro per il riassemblaggio di md1. Al termine dell'autotest, è possibile iniziare a provare a riassemblare l'array. Facoltativamente, se si desidera essere più cauti, spostare i dischi su un'altra macchina prima di continuare (solo in caso di ram / controller / ecc. Difettosi).

Di recente, ho avuto un caso esattamente come questo. Un'unità si è guastata, l'ho aggiunta nuovamente nell'array ma durante la ricostruzione 3 di 4 unità si è guastata del tutto. Il contenuto di / proc / mdadm era uguale al tuo (forse non nello stesso ordine)

md1 : inactive sdc2[2](S) sdd2[4](S) sdb2[1](S) sda2[0](S)

Ma sono stato fortunato e ho riassemblato l'array con questo 

mdadm --assemble /dev/md1 --scan --force

Guardando l'output --examine che hai fornito, posso dire che si è verificato il seguente scenario: sdd2 non è riuscito, l'hai rimosso e aggiunto di nuovo, quindi è diventato un'unità di riserva che sta cercando di ricostruire. Ma durante la ricostruzione di sda2 fallito e quindi sdb2 fallito. Quindi il contatore degli eventi è più grande in sdc2 e sdd2, che sono le ultime unità attive nell'array (anche se sdd non ha avuto la possibilità di ricostruirsi e quindi è il più obsoleto di tutti). A causa delle differenze nei contatori di eventi, --force sarà necessario. Quindi potresti anche provare questo

mdadm --assemble /dev/md1 /dev/sd[abc]2 --force

Per concludere, penso che se il comando sopra fallisce, dovresti provare a ricreare l'array in questo modo:

mdadm --create /dev/md1 --assume-clean -l5 -n4 -c64 /dev/sd[abc]2 missing

Se lo fai --create, la missingparte è importante, non provare ad aggiungere una quarta unità nell'array, perché quindi inizierà la costruzione e perderai i tuoi dati . La creazione dell'array con un'unità mancante non modificherà il suo contenuto e avrai la possibilità di ottenere una copia altrove (raid5 non funziona allo stesso modo di raid1).

Se ciò non riesce a far apparire l'array, prova questa soluzione (script perl) qui Ricreare un array

Se riesci finalmente a far apparire l'array, il filesystem sarà sporco e probabilmente corrotto. Se un disco si guasta durante la ricostruzione, si prevede che l'array si fermerà e si bloccherà non eseguendo alcuna scrittura sugli altri dischi. In questo caso due dischi si sono guastati, forse il sistema stava eseguendo richieste di scrittura che non erano in grado di completare, quindi c'è qualche piccola possibilità che tu abbia perso alcuni dati, ma anche una possibilità che non li noterai mai :-)

modifica: alcuni chiarimenti aggiunti.

— forcefsck
fonte
mdadm --assemble /dev/md1 /dev/sd[abc]2 --forcelavorato. Grazie. Hai salvato i miei dati! :) Non tenterò di aggiungere il quarto disco perché il primo 3 non è buono come in precedenza. Il più automatico rivelato ciascuno ha 10-20 blocchi illeggibili. Mi sento stupido per non aver controllato prima questo.
— stribika,
Grazie per una risposta esaustiva. Premiato con 50 rappresentanti da parte mia.
— 0xC0000022L,
Permute_array.pl ha funzionato benissimo per me. Nota per gli altri utenti: l'array di dispositivi che prevede di vedere include tutte le unità, incluso qualsiasi unità morta che potresti aver rimosso.
"Se esegui il comando --create, la parte mancante è importante, non provare ad aggiungere una quarta unità nell'array, perché la costruzione inizierà e perderai i tuoi dati." - BS. Se hai specificato --assume-clean(lo hai fatto) non lo farà.
— poige,
1

Ho riscontrato molti problemi durante l'utilizzo mdadm, ma non ho mai perso i dati. Dovresti evitare l' --forceopzione o usarla con molta attenzione, perché potresti perdere tutti i tuoi dati. Per favore pubblica il tuo/etc/mdadm/mdadm.conf

— Glendyr
fonte
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.