Leute, bitte helfen Sie - ich bin ein Neuling mit starken Kopfschmerzen (perfekte Sturmsituation).

Ich habe eine 3 1-TB-Festplatte auf meinem Ubuntu 11.04 als Software-RAID 5 konfiguriert. Die Daten wurden wöchentlich auf eine andere, vom Computer getrennte Festplatte kopiert, bis dies vollständig fehlschlug und weggeworfen wurde. Vor ein paar Tagen hatten wir einen Stromausfall und nach dem Neustart meiner Box würde der Überfall nicht stattfinden. In meiner unendlichen Weisheit trat ich ein

mdadm --create -f...

befehl statt

mdadm --assemble

und bemerkte nicht die Travestie, die ich bis danach getan hatte. Das Array wurde heruntergefahren und es wurde erstellt und synchronisiert, was ~ 10 Stunden dauerte. Nachdem ich zurück war, habe ich festgestellt, dass das Array erfolgreich funktioniert, der Raid jedoch nicht

Ich meine, die einzelnen Laufwerke sind partitioniert (Partitionstyp f8), das md0Gerät jedoch nicht. Mit Entsetzen realisiere ich, was ich getan habe und versuche, einige Lösungen zu finden. Ich bete nur, dass --createnicht der gesamte Inhalt des Festplattenfahrers überschrieben wurde.

Könnte mir BITTE jemand dabei helfen - die Daten auf dem Laufwerk sind sehr wichtig und einzigartig ~ 10 Jahre Fotos, Dokumente usw.

Ist es möglich, dass durch Angabe der beteiligten Festplatten in falscher Reihenfolge diese mdadmüberschrieben werden können? wenn ich es tue

mdadm --examine --scan 

Ich bekomme so etwas wie ARRAY /dev/md/0 metadata=1.2 UUID=f1b4084a:720b5712:6d03b9e9:43afe51b name=<hostname>:0

Interessanterweise war der Name früher 'raid' und nicht der Host hame mit: 0 angehängt.

Hier sind die 'bereinigten' Konfigurationseinträge:

DEVICE /dev/sdf1 /dev/sde1 /dev/sdd1

CREATE owner=root group=disk mode=0660 auto=yes

HOMEHOST <system>

MAILADDR root


ARRAY /dev/md0 metadata=1.2 name=tanserv:0 UUID=f1b4084a:720b5712:6d03b9e9:43afe51b


Here is the output from mdstat

cat /proc/mdstat 
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
md0 : active raid5 sdd1[0] sdf1[3] sde1[1]
1953517568 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]

unused devices: <none>


fdisk shows the following:

fdisk -l

Disk /dev/sda: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000bf62e

Device Boot Start End Blocks Id System
/dev/sda1 * 1 9443 75846656 83 Linux
/dev/sda2 9443 9730 2301953 5 Extended
/dev/sda5 9443 9730 2301952 82 Linux swap / Solaris

Disk /dev/sdb: 750.2 GB, 750156374016 bytes
255 heads, 63 sectors/track, 91201 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000de8dd

Device Boot Start End Blocks Id System
/dev/sdb1 1 91201 732572001 8e Linux LVM

Disk /dev/sdc: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00056a17

Device Boot Start End Blocks Id System
/dev/sdc1 1 60801 488384001 8e Linux LVM

Disk /dev/sdd: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000ca948

Device Boot Start End Blocks Id System
/dev/sdd1 1 121601 976760001 fd Linux raid autodetect

Disk /dev/dm-0: 1250.3 GB, 1250254913536 bytes
255 heads, 63 sectors/track, 152001 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Disk /dev/dm-0 doesn't contain a valid partition table

Disk /dev/sde: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x93a66687

Device Boot Start End Blocks Id System
/dev/sde1 1 121601 976760001 fd Linux raid autodetect

Disk /dev/sdf: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xe6edc059

Device Boot Start End Blocks Id System
/dev/sdf1 1 121601 976760001 fd Linux raid autodetect

Disk /dev/md0: 2000.4 GB, 2000401989632 bytes
2 heads, 4 sectors/track, 488379392 cylinders
Units = cylinders of 8 * 512 = 4096 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 524288 bytes / 1048576 bytes
Disk identifier: 0x00000000

Disk /dev/md0 doesn't contain a valid partition table

Gemäß den Vorschlägen habe ich die Superblöcke aufgeräumt und das Array mit der --assume-cleanOption neu erstellt, aber ohne Glück.

Gibt es ein Tool, mit dem ich zumindest einige der Daten wiederbeleben kann? Kann mir jemand sagen, was und wie mdadm --create bei der Synchronisierung vorgeht, um die Daten zu zerstören, damit ich ein Tool schreiben kann, mit dem ich das, was getan wurde, wieder rückgängig machen kann?

Nach der Neuerstellung des Raids starte ich fsck.ext4 / dev / md0 und hier ist die Ausgabe

root @ tanserv: / etc / mdadm # fsck.ext4 / dev / md0 e2fsck 1.41.14 (22.12.2010) fsck.ext4: Superblock ungültig, Sicherungsblöcke werden versucht ... fsck.ext4: Ungültige magische Nummer in Super- Block beim Versuch, / dev / md0 zu öffnen

Der Superblock konnte nicht gelesen werden oder beschreibt kein korrektes ext2-Dateisystem. Wenn das Gerät gültig ist und wirklich ein ext2-Dateisystem enthält (und nicht Swap oder UFS oder etwas anderes), ist der Superblock beschädigt, und Sie können versuchen, e2fsck mit einem alternativen Superblock auszuführen: e2fsck -b 8193

Per Shanes Vorschlag habe ich versucht

root@tanserv:/home/mushegh# mkfs.ext4 -n /dev/md0
mke2fs 1.41.14 (22-Dec-2010)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=128 blocks, Stripe width=256 blocks
122101760 inodes, 488379392 blocks
24418969 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=0
14905 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks: 
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
    4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 
    102400000, 214990848

Führen Sie fsck.ext4 mit jedem Sicherungsblock aus, aber alle haben Folgendes zurückgegeben:

root@tanserv:/home/mushegh# fsck.ext4 -b 214990848 /dev/md0
e2fsck 1.41.14 (22-Dec-2010)
fsck.ext4: Invalid argument while trying to open /dev/md0

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>

Irgendwelche Vorschläge?

Grüße!

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:

1. Sichern Sie die Datenträger mit, ddbevor Sie etwas tun !!
2. 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.
3. 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

Wenn Sie Glück haben, haben Sie möglicherweise Erfolg, wenn Sie Ihre Dateien mit einer Wiederherstellungssoftware wiederherstellen, die ein defektes RAID-5-Array lesen kann. Zero Assumption Recovery ist eine, mit der ich schon einmal erfolgreich war.

Ich bin mir jedoch nicht sicher, ob beim Erstellen eines neuen Arrays alle Daten zerstört wurden. Dies könnte also die letzte Chance sein.

Ich hatte ein ähnliches Problem:
Nach einem Ausfall eines Software-RAID5-Arrays habe ich mdadm --createohne Angabe des Arrays ausgelöst --assume-cleanund konnte das Array nicht mehr mounten. Nach zwei Wochen des Grabens habe ich endlich alle Daten wiederhergestellt. Ich hoffe, dass das folgende Verfahren jemandem Zeit spart.

Um es kurz zu machen

Das Problem wurde durch die Tatsache verursacht, dass mdadm --createein neues Array erstellt wurde, das sich in zwei Punkten vom Original unterscheidet:

• andere Reihenfolge der Partitionen
• Unterschiedlicher RAID-Datenversatz

Wie es in der brillanten gezeigte Antwort von Shane Madden , mdadm --createzerstört nicht die Daten in den meisten Fällen! Nachdem ich die Partitionsreihenfolge und den Datenoffset gefunden hatte, konnte ich das Array wiederherstellen und alle Daten daraus extrahieren.

Voraussetzungen

Ich hatte keine Backups von RAID-Superblöcken, daher wusste ich nur, dass es sich um ein RAID5-Array auf 8 Partitionen handelte, das während der Installation von Xubuntu 12.04.0 erstellt wurde. Es hatte ein ext4-Dateisystem. Ein weiteres wichtiges Wissen war eine Kopie einer Datei, die ebenfalls auf dem RAID-Array gespeichert war.

Werkzeuge

Für die gesamte Arbeit wurde die Live-CD Xubuntu 12.04.1 verwendet. Abhängig von Ihrer Situation benötigen Sie möglicherweise einige der folgenden Tools:

Version von mdadm, mit der Datenoffset angegeben werden kann

sudo apt-get install binutils-dev git
git clone -b data_offset git://neil.brown.name/mdadm
cd mdadm
make

bgrep - Suche nach binären Daten

curl -L 'https://github.com/tmbinc/bgrep/raw/master/bgrep.c' | gcc -O2 -x c -o bgrep -

hexdump, e2fsck, mount und ein hexadezimaler Rechner - Standardwerkzeuge von repos

Beginnen Sie mit der vollständigen Sicherung

Die Benennung von Gerätedateien, z /dev/sda2 /dev/sdb2. B. usw., ist nicht dauerhaft. Notieren Sie sich daher die Seriennummern Ihrer Laufwerke, die von angegeben werden

sudo hdparm -I /dev/sda

Schließen Sie dann eine externe Festplatte an und sichern Sie jede Partition Ihres RAID-Arrays wie folgt:

sudo dd if=/dev/sda2 bs=4M | gzip > serial-number.gz

Bestimmen Sie das ursprüngliche RAID5-Layout

Hier werden verschiedene Layouts beschrieben: http://www.accs.com/p_and_p/RAID/LinuxRAID.html
Um herauszufinden, wie Datenstreifen im ursprünglichen Array organisiert waren, benötigen Sie eine Kopie einer zufällig aussehenden Datei, von der Sie wissen, dass sie vorhanden ist auf dem Array gespeichert. Die derzeit von verwendete Standardblockgröße mdadmist 512 KB. Für ein Array von N Partitionen benötigen Sie eine Datei mit einer Größe von mindestens (N + 1) * 512 KB. Ein JPEG oder Video ist gut, da es relativ eindeutige Teilfolgen von Binärdaten liefert. Angenommen, unsere Datei heißt picture.jpg. Wir lesen 32 Datenbytes an N + 1 Positionen ab 100k und inkrementieren um 512k:

hexdump -n32 -s100k -v -e '/1 "%02X"' picture.jpg ; echo
DA1DC4D616B1C71079624CDC36E3D40E7B1CFF00857C663687B6C4464D6C77D2
hexdump -n32 -s612k -v -e '/1 "%02X"' picture.jpg ; echo
AB9DDDBBB05CA915EE2289E59A116B02A26C82C8A8033DD8FA6D06A84B6501B7
hexdump -n32 -s1124k -v -e '/1 "%02X"' picture.jpg ; echo
BC31A8DC791ACDA4FA3E9D3406D5639619576AEE2E08C03C9EF5E23F0A7C5CBA
...

Wir suchen dann nach Vorkommen all dieser Bytestrings auf all unseren Raw-Partitionen, also insgesamt (N + 1) * N Befehle, wie folgt:

sudo ./bgrep DA1DC4D616B1C71079624CDC36E3D40E7B1CFF00857C663687B6C4464D6C77D2 /dev/sda2
sudo ./bgrep DA1DC4D616B1C71079624CDC36E3D40E7B1CFF00857C663687B6C4464D6C77D2 /dev/sdb2
...
sudo ./bgrep DA1DC4D616B1C71079624CDC36E3D40E7B1CFF00857C663687B6C4464D6C77D2 /dev/sdh2
/dev/sdh2: 52a7ff000
sudo ./bgrep AB9DDDBBB05CA915EE2289E59A116B02A26C82C8A8033DD8FA6D06A84B6501B7 /dev/sda2
/dev/sdb2: 52a87f000
...

Diese Befehle können für verschiedene Festplatten parallel ausgeführt werden. Der Scan einer 38-GB-Partition dauerte ca. 12 Minuten. In meinem Fall wurde jede 32-Byte-Zeichenfolge nur einmal unter allen acht Laufwerken gefunden. Durch Vergleichen der von bgrep zurückgegebenen Offsets erhalten Sie ein Bild wie das folgende:

| offset \ partition | b | d | c | e | f | g | a | h |
|--------------------+---+---+---+---+---+---+---+---|
| 52a7ff000          | P |   |   |   |   |   |   | 1 |
| 52a87f000          | 2 | 3 | 4 | 5 | 6 | 7 | 8 | P |
| 52a8ff000          |   |   |   |   |   |   | P | 9 |

Wir sehen ein normales links-symmetrisches Layout, das standardmäßig für verwendet wird mdadm. Noch wichtiger ist, dass wir jetzt die Reihenfolge der Partitionen kennen. Wir wissen jedoch nicht, welche Partition die erste im Array ist, da sie zyklisch verschoben werden können.

Beachten Sie auch den Abstand zwischen gefundenen Offsets. In meinem Fall waren es 512 KB. Die Blockgröße kann tatsächlich kleiner als dieser Abstand sein. In diesem Fall unterscheidet sich das tatsächliche Layout.

Finden Sie die ursprüngliche Blockgröße

Wir verwenden dieselbe Datei picture.jpg, um 32 Datenbytes in unterschiedlichen Intervallen voneinander zu lesen. Wir wissen von oben, dass die Daten bei Versatz 100k auf /dev/sdh2, bei Versatz 612k auf /dev/sdb2und bei 1124k auf liegen /dev/sdd2. Dies zeigt, dass die Blockgröße nicht größer als 512 KB ist. Wir stellen sicher, dass es nicht kleiner als 512 KB ist. Dazu geben wir den Bytestring bei Offset 356k aus und schauen, auf welcher Partition er sich befindet:

hexdump -n32 -s356k -v -e '/1 "%02X"' P1080801.JPG ; echo
7EC528AD0A8D3E485AE450F88E56D6AEB948FED7E679B04091B031705B6AFA7A
sudo ./bgrep 7EC528AD0A8D3E485AE450F88E56D6AEB948FED7E679B04091B031705B6AFA7A /dev/sdb2
/dev/sdb2: 52a83f000

Es befindet sich auf derselben Partition wie Offset 612 KB, was darauf hinweist, dass die Blockgröße nicht 256 KB beträgt. In ähnlicher Weise eliminieren wir kleinere Chunk-Größen. Am Ende waren 512-KB-Blöcke die einzige Möglichkeit.

Finden Sie die erste Partition im Layout

Jetzt kennen wir die Reihenfolge der Partitionen, aber wir wissen nicht, welche Partition die erste sein soll und welcher RAID-Datenoffset verwendet wurde. Um diese beiden Unbekannten zu finden, erstellen wir ein RAID5-Array mit korrektem Chunk-Layout und kleinem Datenoffset und suchen in diesem neuen Array nach dem Anfang unseres Dateisystems.

Zunächst erstellen wir ein Array mit der richtigen Reihenfolge der Partitionen, die wir zuvor gefunden haben:

sudo mdadm --stop /dev/md126
sudo mdadm --create /dev/md126 --assume-clean --raid-devices=8 --level=5  /dev/sdb2 /dev/sdd2 /dev/sdc2 /dev/sde2 /dev/sdf2 /dev/sdg2 /dev/sda2 /dev/sdh2

Wir überprüfen, dass die Bestellung durch Erteilung eingehalten wird

sudo mdadm --misc -D /dev/md126
...
Number   Major   Minor   RaidDevice State
   0       8       18        0      active sync   /dev/sdb2
   1       8       50        1      active sync   /dev/sdd2
   2       8       34        2      active sync   /dev/sdc2
   3       8       66        3      active sync   /dev/sde2
   4       8       82        4      active sync   /dev/sdf2
   5       8       98        5      active sync   /dev/sdg2
   6       8        2        6      active sync   /dev/sda2
   7       8      114        7      active sync   /dev/sdh2

Nun bestimmen wir die Offsets der N + 1 bekannten Bytestrings im RAID-Array. Ich starte ein Skript für eine Nacht (Live CD fragt nicht nach dem Passwort für sudo :):

#!/bin/bash
echo "1st:"
sudo ./bgrep DA1DC4D616B1C71079624CDC36E3D40E7B1CFF00857C663687B6C4464D6C77D2 /dev/md126
echo "2nd:"
sudo ./bgrep AB9DDDBBB05CA915EE2289E59A116B02A26C82C8A8033DD8FA6D06A84B6501B7 /dev/md126
echo "3rd:"
sudo ./bgrep BC31A8DC791ACDA4FA3E9D3406D5639619576AEE2E08C03C9EF5E23F0A7C5CBA /dev/md126
...
echo "9th:"
sudo ./bgrep 99B5A96F21BB74D4A630C519B463954EC096E062B0F5E325FE8D731C6D1B4D37 /dev/md126

Ausgabe mit Kommentaren:

1st:
/dev/md126: 2428fff000 # 1st
2nd:
/dev/md126: 242947f000 # 480000 after 1st
3rd:                   # 3rd not found
4th:
/dev/md126: 242917f000 # 180000 after 1st
5th:
/dev/md126: 24291ff000 # 200000 after 1st
6th:
/dev/md126: 242927f000 # 280000 after 1st
7th:
/dev/md126: 24292ff000 # 300000 after 1st
8th:
/dev/md126: 242937f000 # 380000 after 1st
9th:
/dev/md126: 24297ff000 # 800000 after 1st

Basierend auf diesen Daten sehen wir, dass der 3. String nicht gefunden wurde. Dies bedeutet, dass der Block at /dev/sdd2für die Parität verwendet wird. Hier ist eine Darstellung der Paritätspositionen im neuen Array:

| offset \ partition | b | d | c | e | f | g | a | h |
|--------------------+---+---+---+---+---+---+---+---|
| 52a7ff000          |   |   | P |   |   |   |   | 1 |
| 52a87f000          | 2 | P | 4 | 5 | 6 | 7 | 8 |   |
| 52a8ff000          | P |   |   |   |   |   |   | 9 |

Unser Ziel ist es herauszufinden, von welcher Partition aus das Array gestartet werden soll, um die Paritätsblöcke an die richtige Stelle zu verschieben. Da die Parität um zwei Abschnitte nach links verschoben werden sollte, sollte die Partitionssequenz um zwei Schritte nach rechts verschoben werden. Das korrekte Layout für diesen Datenoffset lautet also ahbdcefg:

sudo mdadm --stop /dev/md126
sudo mdadm --create /dev/md126 --assume-clean --raid-devices=8 --level=5  /dev/sda2 /dev/sdh2 /dev/sdb2 /dev/sdd2 /dev/sdc2 /dev/sde2 /dev/sdf2 /dev/sdg2 

Zu diesem Zeitpunkt enthält unser RAID-Array Daten in der richtigen Form. Sie können sich glücklich schätzen, dass der RAID-Datenoffset mit dem des ursprünglichen Arrays identisch ist und Sie die Partition dann höchstwahrscheinlich einbinden können. Leider war das nicht mein Fall.

Überprüfen Sie die Datenkonsistenz

Wir überprüfen, ob die Daten über einen Streifen von Blöcken konsistent sind, indem wir eine Kopie von picture.jpgaus dem Array extrahieren . Dazu lokalisieren wir den Offset für die 32-Byte-Zeichenfolge bei 100k:

sudo ./bgrep DA1DC4D616B1C71079624CDC36E3D40E7B1CFF00857C663687B6C4464D6C77D2 /dev/md126

Wir subtrahieren dann 100 * 1024 vom Ergebnis und verwenden den erhaltenen Dezimalwert im skip=Parameter für dd. Das count=ist die Größe picture.jpgin Bytes:

sudo dd if=/dev/md126 of=./extract.jpg bs=1 skip=155311300608 count=4536208

Stellen Sie sicher, dass dies extract.jpgdasselbe ist wie picture.jpg.

Suchen Sie den RAID-Datenoffset

Eine Randnotiz: Der Standard-Datenoffset für mdadmVersion 3.2.3 beträgt 2048 Sektoren. Dieser Wert wurde jedoch im Laufe der Zeit geändert. Wenn das ursprüngliche Array einen kleineren Datenoffset als das aktuelle verwendet mdadm, kann mdadm --createohne --assume-cleanden Anfang des Dateisystems überschrieben werden.

Im vorherigen Abschnitt haben wir ein RAID-Array erstellt. Überprüfen Sie den RAID-Datenoffset, indem Sie für einige der einzelnen Partitionen Folgendes ausgeben:

sudo mdadm --examine /dev/sdb2
...
    Data Offset : 2048 sectors
...

2048 512-Byte-Sektoren haben eine Größe von 1 MB. Da die Blockgröße 512 KB beträgt, beträgt der aktuelle Datenoffset zwei Blöcke.

Wenn Sie zu diesem Zeitpunkt einen Versatz von zwei Teilen haben, ist dieser wahrscheinlich klein genug, und Sie können diesen Absatz überspringen.
Wir erstellen ein RAID5-Array mit dem Datenoffset eines 512-KB-Blocks. Wenn Sie einen Block früher beginnen, wird die Parität um einen Schritt nach links verschoben. Dies wird durch Verschieben der Partitionssequenz um einen Schritt nach links ausgeglichen. Daher ist für 512 KB Datenversatz das richtige Layout hbdcefga. Wir verwenden eine Version mdadm, die Datenoffset unterstützt (siehe Abschnitt Tools). Es dauert in Kilobyte versetzt:

sudo mdadm --stop /dev/md126
sudo ./mdadm --create /dev/md126 --assume-clean --raid-devices=8 --level=5  /dev/sdh2:512 /dev/sdb2:512 /dev/sdd2:512 /dev/sdc2:512 /dev/sde2:512 /dev/sdf2:512 /dev/sdg2:512 /dev/sda2:512

Jetzt suchen wir nach einem gültigen ext4-Superblock. Die Superblock-Struktur finden Sie hier: https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#The_Super_Block
Wir durchsuchen den Anfang des Arrays nach Vorkommen der magischen Zahl, s_magicgefolgt von s_stateund s_errors. Die zu suchenden Bytestrings sind:

53EF01000100
53EF00000100
53EF02000100
53EF01000200
53EF02000200

Beispielbefehl:

sudo ./bgrep 53EF01000100 /dev/md126
/dev/md126: 0dc80438

Die magische Zahl beginnt 0x38 Bytes im Superblock, also subtrahieren wir 0x38, um den Offset zu berechnen und den gesamten Superblock zu untersuchen:

sudo hexdump -n84 -s0xDC80400 -v /dev/md126
dc80400 2000 00fe 1480 03f8 cdd3 0032 d2b2 0119
dc80410 ab16 00f7 0000 0000 0002 0000 0002 0000
dc80420 8000 0000 8000 0000 2000 0000 b363 51bd
dc80430 e406 5170 010d ffff ef53 0001 0001 0000
dc80440 3d3a 50af 0000 0000 0000 0000 0001 0000
dc80450 0000 0000                              

Dies scheint ein gültiger Superblock zu sein. s_log_block_sizeDas Feld bei 0x18 ist 0002, was bedeutet, dass die Blockgröße 2 ^ (10 + 2) = 4096 Bytes beträgt. s_blocks_count_lobei 0x4 ist 03f81480 Blöcke, die 254 GB ist. Sieht gut aus.

Wir suchen nun nach den Vorkommen der ersten Bytes des Superblocks, um seine Kopien zu finden. Beachten Sie das Umkehren des Bytes im Vergleich zur Hexdump-Ausgabe:

sudo ./bgrep 0020fe008014f803d3cd3200 /dev/md126
/dev/md126: 0dc80400    # offset by 1024 bytes from the start of the FS        
/dev/md126: 15c80000    # 32768 blocks from FS start
/dev/md126: 25c80000    # 98304
/dev/md126: 35c80000    # 163840
/dev/md126: 45c80000    # 229376
/dev/md126: 55c80000    # 294912
/dev/md126: d5c80000    # 819200
/dev/md126: e5c80000    # 884736
/dev/md126: 195c80000
/dev/md126: 295c80000

Dies passt perfekt zu den erwarteten Positionen von Backup-Superblöcken:

sudo mke2fs -n /dev/md126
...
Block size=4096 (log=2)
...
Superblock backups stored on blocks: 
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
    4096000, 7962624, 11239424, 20480000, 23887872

Daher startet das Dateisystem beim Offset 0xdc80000, dh 225792 KB vom Partitionsstart. Da wir 8 Partitionen haben, von denen eine für die Parität ist, teilen wir den Versatz durch 7. Dies ergibt einen Versatz von 33030144 Bytes auf jeder Partition, was genau 63 RAID-Chunks entspricht. Und da der aktuelle RAID-Datenversatz ein Block ist, folgern wir, dass der ursprüngliche Datenversatz 64 Blöcke oder 32768 KB betrug. Eine hbdcefga63-fache Verschiebung nach rechts ergibt das Layout bdcefgah.

Wir bauen endlich das richtige RAID-Array:

sudo mdadm --stop /dev/md126
sudo ./mdadm --create /dev/md126 --assume-clean --raid-devices=8 --level=5  /dev/sdb2:32768 /dev/sdd2:32768 /dev/sdc2:32768 /dev/sde2:32768 /dev/sdf2:32768 /dev/sdg2:32768 /dev/sda2:32768 /dev/sdh2:32768
sudo fsck.ext4 -n /dev/md126
e2fsck 1.42 (29-Nov-2011)
Warning: skipping journal recovery because doing a read-only filesystem check.
/dev/md126: clean, 423146/16654336 files, 48120270/66589824 blocks
sudo mount -t ext4 -r /dev/md126 /home/xubuntu/mp

Voilà!

Ich hatte ein ähnliches Problem. Ich habe mein OS / Boot-Laufwerk mit einer Neuinstallation von Ubuntu 12.04 formatiert und neu installiert, dann habe ich den Befehl mdadm --create ... ausgeführt und konnte es nicht mounten.

Es hieß, es habe keinen gültigen Superblock oder keine Partition.

Darüber hinaus konnte ich das normale Gerät nicht mehr mounten, als ich den mdadm-Raid stoppte.

Ich konnte den Superblock mit mke2fs und e2fsck reparieren:

root@blackbox:~# mke2fs -n /dev/sdc1
mke2fs 1.42 (29-Nov-2011)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
91578368 inodes, 366284000 blocks
18314200 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
11179 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks: 
  32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
  4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 
  102400000, 214990848

Dann lief:

e2fsck -b 32768 -y /dev/sdc1

Dadurch wurde der Superblock wiederhergestellt, sodass ich das Laufwerk einbinden und lesen konnte.

Damit das Array funktioniert, ohne den Superblock oder die Partitionen zu zerstören, die ich erstellt habe:

mdadm --build /dev/md0 --level=mirror --assume-clean --raid-devices=2  /dev/sdc1 missing 

Nach der Überprüfung der Daten werde ich das andere Laufwerk hinzufügen:

mdadm --add /dev/md0 /sdd1

Ich aktualisiere nur einige der zuvor gegebenen Informationen. Ich hatte ein RAID5-Array mit 3 Festplatten, das einwandfrei funktionierte, als mein Motherboard starb. Das Array enthielt / dev / md2 als / home-Partition mit 1,2 TB und / dev / md3 als / var-Partition mit 300 GB.

Ich hatte zwei Backups von "wichtigen" Sachen und ein paar zufällige Dinge, die ich aus verschiedenen Teilen des Internets geholt hatte, die ich eigentlich hätte durchmachen und selektiv wegwerfen sollen. Die meisten Backups wurden in .tar.gz-Dateien mit maximal 25 GB aufgeteilt, und eine separate Kopie von / etc wurde ebenfalls gesichert.

Der Rest des Dateisystems befand sich auf zwei kleinen RAID0-Festplatten mit 38 GB.

Mein neuer Computer ähnelte der alten Hardware, und ich brachte den Computer zum Laufen, indem ich einfach alle fünf Festplatten einsteckte und einen alten generischen Kernel auswählte. Also hatte ich fünf Festplatten mit sauberen Dateisystemen, obwohl ich nicht sicher sein konnte, ob die Festplatten in der richtigen Reihenfolge waren, und musste eine neue Version von Debian Jessie installieren, um sicherzugehen, dass ich die Maschine bei Bedarf aktualisieren und andere sortieren konnte Probleme.

Nachdem das neue generische System auf zwei Raid0-Festplatten installiert war, begann ich, die Arrays wieder zusammenzusetzen. Ich wollte sichergehen, dass ich die Datenträger in der richtigen Reihenfolge hatte. Was ich hätte tun sollen, war folgendes herauszugeben:

mdadm --assemble /dev/md3 -o --no-degraded --uuid=82164ae7:9af3c5f1:f75f70a5:ba2a159a

Aber ich habe es nicht getan. Es scheint, dass mdadm ziemlich schlau ist und mit einer UUID herausfinden kann, welche Laufwerke wohin führen. Auch wenn das BIOS / dev / sdc als / sda bezeichnet, setzt mdadm es korrekt zusammen (obwohl YMMV).

Stattdessen gab ich mdadm --create /dev/md2 without the --assume-cleanFolgendes aus: und erlaubte dem Resync auf / dev / sde1, den Vorgang abzuschließen. Der nächste Fehler, den ich gemacht habe, war, auf / dev / sdc1 anstatt auf dem letzten Laufwerk in / dev / md2 / sde1 zu arbeiten. Immer wenn mdadm denkt, dass es ein Problem gibt, wird das letzte Laufwerk rausgeschmissen oder neu synchronisiert.

Danach konnte mdadm keinen Superblock mehr finden und e2fsck -n auch nicht.

Nachdem ich diese Seite gefunden habe, habe ich versucht, die Reihenfolge der Laufwerke zu finden (fertig), nach gültigen Daten zu suchen (überprüft 6 MB einer 9-MB-Datei), die Datenträger in der richtigen Reihenfolge abgerufen, die UUIDs abgerufen von / md2 und / md3 aus der alten /etc/mdadm.conf und versuchten das Assemblieren.

Nun, /dev/md3begann und mdadm --misc -D /dev/md3zeigte drei gesunde Partitionen und die Festplatten in der richtigen Reihenfolge. /dev/md2sah auch gut aus, bis ich versuchte, das Dateisystem zu mounten.

# mdadm --create /dev/md2 --raid-devices=3 --level=5 --uuid=c0a644c7:e5bcf758:ecfbc8f3:ee0392b7 /dev/sdc1 /dev/sdd1 /dev/sde1
mdadm: /dev/sdc1 appears to be part of a raid array:
       level=raid5 devices=3 ctime=Wed Feb  3 14:05:36 2016
mdadm: /dev/sdd1 appears to contain an ext2fs file system
       size=585936896K  mtime=Thu Jan  1 01:00:00 1970
mdadm: /dev/sdd1 appears to be part of a raid array:
       level=raid5 devices=3 ctime=Wed Feb  3 14:05:36 2016
mdadm: /dev/sde1 appears to contain an ext2fs file system
       size=585936896K  mtime=Thu Jan  1 01:00:00 1970
mdadm: /dev/sde1 appears to be part of a raid array:
       level=raid5 devices=3 ctime=Wed Feb  3 14:05:36 2016
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md2 started.

Das Dateisystem konnte nicht gemountet werden und e2fsck konnte keine Superblöcke finden. Bei der Überprüfung auf Superblöcke, wie oben beschrieben, stimmte die Gesamtblockanzahl von a880 0076 oder a880 0076 oder 5500 1176 nicht mit der Festplattenkapazität von 1199,79 überein, die von meinem mdadm gemeldet wurde. Auch keiner der Standorte der "Superblöcke" stimmte mit den Daten in den obigen Beiträgen überein.

Ich habe die gesamte Datei / var gesichert und mich darauf vorbereitet, die Datenträger zu löschen. Um zu sehen, ob es möglich war, nur / md2 zu löschen (ich hatte zu diesem Zeitpunkt nichts anderes zu verlieren), dis ich Folgendes:

root@ced2:/home/richard# mdadm --create /dev/md2 --raid-devices=3 --level=5 --uuid=c0a644c7:e5bcf758:ecfbc8f3:ee0392b7 /dev/sdc1 /dev/sdd1 /dev/sde1
mdadm: /dev/sdc1 appears to be part of a raid array:
       level=raid5 devices=3 ctime=Wed Feb  3 14:05:36 2016
mdadm: /dev/sdd1 appears to contain an ext2fs file system
       size=585936896K  mtime=Thu Jan  1 01:00:00 1970
mdadm: /dev/sdd1 appears to be part of a raid array:
       level=raid5 devices=3 ctime=Wed Feb  3 14:05:36 2016
mdadm: /dev/sde1 appears to contain an ext2fs file system
       size=585936896K  mtime=Thu Jan  1 01:00:00 1970
mdadm: /dev/sde1 appears to be part of a raid array:
       level=raid5 devices=3 ctime=Wed Feb  3 14:05:36 2016
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md2 started.
# mkfs.ext3 /dev/md2
mke2fs 1.42.12 (29-Aug-2014)
Creating filesystem with 292902912 4k blocks and 73228288 inodes
Filesystem UUID: a54e252f-78db-4ebb-b7ca-7dcd2edf57a4
Superblock backups stored on blocks: 
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
    4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 
    102400000, 214990848

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done 


# hexdump -n84 -s0x00000400 -v /dev/md2
0000400 6000 045d 5800 1175 7799 00df 6ff0 112e
0000410 5ff5 045d 0000 0000 0002 0000 0002 0000
0000420 8000 0000 8000 0000 2000 0000 10d3 56b2
0000430 10d3 56b2 0002 ffff ef53 0001 0001 0000
0000440 0c42 56b2 0000 0000 0000 0000 0001 0000
0000450 0000 0000                              
0000454

#  ./bgrep 00605D0400587511 /dev/md2
/dev/md2: 00000400
/dev/md2: 08000000
/dev/md2: 18000000
/dev/md2: 28000000
/dev/md2: 38000000
/dev/md2: 48000000
/dev/md2: c8000000
/dev/md2: d8000000
/dev/md2: 188000000
/dev/md2: 288000000
/dev/md2: 3e8000000
/dev/md2: 798000000
/dev/md2: ab8000000
etc

Alles schien in Ordnung, bis auf die Änderung der UUID. Nach ein paar weiteren Überprüfungen habe ich 600 GB an gesicherten Daten auf / dev / md2 geschrieben. Anschließend wurde das Laufwerk abgemeldet und versucht, es erneut zu mounten:

# mdadm --assemble /dev/md2 uuid=c0a644c7:e5bcf758:ecfbc8f3:ee0392b7
mdadm: cannot open device uuid=c0a644c7:e5bcf758:ecfbc8f3:ee0392b7: No such file or directory
mdadm: uuid=c0a644c7:e5bcf758:ecfbc8f3:ee0392b7 has no superblock - assembly aborted

Willst du mich veräppeln? Was ist mit meinen 600 GB in der Datei?

# mdadm --assemble /dev/md2 
mdadm: /dev/md2 not identified in config file.

Ah - leicht zu reparieren. unkommentierte Zeile in /etc/mdadm.conf

# mdadm --assemble /dev/md2 
mdadm: /dev/md2 has been started with 3 drives.

# e2fsck -n /dev/md2
e2fsck 1.42.12 (29-Aug-2014)
/dev/md2: clean, 731552/73228288 files, 182979586/292902912 blocks

Yippie!