Innanzitutto come sono arrivato in questa situazione:
Avevo un array RAID5 con dischi ogni 2 TB (dischi USB esterni), quindi volevo creare un array crittografato più grande. Pertanto ho ottenuto 2 dischi aggiuntivi (anche 2 TB ciascuno) e il piano era di eseguire l'array originale in modalità degradata, impostare il nuovo array crittografato, copiare parte dei dati, quindi ridurre l'array originale a 2 dischi in modalità degradata, ingrandisci quello nuovo, copia il resto dei dati e infine ingrandiscilo a 7 dischi RAID5 non degradati. Ho eseguito l'intera procedura con /dev/loopX dispositivi da 2 GB ciascuno per verificare se il mio piano ha delle avvertenze.
Tutto è andato bene con l'array reale fino al punto in cui uno dei nuovi dischi si è guastato. Quando ho sostituito questo, l'ordine in cui i dischi vengono riconosciuti dal kernel è cambiato dopo il prossimo riavvio (/dev/sdb , /dev/sdc , … erano tutti dischi diversi rispetto a prima). Tutto è stato incasinato e non me ne sono reso conto fino a quando uno dei dischi non è stato risincronizzato come membro dell'array sbagliato. Risparmio i dettagli di questa storia e vado dritto al punto:
Ora ho un array crittografato, RAID5 a 3 dischi, degradato su /dev/sdc1 e /dev/sdd1 , perfettamente funzionante, tutti i dati lì e un file system sano secondo fsck -f .
Fin qui tutto bene.
L'intero problema è ora ridotto a 3 dischi:non riesco a far funzionare di nuovo questo array non crittografato. Sono abbastanza sicuro che i dati HAS essere presente su /dev/sdf1 , /dev/sdg1 , /dev/sdh1 , poiché si trattava di un array funzionante appena prima che UNO dei dischi potesse essere incasinato (è stato accidentalmente risincronizzato come membro dell'altro array crittografato, come detto prima). Quindi, uno di questi tre dischi potrebbe avere dati di array errati, ma quale? E due di loro devono essere buoni, ma come faccio a capirlo?
Ho provato ogni permutazione di mdadm --create … con /dev/sdf1 , /dev/sdg1 , /dev/sdh1 e "mancanti" come:
mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/sdf1 /dev/sdg1 missing
mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/sdf1 missing /dev/sdg1
...e ovviamente controllato ogni volta con
fsck /dev/md0
che si è lamentato di un superblocco non valido.
Ogni volta che mdadm creava l'array, ma non c'era un file system leggibile, conteneva solo spazzatura, nessuna delle permutazioni utilizzate con mdadm alla fine funzionava.
Quindi la mia domanda ora è:quali opzioni ho ancora? Oltre a perdere i miei dati e ricostruire l'array da zero, ovviamente.
Qui alcune informazioni aggiuntive (tutti i dischi):
mdadm --examine /dev/sdb1
/dev/sdb1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : cfee26c0:414eee94:e470810c:17141589
Name : merlin:0 (local to host merlin)
Creation Time : Sun Oct 28 11:38:32 2012
Raid Level : raid5
Raid Devices : 3
Avail Dev Size : 3906760704 (1862.89 GiB 2000.26 GB)
Array Size : 3906759680 (3725.78 GiB 4000.52 GB)
Used Dev Size : 3906759680 (1862.89 GiB 2000.26 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : f4f0753e:56b8d6a5:84ec2ce8:dbc933f0
Update Time : Sun Oct 28 11:38:32 2012
Checksum : 60093b72 - correct
Events : 0
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 1
Array State : AA. ('A' == active, '.' == missing)
mdadm --examine /dev/sdc1
/dev/sdc1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 5cb45bae:7a4843ba:4ad7dbfb:5c129d2a
Name : merlin:1 (local to host merlin)
Creation Time : Wed Sep 26 07:32:32 2012
Raid Level : raid5
Raid Devices : 3
Avail Dev Size : 3906760704 (1862.89 GiB 2000.26 GB)
Array Size : 3905299456 (3724.38 GiB 3999.03 GB)
Used Dev Size : 3905299456 (1862.19 GiB 1999.51 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 9e2f9ae6:6c95d05e:8d83970b:f1308de0
Update Time : Fri Oct 26 03:26:37 2012
Checksum : 79d4964b - correct
Events : 220
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 0
Array State : AA. ('A' == active, '.' == missing)
mdadm --examine /dev/sdd1
/dev/sdd1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 5cb45bae:7a4843ba:4ad7dbfb:5c129d2a
Name : merlin:1 (local to host merlin)
Creation Time : Wed Sep 26 07:32:32 2012
Raid Level : raid5
Raid Devices : 3
Avail Dev Size : 3906760704 (1862.89 GiB 2000.26 GB)
Array Size : 3905299456 (3724.38 GiB 3999.03 GB)
Used Dev Size : 3905299456 (1862.19 GiB 1999.51 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 98b07c41:ff4bea98:2a765a6b:63d820e0
Update Time : Fri Oct 26 03:26:37 2012
Checksum : 6e2767e8 - correct
Events : 220
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 1
Array State : AA. ('A' == active, '.' == missing)
mdadm --examine /dev/sde1
/dev/sde1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 6db9959d:3cdd4bc3:32a241ad:a9f37a0c
Name : merlin:0 (local to host merlin)
Creation Time : Sun Oct 28 12:12:59 2012
Raid Level : raid5
Raid Devices : 3
Avail Dev Size : 3905299943 (1862.19 GiB 1999.51 GB)
Array Size : 3905299456 (3724.38 GiB 3999.03 GB)
Used Dev Size : 3905299456 (1862.19 GiB 1999.51 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 677a4410:8931e239:2c789f83:e130e6f7
Update Time : Sun Oct 28 12:12:59 2012
Checksum : 98cb1950 - correct
Events : 0
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 2
Array State : A.A ('A' == active, '.' == missing)
mdadm --examine /dev/sdf1
/dev/sdf1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 3700a0a6:3fadfd73:bc74b618:a5526767
Name : merlin:0 (local to host merlin)
Creation Time : Sun Oct 28 11:28:30 2012
Raid Level : raid5
Raid Devices : 3
Avail Dev Size : 3905392640 (1862.24 GiB 1999.56 GB)
Array Size : 3905391616 (3724.47 GiB 3999.12 GB)
Used Dev Size : 3905391616 (1862.24 GiB 1999.56 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 5a8a5423:10b7a542:26b5e2b3:f0887121
Update Time : Sun Oct 28 11:28:30 2012
Checksum : 8e90495f - correct
Events : 0
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 1
Array State : AA. ('A' == active, '.' == missing)
mdadm --examine /dev/sdg1
/dev/sdg1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 202255c9:786f474d:ba928527:68425dd6
Name : merlin:0 (local to host merlin)
Creation Time : Sun Oct 28 11:24:36 2012
Raid Level : raid5
Raid Devices : 3
Avail Dev Size : 3905299943 (1862.19 GiB 1999.51 GB)
Array Size : 3905299456 (3724.38 GiB 3999.03 GB)
Used Dev Size : 3905299456 (1862.19 GiB 1999.51 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 4605c729:c290febb:92901971:9a3ed814
Update Time : Sun Oct 28 11:24:36 2012
Checksum : 38ba4d0a - correct
Events : 0
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 1
Array State : AA. ('A' == active, '.' == missing)
mdadm --examine /dev/sdh1
/dev/sdh1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 682356f5:da2c442e:7bfc85f7:53aa9ea7
Name : merlin:0 (local to host merlin)
Creation Time : Sun Oct 28 12:13:44 2012
Raid Level : raid5
Raid Devices : 3
Avail Dev Size : 3906761858 (1862.89 GiB 2000.26 GB)
Array Size : 3906760704 (3725.78 GiB 4000.52 GB)
Used Dev Size : 3906760704 (1862.89 GiB 2000.26 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 489943b3:d5e35022:f52c917a:9ca6ff2a
Update Time : Sun Oct 28 12:13:44 2012
Checksum : f6947a7d - correct
Events : 0
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 1
Array State : AA. ('A' == active, '.' == missing)
cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid5 sdc1[0] sdd1[1]
3905299456 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
unused devices: <none>
Qualsiasi aiuto sarebbe molto apprezzato!
Correlati:perché rsync non consente dimensioni del blocco> 128K?Risposta accettata:
Se hai appena perso un disco, dovresti sono stati in grado di recuperare da ciò utilizzando il molto più sicuro --assemble .
Hai eseguito create ora così tanto che tutti gli UUID sono diversi. sdc1 e sdd1 condividi un UUID (previsto, dato che è il tuo array di lavoro)... il resto i dischi condividono un nome, ma hanno tutti UUID diversi. Quindi suppongo che nessuno di questi sia i superblocchi originali. Peccato...
Ad ogni modo, suppongo che tu stia tentando di utilizzare i dischi sbagliati o che tu stia cercando di utilizzare la dimensione del blocco sbagliata (l'impostazione predefinita è cambiata nel tempo, credo). Il tuo vecchio array potrebbe aver utilizzato anche una versione del superblocco diversa, che l'impostazione predefinita è decisamente cambiata, che potrebbe compensare tutti i settori (e anche distruggere alcuni dati). Infine, è possibile che tu stia utilizzando il layout sbagliato, anche se è meno probabile.
È anche possibile che l'array di test fosse di lettura-scrittura (dal punto di vista md) che tenta di utilizzare ext3 abbia effettivamente eseguito alcune scritture. Ad esempio, un replay del diario. Ma questo è solo se a un certo punto ha trovato un superblocco, credo.
A proposito:penso che dovresti davvero usare --assume-clean , anche se ovviamente un array degradato non tenterà di avviare la ricostruzione. Quindi probabilmente vorrai impostare immediatamente la sola lettura.