mdadm raid5 ripristina il guasto del doppio disco - con un colpo di scena (ordine dell'unità)

Consentitemi di riconoscere innanzitutto che ho commesso errori e che ho un backup per la maggior parte ma non per tutti i dati su questo RAID. Spero ancora di recuperare il resto dei dati. Non ho il tipo di denaro per portare le unità in un'azienda esperta di recupero.

Errore # 0, non avendo un backup del 100%. Lo so.

Ho un mdadmsistema RAID5 di 4x3 TB. Drives / dev / sd [be], tutti con una partizione /dev/sd[b-e]1. Sono consapevole che RAID5 su unità molto grandi è rischioso, eppure l'ho fatto comunque.

Eventi recenti

Il RAID si deteriora dopo un guasto a due unità. Un'unità [/ dev / sdc] è davvero sparita, l'altra [/ dev / sde] è tornata su dopo un ciclo di accensione, ma non è stata automaticamente aggiunta di nuovo al RAID. Quindi mi è rimasto un RAID a 4 dispositivi con solo 2 unità attive [/ dev / sdb e / dev / sdd].

Errore n. 1, non utilizzare copie dd delle unità per ripristinare il RAID. Non avevo le unità o il tempo. Errore n. 2, non eseguire un backup del superblocco e mdadm -Edelle unità rimanenti.

Tentativo di recupero

Ho riassemblato il RAID in modalità degradata con

mdadm --assemble --force /dev/md0, using /dev/sd[bde]1.

Potrei quindi accedere ai miei dati. Ho sostituito /dev/sdccon un ricambio; vuoto; unità identica.

Ho rimosso il vecchio /dev/sdc1dal RAID

mdadm --fail /dev/md0 /dev/sdc1

Errore n. 3, non farlo prima di sostituire l'unità

Ho quindi partizionato il nuovo /dev/sdce l'ho aggiunto al RAID.

mdadm --add /dev/md0 /dev/sdc1

Quindi ha iniziato a ripristinare il RAID. ETA 300 min. Ho seguito il processo /proc/mdstatfino al 2% e poi sono andato a fare altre cose.

Verifica del risultato

Diverse ore (ma meno di 300 minuti) più tardi, ho controllato il processo. Si era interrotto a causa di un errore di lettura attivato /dev/sde1.

Qui è dove inizia davvero il problema

Ho quindi rimosso /dev/sde1dal RAID e l'ho aggiunto di nuovo. Non ricordo perché l'ho fatto; era tardi.

mdadm --manage /dev/md0 --remove /dev/sde1
mdadm --manage /dev/md0 --add /dev/sde1

Tuttavia, /dev/sde1ora è stato contrassegnato come ricambio. Così ho deciso di ricreare l'intero array usando --assume-clean usando quello che pensavo fosse il giusto ordine e con la /dev/sdc1mancanza.

mdadm --create /dev/md0 --assume-clean -l5 -n4 /dev/sdb1 missing /dev/sdd1 /dev/sde1

Ha funzionato, ma il filesystem non è stato riconosciuto durante il tentativo di montare. (Avrebbe dovuto essere EXT4).

Ordine del dispositivo

Ho quindi controllato un backup recente di cui disponevo /proc/mdstate ho trovato l'ordine dell'unità.

md0 : active raid5 sdb1[0] sde1[4] sdd1[2] sdc1[1]
      8790402048 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]

Ho poi ricordato che questo RAID aveva subito una perdita di unità circa un anno fa e mi sono ripreso sostituendo l'unità guasta con una di riserva. Ciò potrebbe aver confuso un po 'l'ordine del dispositivo ... quindi non c'erano unità [3] ma solo [0], [1], [2] e [4].

Ho provato a trovare l'ordine dell'unità con lo script Permute_array: https://raid.wiki.kernel.org/index.php/Permute_array.pl ma quello non ha trovato l'ordine giusto.

Domande

Ora ho due domande principali:

1. Ho rovinato tutti i superblocchi sui dischi, ma ho dato solo:

   mdadm --create --assume-clean
   

   comandi (quindi non avrei dovuto sovrascrivere i dati stessi /dev/sd[bde]1. Ho ragione che in teoria il RAID può essere ripristinato [supponendo per un momento che /dev/sde1sia ok] se trovo solo il giusto ordine del dispositivo?

2. È importante che /dev/sde1venga assegnato il numero del dispositivo [4] nel RAID? Quando lo creo con

   mdadm --create /dev/md0 --assume-clean -l5 -n4 \
     /dev/sdb1 missing /dev/sdd1 /dev/sde1
   

   gli viene assegnato il numero [3]. Mi chiedo se ciò sia rilevante per il calcolo dei blocchi di parità. Se risulta essere importante, come posso ricreare l'array con /dev/sdb1[0][1] mancante /dev/sdd1[2] /dev/sde1[4]? Se riuscissi a farlo funzionare, potrei avviarlo in modalità degradata e aggiungere la nuova unità /dev/sdc1e lasciarlo risincronizzare di nuovo.

Va bene se vuoi farmi notare che questo potrebbe non essere stato il miglior modo di agire, ma scoprirai che me ne sono reso conto. Sarebbe bello se qualcuno avesse qualche suggerimento.

Per rispondere alle tue domande,

1. Può essere ripristinato?

   • La prima cosa è prima: FERMATI, siediti e pensa un po '. Sì, l'algoritmo, la dimensione del blocco e l'ordine del disco sono fondamentali per ottenere il riassemblaggio corretto di qualsiasi file system presente. Ma dal momento che hai sovrascritto i superblocchi, ora sei rimasto con tentativi ed errori.
   • Secondo, c'è un modo per recuperare il layout del disco precedente? Faccio sempre un file mdadm --detail> backup solo per mantenere sicuro quel layout del disco. Controlla dmesg, / var / log per eventuali prove di come sono stati configurati i dischi nel raid.
   • Infine, se abbini la dimensione del blocco precedente e l'ordine del disco, potresti aver danneggiato il superblocco ext4 - ci sono modi per eseguire scansioni veloci per altri superblocchi (e c'è un programma ingegnoso chiamato TestDisk che cerca i superblocchi dei filesystem esistenti e prova a sfogliarli manualmente: http://www.cgsecurity.org/wiki/Main_Page )

2. Poiché sdc è nuovo, continuerei a provare ad assemblare manualmente tramite la clausola mancante, e sì, sde deve essere nell'ordine corretto per poter essere assemblato in modalità degradata. Una volta trovato il layout corretto, copia tutti i dati dall'array e riavvia, documentando il layout (in modo da non eseguire nuovamente questo problema).

In bocca al lupo

Prima di fare qualsiasi altra cosa, catturare un 'mdadm --examine / dev / sdX1' per ciascuna delle unità che erano nel proprio array e un 'mdadm --detail / dev / md0' da quello, si dovrebbe essere in grado di determinare il layout esatto.

Ho dovuto farlo da solo per recuperare un array Synology in una domanda separata:

Come ripristinare un array mdadm su Synology NAS con unità nello stato "E"?

Modifica: mi dispiace, ho appena visto che hai detto che hai perso i superblocchi su tutte le unità.

I tuoi comandi successivi SONO corretti. L'opzione più semplice potrebbe essere quella di eseguire le creazioni con ogni possibile ordinamento e quindi vedere se è possibile montare e accedere al filesystem su di esse in sola lettura.

Questa domanda è vecchia e sono sicuro che nessuno può aiutarti ora, ma per gli altri che leggono:

l'errore più pericoloso che hai fatto non è uno che hai numerato, che doveva essere eseguito:

mdadm --create ...

sui dischi originali, prima che tu fossi preparato sapendo cosa fare. Questo ha sovrascritto i metadati, quindi non hai alcuna registrazione di ordine dell'unità, offset dei dati, dimensione del blocco, ecc.

Per recuperare da questo, è necessario sovrascriverli nuovamente con i valori corretti. Il modo più semplice per saperlo è guardare i metadati, ma l'hai già distrutto. Il prossimo modo è di indovinare. Indovina le diverse combinazioni di un comando come questo, con valori diversi per qualsiasi opzione tranne quella che conosci (4 dispositivi, livello 5) e anche un diverso ordine del disco:

mdadm --create /dev/md0 --assume-clean --metadata=1.2 --raid-devices=4 --level=5 --layout=... --chunk=512 --data-offset=128M /dev/sdb1 missing /dev/sdd1 /dev/sde1

Ma dal momento che NON conosci il risultato corretto, ancora una volta, non dovresti eseguirlo sui vecchi dischi distruggendoli ulteriormente, facendo lo stesso errore fatale. Invece, usa un overlay; ad esempio questa procedura dovrebbe funzionare per mantenere al sicuro gli originali.

Una volta che hai trovato alcuni argomenti che producono un array funzionante che puoi fsck o montare e verificare (es. Controlla il checksum di un file abbastanza grande da estendersi su tutti i membri del raid come un iso che dovresti aver archiviato con il suo checksum / pgp firma, o decomprimere -t o gunzip-un grande archivio)