Ich habe einen Server mit 3 SATA-Festplatten. Jede hat 2 Partitionen: eine kleine ist Teil von /dev/md0, einem RAID1-Array (/boot), der Rest ist Teil eines RAID5-Arrays (/dev/md1), das ein physisches LVM-Volume ist. Darin befinden sich 3 (soweit ich mich erinnere) logische Volumes. Eines davon ist ein ReiserFS 3.6-FS, das etwa 100 Gigabyte Daten enthält.
Gestern ist dieser Server abgestürzt. Beim Einschalten teilte mir SMART mit, dass eines der Laufwerke tot sei. Es machte tatsächlich sehr schlimme Geräusche. Also entfernte ich das defekte Laufwerk und versuchte, das System mit den beiden verbleibenden Festplatten neu zu starten. Was fehlschlug.
Mit einer Live-CD habe ich es gestartet und versucht, das Array neu zu starten. Leider hat mdadm dies abgelehnt, da es dachte, eine der beiden verbleibenden Festplatten sei ebenfalls ausgefallen.
Befolgen Sie also den Rat unterWie kann man ein abgestürztes Linux md RAID5-Array wiederherstellen?das auf meine Situation zutreffen könnte, tat ich etwas, das wahrscheinlich einfach nur dumm war: Ich rannte
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c64 /dev/sd[ab]2 missing
Nun kann ich dieses Array tatsächlich starten, aber die LVM-Tools (vgscan, vgdisplay, pvck) können auf dem Array nichts finden, was mit LVM zu tun hat, und ich kann überhaupt nicht auf meine Daten zugreifen. Habe ich gerade alle LVM-Metadaten gelöscht?
Ich habe das Gefühl, dass die eigentlichen Daten noch unbeschädigt vorhanden sind (abgesehen von den LVM-Metadaten). Besteht eine Möglichkeit, die Daten zurückzubekommen? Wie?
AKTUALISIEREN:
Ich bin dem Rat von psusi (siehe unten) gefolgt und habe jede der folgenden Möglichkeiten zum Neuerstellen des Arrays ausprobiert:
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c64 /dev/sda2 /dev/sdb2 missing
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c64 /dev/sdb2 /dev/sda2 missing
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c64 /dev/sda2 missing /dev/sdb2
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c64 /dev/sdb2 missing /dev/sda2
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c64 missing /dev/sda2 /dev/sdb2
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c64 missing /dev/sdb2 /dev/sda2
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c512 /dev/sda2 /dev/sdb2 missing
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c512 /dev/sdb2 /dev/sda2 missing
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c512 /dev/sda2 missing /dev/sdb2
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c512 /dev/sdb2 missing /dev/sda2
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c512 missing /dev/sda2 /dev/sdb2
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c512 missing /dev/sdb2 /dev/sda2
Das sind im Grunde alle möglichen Reihenfolgen, sowohl mit -c64 als auch mit -c512. Nach jedem Test habe ich einen vgscan ausgeführt. Keiner hat etwas gefunden. Vielleicht sollte ich nicht vgscan, sondern ein anderes Tool verwenden?
UPDATE 2:
Ich habe versucht, die defekte Festplatte wieder anzuschließen. Und welch ein Wunder, es scheint einigermaßen zu funktionieren. Zumindest genug, um es zu untersuchen:
root@debian:~# mdadm --examine /dev/sda2
/dev/sda2:
Magic : a92b4efc
Version : 0.90.00
UUID : 1f5462ab:6945560d:019b01a5:914dd464
Creation Time : Fri Oct 17 12:40:40 2008
Raid Level : raid5
Used Dev Size : 160015360 (152.60 GiB 163.86 GB)
Array Size : 320030720 (305.21 GiB 327.71 GB)
Raid Devices : 3
Total Devices : 3
Preferred Minor : 1
Update Time : Tue Apr 12 08:15:03 2011
State : active
Active Devices : 3
Working Devices : 3
Failed Devices : 0
Spare Devices : 0
Checksum : 64d514fb - correct
Events : 137
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
Gibt es also eine Möglichkeit, diesen Superblock auf die anderen beiden Geräte zu kopieren, damit ich das Array „richtig“ starten kann?
Antwort1
Ich habe ein ähnliches Setup und kann empfehlen, ein komplettes Linux auf der kleinen Partition jedes Laufwerks zu haben undnichtSpiegeln Sie diese kleinen Partitionen, aber sorgen Sie dafür, dass sie separat vollständig bootfähig sind.
Sie können syncdas Setup auf einige wichtige Dateien ( /etc/fstab, Grub-Konfiguration) beschränken. Dies nimmt zwar mehr Platz in Anspruch, /bootspart aber viel Zeit, wenn Probleme auftreten.
Antwort2
Sie haben die Laufwerke wahrscheinlich nicht in derselben Reihenfolge oder mit derselben Blockgröße wie zuvor zusammengestellt. Sie müssen herausfinden, wie die Reihenfolge vorher war, und dieselbe Reihenfolge verwenden, wenn Sie das Array neu erstellen. Mit anderen Worten, es war möglicherweise nicht die dritte Festplatte, die kaputtgegangen ist, sondern die erste oder zweite, oder Sie haben möglicherweise sda und sdb verwechselt.
Antwort3
Als @psusi angedeutetMetadatenformat ist anscheinend der Schlüssel — jetzt ist „1.2“ die Vorgabe, nicht „0.9“. Es ist schade, aber das könnte zu Datenverlust führen, da 1.2 einen 4-KiB-Offset verwendet:
1, 1.0, 1.1, 1.2 Standardmäßig wird der neue Superblock im Version-1-Format verwendet. Dieser hat weniger Einschränkungen. Er kann problemlos zwischen Hosts mit unterschiedlicher Byte-Reihenfolge verschoben werden, und ein Wiederherstellungsvorgang kann überprüft und neu gestartet werden. Die verschiedenen Unterversionen speichern den Superblock an unterschiedlichen Stellen auf dem Gerät, entweder am Ende (für 1.0), am Anfang (für 1.1) oder 4 KB vom Anfang entfernt (für 1.2).
Ein Ratschlag (leider spät): Überstürzen Sie nie die Neuerstellung eines Arrays, ohne es vorher mit -B— build versucht zu haben:
-B, --build Build a legacy array without superblocks
UPD.: Es stellte sich heraus, -Bdass der Aufbau von RAID-5 nicht möglich ist … :-/