Zuerst, wie ich in diese Situation gekommen bin:
Ich hatte ein RAID5-Array mit Festplatten von jeweils 2 TB (externe USB-Festplatten), ich wollte dann ein größeres verschlüsseltes Array erstellen. Daher habe ich 2 zusätzliche Festplatten (ebenfalls jeweils 2 TB) und der Plan war, das ursprüngliche Array im degradierten Modus auszuführen, das neue verschlüsselte Array einzurichten, einen Teil der Daten zu kopieren und danach das ursprüngliche Array auf 2 Festplatten im degradierten Modus zu verkleinern. Vergrößern Sie die neue, kopieren Sie den Rest der Daten und vergrößern Sie sie schließlich auf 7 Festplatten RAID5 nicht herabgesetzt. Ich habe die ganze Prozedur mit /dev/loopX
gemacht Geräte jeweils 2 GB, um zu testen, ob mein Plan Einschränkungen enthält.
Mit dem echten Array lief alles gut, bis zu dem Punkt, an dem eine der neuen Festplatten ausfiel. Als ich diesen ersetzte, änderte sich die Reihenfolge, in der die Festplatten vom Kernel erkannt werden, nach dem nächsten Neustart (/dev/sdb
, /dev/sdc
, … waren alle andere Festplatten als vorher). Alles wurde durcheinander gebracht und ich bemerkte das nicht, bis eine der Festplatten als Mitglied des falschen Arrays neu synchronisiert wurde. Ich erspare mir die Details dieser Geschichte und komme direkt zum Punkt:
Ich habe jetzt ein verschlüsseltes Array, 3-Festplatten-RAID5, degradiert auf /dev/sdc1
und /dev/sdd1
, läuft einwandfrei, alle Daten vorhanden und ein gesundes Dateisystem laut fsck -f
.
So weit so gut.
Das ganze Problem liegt jetzt bei 3 Festplatten – ich kann dieses unverschlüsselte Array nicht wieder zum Laufen bringen. Ich bin mir ziemlich sicher, dass die Daten HABEN dort auf /dev/sdf1
zu finden , /dev/sdg1
, /dev/sdh1
, da dies ein funktionierendes Array war, kurz bevor EINE der Festplatten durcheinander gebracht wurde (versehentlich als Mitglied des anderen verschlüsselten Arrays neu synchronisiert wurde, wie bereits erwähnt). Eine dieser drei Festplatten kann also falsche Array-Daten enthalten, aber welche? Und zwei davon müssen gut sein, aber wie finde ich das heraus?
Ich habe jede Permutation von mdadm --create
ausprobiert … mit /dev/sdf1
, /dev/sdg1
, /dev/sdh1
und „fehlt“ wie:
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
...
und natürlich immer mit
überprüft
fsck /dev/md0
die sich über einen ungültigen Superblock beschwert hat.
Jedes Mal, wenn mdadm das Array erstellte, aber kein Dateisystem lesbar war, enthielt es nur Müll, keine der mit mdadm verwendeten Permutationen funktionierte letztendlich.
Meine Frage ist also jetzt:Welche Möglichkeiten habe ich noch? Außerdem verliere ich natürlich meine Daten und baue das Array von Grund auf neu auf.
Hier einige zusätzliche Informationen (alle Festplatten):
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>
Jede Hilfe wäre sehr willkommen!
Verwandte:Warum erlaubt rsync keine Blockgröße> 128 KB?Akzeptierte Antwort:
Wenn Sie gerade eine Festplatte verloren haben, sollten Sie es konnten sich mit dem sehr viel sichereren --assemble
davon erholen .
Sie haben create jetzt so oft ausgeführt, dass alle UUIDs unterschiedlich sind. sdc1
und sdd1
teilen Sie sich eine UUID (erwartet, da dies Ihr Arbeitsarray ist)… der Rest der Festplatten hat einen gemeinsamen Namen, aber alle haben unterschiedliche UUIDs. Ich vermute also, dass keiner davon die ursprünglichen Superblöcke sind. Schade…
Wie auch immer, ich würde vermuten, dass Sie entweder versuchen, die falschen Festplatten zu verwenden, oder Sie versuchen, die falsche Chunk-Größe zu verwenden (die Standardeinstellung hat sich im Laufe der Zeit geändert, glaube ich). Ihr altes Array hat möglicherweise auch eine andere Superblock-Version verwendet – diese Standardeinstellung hat sich definitiv geändert – was alle Sektoren versetzen könnte (und auch einige der Daten zerstören würde). Schließlich ist es möglich, dass Sie das falsche Layout verwenden, obwohl dies weniger wahrscheinlich ist.
Es ist auch möglich, dass Ihr Test-Array (aus md-Sicht) lese- und schreibbar war, dass Versuche, ext3 zu verwenden, tatsächlich einige Schreibvorgänge ausgeführt haben. Z. B. eine Tagebuchaufzeichnung. Aber das ist nur, wenn es irgendwann einen Superblock gefunden hat, denke ich.
Übrigens:Ich denke, Sie sollten wirklich --assume-clean
verwenden , obwohl ein degradiertes Array natürlich nicht versucht, mit dem Wiederaufbau zu beginnen. Dann möchten Sie wahrscheinlich sofort schreibgeschützt setzen.