Das MD-RAID5-Array scheint plötzlich nicht mehr zu funktionieren. Die Symptome ähneln denen vondieses Problemdarin erhalte ich Fehlermeldungen, dass nicht genügend Geräte vorhanden sind, um das Array zu starten. In meinem Fall sind die Ereigniszahlen auf allen drei Laufwerken jedoch gleich. Es handelt sich um ein RAID-5-Array, das zwei aktive Laufwerke und ein Paritätslaufwerk haben sollte. Allerdings zeigt mdadm --examine auf jedem Laufwerk an, dass zwei davon als Ersatzlaufwerk aufgeführt sind und nur eines als aktives Laufwerk.
ich habe es versuchtmdadm --stop /dev/md1gefolgt vonmdadm --assemblieren /dev/md1(einschließlich Versuche mit den Flags --force und --run).
SMART-Daten deuten auf keine Probleme mit den Laufwerken hin (und die aktuellen ausstehenden und neu zugewiesenen Sektorenzahlen sind alle Null), ich habe versucht,raid.wiki.kernel.org-AnleitungFrostschutz führt Sie unten per Link durch die Schritte zum Einrichten zugeordneter Overlay-Geräte.
Ich hätte dann angenommen, dass die Ausführung des folgenden Befehls ein RAID-Array erstellen würde, das ich dann schreibgeschützt mounten könnte, um zu sehen, ob das zu einem lesbaren Dateisystem oder nur einem wirren Durcheinander führt (um festzustellen, ob meine Vermutung, dass sdf1 das Paritätslaufwerk ist, richtig war oder ob ich es noch einmal mit sde1 versuchen sollte) - aber stattdessen wird der unten gezeigte Fehler ausgegeben (habe es auch mit den zugehörigen Loop-Geräten gemäßlosetup --Liste, mit dem gleichen Ergebnis).
mdadm --create /dev/md2 --assume-clean --level=5 --chunk=64K --metadata=1.2 --data-offset=261888s --raid-devices=3 fehlt /dev/mapper/sdh1 /dev/mapper/sdf1
mdadm: super1.x cannot open /dev/mapper/sdh1: Device or resource busy
mdadm: /dev/mapper/sdh1 is not suitable for this array.
mdadm: super1.x cannot open /dev/mapper/sdf1: Device or resource busy
mdadm: /dev/mapper/sdf1 is not suitable for this array.
mdadm: create aborted
Auch währendmdadm --detail /dev/md1gab vorher (weiter) die folgende Ausgabe, jetzt gibt es:
/dev/md1:
Version : 1.2
Raid Level : raid0
Total Devices : 3
Persistence : Superblock is persistent
State : inactive
Working Devices : 3
Name : bob:1 (local to host bob)
UUID : 07ff9ba9:e8100e68:94c12c1a:3d7ad811
Events : 373364
Number Major Minor RaidDevice
- 253 11 - /dev/dm-11
- 253 10 - /dev/dm-10
- 253 9 - /dev/dm-9
Außerdem ist mir aufgefallendmsetup-Statusgibt für alle drei Overlays die gleichen Informationen an und weist eine Zahl auf, die verdächtig danach aussieht, sich auf die Größe des ursprünglichen RAID-Arrays (16 TB) und nicht auf ein einzelnes Laufwerk (8 TB) zu beziehen – nicht sicher, ob das so sein sollte?
sde1: 0 15627528888 snapshot 16/16777216000 16
sdh1: 0 15627528888 snapshot 16/16777216000 16
sdf1: 0 15627528888 snapshot 16/16777216000 16
Ich bin nicht sicher, wie ich von diesem Punkt aus weitermachen soll, was den Versuch angeht, das Gerät zu erstellen, es zu mounten und das Dateisystem zu überprüfen, um zu bestätigen, ob ich das richtige Paritätsgerät erraten habe oder nicht, und das Overlay zu verwenden, um zu verhindern, dass irgendetwas auf die tatsächlichen Laufwerke geschrieben wird.
AKTUALISIEREN: Gemäß Frostschutz's Vorschlag unten befand sich das Array irgendwie in einem Zustand, in dem --stop ausgegeben werden musste, bevor irgendetwas mit den zugrunde liegenden Laufwerken gemacht werden konnte. Ich hatte diese Möglichkeit zuvor ausgeschlossen, daKatze /proc/mdstatzeigte das Array als inaktiv an, was meiner Meinung nach bedeutete, dass es unmöglich das sein konnte, was die Laufwerke blockierte, aber das war tatsächlich nicht der Fall (ich hatte auch zuvor --stop ausgeführt, aber es schien, als wäre danach etwas passiert, das die Rückkehr in einen nicht gestoppten Zustand auslöste). Nachdem ich die Laufwerksreihenfolge richtig eingestellt hatte (nicht beim ersten Versuch, zum Glück habe ich Overlays verwendet), bestand das Array eine Fsck-Prüfung ohne gemeldete Fehler undläuft jetzt, als wäre nie etwas passiert.
Das Ergebnis der Ausführung anderer Diagnosebefehle:
Katze /proc/mdstat:
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10]
md1 : inactive sdh1[1](S) sde1[3](S) sdf1[0](S)
23440900500 blocks super 1.2
mdadm --detail /dev/md1:
/dev/md1:
Version : 1.2
Raid Level : raid0
Total Devices : 3
Persistence : Superblock is persistent
State : inactive
Working Devices : 3
Name : bob:1 (local to host bob)
UUID : 07ff9ba9:e8100e68:94c12c1a:3d7ad811
Events : 373364
Number Major Minor RaidDevice
- 8 113 - /dev/sdh1
- 8 81 - /dev/sdf1
- 8 65 - /dev/sde1
Zeilen erscheinen in dmesg beim Versuch,mdadm --assemblieren /dev/md1:
md/raid:md1: device sdh1 operational as raid disk 1
md/raid:md1: not enough operational devices (2/3 failed)
md/raid:md1: failed to run raid set.
md: pers->run() failed ..
und dasmdadm --untersuchenS
/dev/sde1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 07ff9ba9:e8100e68:94c12c1a:3d7ad811
Name : bob:1 (local to host bob)
Creation Time : Mon Mar 4 22:10:29 2019
Raid Level : raid5
Raid Devices : 3
Avail Dev Size : 15627267000 (7451.66 GiB 8001.16 GB)
Array Size : 15627266688 (14903.32 GiB 16002.32 GB)
Used Dev Size : 15627266688 (7451.66 GiB 8001.16 GB)
Data Offset : 261888 sectors
Super Offset : 8 sectors
Unused Space : before=261808 sectors, after=312 sectors
State : clean
Device UUID : e856f539:6a1b5822:b3b8bfb7:4d0f4741
Internal Bitmap : 8 sectors from superblock
Update Time : Sun May 30 00:22:45 2021
Bad Block Log : 512 entries available at offset 40 sectors
Checksum : 9b5703bc - correct
Events : 373364
Layout : left-symmetric
Chunk Size : 64K
Device Role : spare
Array State : .AA ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdf1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 07ff9ba9:e8100e68:94c12c1a:3d7ad811
Name : bob:1 (local to host bob)
Creation Time : Mon Mar 4 22:10:29 2019
Raid Level : raid5
Raid Devices : 3
Avail Dev Size : 15627267000 (7451.66 GiB 8001.16 GB)
Array Size : 15627266688 (14903.32 GiB 16002.32 GB)
Used Dev Size : 15627266688 (7451.66 GiB 8001.16 GB)
Data Offset : 261888 sectors
Super Offset : 8 sectors
Unused Space : before=261800 sectors, after=312 sectors
State : clean
Device UUID : 7919e56f:2e08430e:95a4c4a6:1e64606a
Internal Bitmap : 8 sectors from superblock
Update Time : Sun May 30 00:22:45 2021
Bad Block Log : 512 entries available at offset 72 sectors
Checksum : d54ff3e1 - correct
Events : 373364
Layout : left-symmetric
Chunk Size : 64K
Device Role : spare
Array State : .AA ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdh1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 07ff9ba9:e8100e68:94c12c1a:3d7ad811
Name : bob:1 (local to host bob)
Creation Time : Mon Mar 4 22:10:29 2019
Raid Level : raid5
Raid Devices : 3
Avail Dev Size : 15627267000 (7451.66 GiB 8001.16 GB)
Array Size : 15627266688 (14903.32 GiB 16002.32 GB)
Used Dev Size : 15627266688 (7451.66 GiB 8001.16 GB)
Data Offset : 261888 sectors
Super Offset : 8 sectors
Unused Space : before=261800 sectors, after=312 sectors
State : clean
Device UUID : 0c9a8237:7e79a439:d4e35b31:659f3c86
Internal Bitmap : 8 sectors from superblock
Update Time : Sun May 30 00:22:45 2021
Bad Block Log : 512 entries available at offset 72 sectors
Checksum : 6ec2604b - correct
Events : 373364
Layout : left-symmetric
Chunk Size : 64K
Device Role : Active device 1
Array State : .AA ('A' == active, '.' == missing, 'R' == replacing)
Antwort1
Es sieht seltsam aus. Möglicherweise müssen Siemdadm --create mit Overlaysfür dieses (mit korrektem Datenoffset, Blockgröße und Laufwerksreihenfolge). Und möglicherweise mit dem fehlenden ersten Laufwerk, da dieses anscheinend zuerst ausgefallen ist ...
Grundsätzlich gibt es keine Möglichkeit, mit herkömmlichen Mitteln eine Wiederherstellung durchzuführen, wenn sich ein Laufwerk nicht einmal mehr an seine Geräterolle erinnert. Beide geben an, dass sie „Ersatzlaufwerke“ sind, sodass nicht bekannt ist, ob eines der Laufwerke Rolle 0, Rolle 2 oder gar nichts war (einige RAID-5-Setups verwenden aus irgendeinem Grund tatsächlich Ersatzlaufwerke). Es ist also unklar, ob sich überhaupt nützliche Daten darauf befinden und wenn ja, in welcher Reihenfolge diese liegen. Das müssen Sie selbst herausfinden.
Überprüfen Sie bei dieser Gelegenheit auch die SMART-Daten und prüfen Sie ddrescuezunächst, ob eines dieser Laufwerke tatsächlich neu zugewiesene oder ausstehende Sektoren aufweist, die zum RAID-Fehler beigetragen haben könnten.