Ok, irgendetwas hat mich an Ihrem Problem gestört, also habe ich eine VM hochgefahren, um in das zu erwartende Verhalten einzutauchen. Ich komme gleich zu dem, was mich nervte. Lassen Sie mich zuerst folgendes sagen:
Sichern Sie diese Laufwerke, bevor Sie etwas unternehmen !!
Möglicherweise haben Sie bereits einen Schaden angerichtet, der über den durch die erneute Synchronisierung verursachten Schaden hinausgeht. Können Sie erklären, was Sie meinten, als Sie sagten:
Gemäß den Vorschlägen habe ich die Superblöcke aufgeräumt und das Array mit der Option --assume-clean neu erstellt, aber ohne Erfolg.
Wenn Sie eine ausgeführt haben mdadm --misc --zero-superblock, sollte es Ihnen gut gehen.
Auf jeden Fall sollten Sie einige neue Datenträger aufräumen und genaue aktuelle Bilder von ihnen abrufen, bevor Sie irgendetwas tun, das möglicherweise mehr Schreibzugriff auf diese Datenträger hat.
dd if=/dev/sdd of=/path/to/store/sdd.img
Davon abgesehen ... es sieht so aus, als ob Daten, die auf diesen Dingen gespeichert sind, schockierend widerstandsfähig gegenüber unberechenbaren Resynchronisierungen sind. Lesen Sie weiter, es gibt Hoffnung, und dies könnte der Tag sein, an dem ich die maximale Antwortlänge erreicht habe.
Das beste Szenario
Ich habe eine VM zusammengeschmissen, um Ihr Szenario neu zu erstellen. Die Laufwerke sind nur 100 MB groß, daher würde ich nicht ewig auf jede erneute Synchronisierung warten, aber dies sollte ansonsten eine ziemlich genaue Darstellung sein.
Bauen Sie das Array so generisch und standardmäßig wie möglich auf - 512-KB-Blöcke, links-symmetrisches Layout, Festplatten in Buchstabenreihenfolge. Nichts Besonderes.
root@test:~# mdadm --create /dev/md0 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md0 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid5 sdd1[3] sdc1[1] sdb1[0]
203776 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]
unused devices: <none>
So weit, ist es gut; Lassen Sie uns ein Dateisystem erstellen und einige Daten darauf ablegen.
root@test:~# mkfs.ext4 /dev/md0
mke2fs 1.41.14 (22-Dec-2010)
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
Stride=512 blocks, Stripe width=1024 blocks
51000 inodes, 203776 blocks
10188 blocks (5.00%) reserved for the super user
First data block=1
Maximum filesystem blocks=67371008
25 block groups
8192 blocks per group, 8192 fragments per group
2040 inodes per group
Superblock backups stored on blocks:
8193, 24577, 40961, 57345, 73729
Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 30 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
root@test:~# mkdir /mnt/raid5
root@test:~# mount /dev/md0 /mnt/raid5
root@test:~# echo "data" > /mnt/raid5/datafile
root@test:~# dd if=/dev/urandom of=/mnt/raid5/randomdata count=10000
10000+0 records in
10000+0 records out
5120000 bytes (5.1 MB) copied, 0.706526 s, 7.2 MB/s
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064 /mnt/raid5/randomdata
Okay. Wir haben ein Dateisystem und einige Daten ("data" in datafileund zufällige Daten im Wert von 5 MB mit diesem SHA1-Hash randomdata); Mal sehen, was passiert, wenn wir neu erstellen.
root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md0
mdadm: stopped /dev/md0
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
unused devices: <none>
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 21:07:06 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 21:07:06 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 21:07:06 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid5 sdd1[2] sdc1[1] sdb1[0]
203776 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]
unused devices: <none>
Die erneute Synchronisierung wurde mit diesen winzigen Datenträgern sehr schnell abgeschlossen, es ist jedoch aufgetreten. Also hier ist, was mich von früher nervte; Ihre fdisk -lAusgabe. mdEs wird erwartet, dass keine Partitionstabelle auf dem Gerät vorhanden ist. Ihr Dateisystem befindet sich direkt auf dem gefälschten Blockgerät ohne Partitionstabelle.
root@test:~# fdisk -l
...
Disk /dev/md1: 208 MB, 208666624 bytes
2 heads, 4 sectors/track, 50944 cylinders, total 407552 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 524288 bytes / 1048576 bytes
Disk identifier: 0x00000000
Disk /dev/md1 doesn't contain a valid partition table
Ja, keine Partitionstabelle. Aber...
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 12/51000 files, 12085/203776 blocks
Perfekt gültiges Dateisystem nach einer Resynchronisation. So ist das gut; Lassen Sie uns unsere Datendateien überprüfen:
root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064 /mnt/raid5/randomdata
Solide - überhaupt keine Datenbeschädigung! Dies ist jedoch mit genau den gleichen Einstellungen möglich, sodass zwischen den beiden RAID-Gruppen keine unterschiedlichen Zuordnungen vorgenommen wurden. Lassen Sie uns das Ding fallen, bevor wir versuchen, es zu zerbrechen.
root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md1
Einen Schritt zurücktreten
Bevor wir versuchen, dies zu brechen, wollen wir darüber sprechen, warum es schwierig ist, es zu brechen. RAID 5 verwendet einen Paritätsblock, der einen Bereich schützt, der genauso groß ist wie der Block auf jeder anderen Festplatte im Array. Die Parität ist nicht nur auf einer bestimmten Festplatte festgelegt, sondern wird gleichmäßig um die Festplatten gedreht, um die Leselast im normalen Betrieb besser auf die Festplatten zu verteilen.
Die XOR-Operation zur Berechnung der Parität sieht folgendermaßen aus:
DISK1 DISK2 DISK3 DISK4 PARITY
1 0 1 1 = 1
0 0 1 1 = 0
1 1 1 1 = 0
Die Parität ist also auf die Festplatten verteilt.
DISK1 DISK2 DISK3 DISK4 DISK5
DATA DATA DATA DATA PARITY
PARITY DATA DATA DATA DATA
DATA PARITY DATA DATA DATA
Eine erneute Synchronisierung wird normalerweise durchgeführt, wenn eine leere oder fehlende Festplatte ersetzt wird. Es wird auch mdadm createdarauf geachtet, dass die Daten auf den Datenträgern mit der RAID-Geometrie übereinstimmen. In diesem Fall ist der letzte Datenträger in der Array-Spezifikation derjenige, mit dem "synchronisiert" wird - alle vorhandenen Daten auf den anderen Datenträgern werden für die Synchronisierung verwendet.
Alle Daten auf der 'neuen' Festplatte werden gelöscht und neu erstellt. Entweder werden frische Datenblöcke aus Paritätsblöcken für das erstellt, was hätte vorhanden sein sollen, oder es werden frische Paritätsblöcke erstellt.
Was cool ist, ist, dass die Prozedur für diese beiden Dinge genau gleich ist: eine XOR-Operation über die Daten von den restlichen Festplatten. Der Resync-Prozess in diesem Fall kann in seinem Layout enthalten sein, dass ein bestimmter Block ein Paritätsblock sein sollte, und denkt, dass er einen neuen Paritätsblock erstellt, während er tatsächlich einen alten Datenblock neu erstellt. Also, selbst wenn es denkt , dass es das baut:
DISK1 DISK2 DISK3 DISK4 DISK5
PARITY DATA DATA DATA DATA
DATA PARITY DATA DATA DATA
DATA DATA PARITY DATA DATA
... es wird möglicherweise gerade DISK5aus dem obigen Layout wiederhergestellt.
Daher können Daten auch dann konsistent bleiben, wenn das Array falsch aufgebaut ist.
Werfen eines Affen in die Werke
(kein Schraubenschlüssel; der ganze Affe)
Test 1:
Lassen Sie uns das Array in der falschen Reihenfolge machen! sdcdann sdddann sdb..
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdc1 /dev/sdd1 /dev/sdb1
mdadm: /dev/sdc1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:06:34 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:06:34 2012
mdadm: /dev/sdb1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:06:34 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid5 sdb1[3] sdd1[1] sdc1[0]
203776 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]
unused devices: <none>
Ok, das ist alles schön und gut. Haben wir ein Dateisystem?
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/md1
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
Nee! Warum das? Denn während die Daten alle da sind, ist es in der falschen Reihenfolge; Was einmal 512 KB von A, dann 512 KB von B, A, B und so weiter war, wurde jetzt zu B, A, B, A gemischt. Die Festplatte sieht für den Dateisystem-Checker jetzt wie Dummkopf aus, sie wird nicht ausgeführt. Die Ausgabe von mdadm --misc -D /dev/md1gibt uns mehr Details; Es sieht aus wie das:
Number Major Minor RaidDevice State
0 8 33 0 active sync /dev/sdc1
1 8 49 1 active sync /dev/sdd1
3 8 17 2 active sync /dev/sdb1
Wann sollte es so aussehen:
Number Major Minor RaidDevice State
0 8 17 0 active sync /dev/sdb1
1 8 33 1 active sync /dev/sdc1
3 8 49 2 active sync /dev/sdd1
Also, das ist alles schön und gut. Wir haben dieses Mal eine ganze Reihe von Datenblöcken mit neuen Paritätsblöcken überschrieben. Erstellen Sie mit der richtigen Reihenfolge jetzt neu:
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:11:08 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:11:08 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:11:08 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 12/51000 files, 12085/203776 blocks
Ordentlich, da ist noch ein Dateisystem! Sie haben noch Daten?
root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064 /mnt/raid5/randomdata
Erfolg!
Test 2
Ok, lass uns die Chunk-Größe ändern und sehen, ob das uns etwas Zerbrechlichkeit bringt.
root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --create /dev/md1 --chunk=64 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:21:19 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:21:19 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:21:19 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/md1
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
Ja, ja, es ist abgespritzt, wenn es so aufgebaut ist. Aber können wir uns erholen?
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:21:51 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:21:51 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:21:51 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 12/51000 files, 12085/203776 blocks
root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064 /mnt/raid5/randomdata
Wieder Erfolg!
Test 3
Dies ist derjenige, von dem ich dachte, er würde Daten mit Sicherheit töten - lasst uns einen anderen Layout-Algorithmus ausführen!
root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --layout=right-asymmetric --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:32:34 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:32:34 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:32:34 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid5 sdd1[3] sdc1[1] sdb1[0]
203776 blocks super 1.2 level 5, 512k chunk, algorithm 1 [3/3] [UUU]
unused devices: <none>
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
fsck.ext4: Superblock invalid, trying backup blocks...
Superblock has an invalid journal (inode 8).
Beängstigend und schlimm - es glaubt, es hat etwas gefunden und will etwas reparieren! Ctrl+ C!
Clear<y>? cancelled!
fsck.ext4: Illegal inode number while checking ext3 journal for /dev/md1
Ok, Krise abgewendet. Mal sehen, ob die Daten nach dem erneuten Synchronisieren mit dem falschen Layout noch intakt sind:
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:33:02 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:33:02 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:33:02 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 12/51000 files, 12085/203776 blocks
root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064 /mnt/raid5/randomdata
Erfolg!
Test 4
Lassen Sie uns auch einfach beweisen, dass das Nullsetzen von Superblöcken nicht wirklich schädlich ist:
root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --misc --zero-superblock /dev/sdb1 /dev/sdc1 /dev/sdd1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 12/51000 files, 12085/203776 blocks
root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064 /mnt/raid5/randomdata
Ja, keine große Sache.
Test 5
Werfen wir einfach alles, was wir drauf haben. Alle 4 vorherigen Tests, kombiniert.
- Falsche Gerätereihenfolge
- Falsche Blockgröße
- Falscher Layout-Algorithmus
- Zeroed Superblocks (wir machen das zwischen beiden Kreationen)
Weiter!
root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --misc --zero-superblock /dev/sdb1 /dev/sdc1 /dev/sdd1
root@test:~# mdadm --create /dev/md1 --chunk=64 --level=5 --raid-devices=3 --layout=right-symmetric /dev/sdc1 /dev/sdd1 /dev/sdb1
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid5 sdb1[3] sdd1[1] sdc1[0]
204672 blocks super 1.2 level 5, 64k chunk, algorithm 3 [3/3] [UUU]
unused devices: <none>
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/md1
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
Das Urteil?
root@test:~# mdadm --misc --zero-superblock /dev/sdb1 /dev/sdc1 /dev/sdd1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid5 sdd1[3] sdc1[1] sdb1[0]
203776 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]
unused devices: <none>
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 13/51000 files, 17085/203776 blocks
root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064 /mnt/raid5/randomdata
Wow.
Es sieht also so aus, als ob durch keine dieser Aktionen Daten in irgendeiner Weise beschädigt wurden. Ehrlich gesagt war ich von diesem Ergebnis ziemlich überrascht; Ich erwartete moderate Datenverluste bei der Änderung der Blockgröße und deutliche Verluste bei der Layoutänderung. Ich habe heute etwas gelernt.
Also .. Wie bekomme ich meine Daten?
So viele Informationen wie Sie über das alte System haben, wären für Sie äußerst hilfreich. Wenn Sie den Dateisystemtyp kennen, alte Kopien /proc/mdstatmit Informationen zur Laufwerksreihenfolge, zum Algorithmus, zur Blockgröße und zur Metadatenversion vorliegen. Haben Sie die E-Mail-Benachrichtigungen von mdadm eingerichtet? Wenn ja, finde einen alten; Wenn nicht, überprüfen Sie /var/spool/mail/root. Überprüfen Sie ~/.bash_history, ob sich Ihr ursprünglicher Build dort befindet.
Also, die Liste der Dinge, die Sie tun sollten:
- Sichern Sie die Datenträger mit,
ddbevor Sie etwas tun !!
- Versuchen Sie es mit
fsckdem aktuellen, aktiven MD - Sie haben möglicherweise gerade in der gleichen Reihenfolge wie zuvor gebaut. Wenn Sie den Dateisystemtyp kennen, ist dies hilfreich. benutze dieses spezielle fsckWerkzeug. Wenn eines der Tools eine Lösung anbietet, lassen Sie es nicht zu, es sei denn, Sie sind sich sicher, dass tatsächlich das gültige Dateisystem gefunden wurde! Wenn ein fsckAngebot zur Behebung eines Problems für Sie vorliegt, können Sie einen Kommentar hinterlassen und fragen, ob dies tatsächlich hilfreich ist oder nur dazu dient, Daten zu vernichten.
- Versuchen Sie, das Array mit verschiedenen Parametern zu erstellen. Wenn Sie ein altes haben
/proc/mdstat, können Sie einfach nachahmen, was es zeigt; Wenn nicht, dann sind Sie ein bisschen im Dunkeln - es ist vernünftig, alle unterschiedlichen Laufwerksreihenfolgen auszuprobieren, aber es ist sinnlos, bei jeder möglichen Bestellung jede mögliche Blockgröße zu überprüfen. Für jeden ist fsckes zu sehen, ob Sie etwas Vielversprechendes bekommen.
Das ist es also. Entschuldigung für den Roman, bitte hinterlasse einen Kommentar, falls du Fragen hast, und viel Glück!
Fußnote: unter 22 Tausend Zeichen; 8k + schüchtern von der Längenbeschränkung