Ripristino dell'array RAID5 del software Linux dopo l'aggiornamento del server

Recentemente ho aggiornato un server da Fedora 6 a Fedora 14. Oltre al disco rigido principale in cui è installato il sistema operativo, ho 3 dischi rigidi da 1 TB configurati per RAID5 (tramite software). Dopo l'aggiornamento, ho notato che uno dei dischi rigidi era stato rimosso dall'array RAID. Ho provato ad aggiungerlo di nuovo con mdadm --add, ma lo ho appena inserito come riserva. Ho pensato di tornarci più tardi.

Quindi, quando si esegue un riavvio, il sistema non è in grado di montare l'array RAID. L'ho rimosso da fstab in modo da poter avviare il sistema, e ora sto cercando di ottenere il backup dell'array raid.

Ho eseguito quanto segue:

mdadm --create /dev/md0 --assume-clean --level=5 --chunk=64 --raid-devices=3 missing /dev/sdc1 /dev/sdd1

So che la mia dimensione del blocco è 64k e "mancante" è per l'unità che è stata estratta dall'array (/ dev / sdb1).

Sembra che funzioni e mdadm segnala che l'array è in esecuzione "pulito, degradato" con l'unità mancante.

Tuttavia, non posso montare l'array RAID. Quando provo:

mount -t ext3 /dev/md0 /mnt/foo

Ottengo:

mount: wrong fs type, bad option, bad superblock on /dev/md0,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

e / var / log / messages mostra:

EXT3-fs (md0): error: can't find ext3 filesystem on dev md0.

Qualcuno ha qualche idea su cosa provare dopo?

Potresti avere il missing nella posizione sbagliata. Solo la posizione corretta delle unità e missing funzionerà. Corri:

mdadm --examine  /dev/sdb1

Ciò produrrà (tra le altre cose) le informazioni che il numero nel RAID è veramente mancante. Cerca il this linea:

      Number   Major   Minor   RaidDevice State
this     0     253       13        0      active sync   /dev/dm-13

In questo caso, è il numero 0 (= primo dispositivo) e active dato che il mio RAID è online adesso. Ora sai che l'unità dovrebbe essere specificata come missing.

Ma hai ancora 2 scelte: l'ordine del lavoro le unità possono anche essere scambiate. Questa informazione è persa, tuttavia, perché è stata sovrascritta dal tuo tentativo di rimontaggio.

una delle cose che ho trovato è quella mdadm --create /dev/md0 --assume-clean funzionerà correttamente solo se utilizzi la stessa (o vicina) versione di mdadm che è stata utilizzata per creare l'array originale. Questo è perché usano offset diversi per dati e metadati, anche se la stessa versione superblock (come 1.2)

Il problema è che l'output di mdadm dirà sempre che l'array è stato ricreato bene, ma i dati contenuti in / dev / md0 saranno errati.

ad esempio, usare il recente mdadm 3.3.2 o anche il precedente 3.2.5 non ha funzionato per me, ma tornare a mdadm 3.1.4 (che ha creato l'array) ha funzionato bene.

Si noti che ho anche avuto cura di specificare le unità nell'ordine corretto (come descritto in mdadm --examine /dev/sd? ) quando si ricrea la matrice e si usano i file di sovrapposizione per tutti i test (per non aumentare il danno), usando le istruzioni a https://raid.wiki.kernel.org/index.php/Recovering_a_failed_software_RAID

Nel mio caso il problema era il RAID5 da 6 dischi che era stato sviluppato su 7 dischi, ma non ha fatto progressi, quindi è stato interrotto e non si sarebbe più assemblato con mdadm: Failed to restore critical section for reshape, sorry., e --force e --invalid-backup neanche io stavo aiutando, quindi ho dovuto usare --create --assume-clean