Frage Wiederherstellen von RAID 5-Daten nach dem Erstellen eines neuen Arrays anstelle der Wiederverwendung


Leute bitte helfen - ich bin ein Neuling mit einem großen Kopfschmerz zur Hand (perfekte Sturmsituation).

Ich habe eine 3 1 tb hdd auf meinem ubuntu 11.04 als software raid 5 konfiguriert. Die daten wurden wöchentlich auf eine andere separate von der computerfestplatte kopiert bis das komplett fehlschlug und weggeworfen wurde. Vor ein paar Tagen hatten wir einen Stromausfall und nach dem Neustart meiner Box würde der Raid nicht starten. In meiner unendlichen Weisheit trat ich ein

mdadm --create -f...

Befehl statt

mdadm --assemble

und bemerkte die Travestie, die ich bis danach gemacht hatte. Es begann das Array degradiert und baute und synchronisierte es, was ~ 10 Stunden dauerte. Nachdem ich zurück war, sah ich, dass das Array erfolgreich läuft, aber der Raid nicht

Ich meine die einzelnen Laufwerke sind partitioniert (Partitionstyp f8 ) aber die md0 Gerät ist nicht. In Entsetzen erkennend, was ich getan habe, versuche ich, einige Lösungen zu finden. Ich bete das einfach --create hat den gesamten Inhalt des harten Treibers nicht überschrieben.

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

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

mdadm --examine --scan 

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

Interessanterweise war der Name "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

Pro Vorschläge habe ich die Superblocks aufgeräumt und das Array neu erstellt --assume-clean Option, aber ohne Glück überhaupt.

Gibt es ein Tool, mit dem ich zumindest einige der Daten wiederbeleben kann? Kann mir jemand sagen, was und wie der mdadm --create funktioniert, wenn er die Daten zerstört, damit ich ein Tool schreiben kann, um alles zu erledigen?

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, Backup-Blöcke versuchen ... fsck.ext4: Schlechte magische Zahl im Superblock 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 enthält Dateisystem (und nicht Swap oder UFS oder etwas anderes), dann der Superblock ist beschädigt, und Sie könnten versuchen, e2fsck mit einem alternativen Superblock auszuführen:     e2fsck -b 8193


Pro 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

und führen Sie fsck.ext4 mit jedem Backup-Block 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!


34
2018-01-07 06:24


Ursprung


Vielleicht werden die Leute eines Tages erkennen, warum RAID5 eine schreckliche Idee ist. Bis dahin, 1) Menschen werden Daten verlieren. 2) Wir werden Fragen wie diese bekommen. - Tom O'Connor
@ Tom O'Connor ... weil RAID5 eindeutig für Benutzerfehler verantwortlich ist. :mit den Augen rollen: - Reality Extractor
Hoffentlich kann die Antwort von Shane die Daten speichern, aber, wieder, Beweis, warum RAID allein nicht am besten für den Speicher ist. Brauchen auch Backups. (aber +1 für die Frage und die epische Antwort, die sich ergab) - tombull89
Ich weiß, es wird oft wiederholt, aber RAID ist keine Backup-Lösung. Die Nachricht muss wirklich nach Hause fahren. - Sirex


Antworten:


Ok - etwas nervte mich über dein Problem, also habe ich eine VM hochgefahren, um in das Verhalten zu schauen, das erwartet werden sollte. Ich werde zu dem kommen, was mich in einer Minute nervte; Lass es mich zuerst sagen:

Sichern Sie diese Laufwerke, bevor Sie etwas versuchen !!

Möglicherweise haben Sie bereits Schäden verursacht, die über die Resynchronisation hinausgehen. kannst du erklären, was du gemeint hast, als du gesagt hast:

Pro Vorschläge habe ich die Superblocks aufgeräumt und das Array mit --assume-clean Option - aber ohne Glück neu erstellt.

Wenn du ein mdadm --misc --zero-superblockDann sollte es dir gut gehen.

Wie auch immer, fange neue Festplatten auf und schnapp dir genau die aktuellen Bilder von ihnen, bevor du überhaupt etwas machst, das mehr auf diese Festplatten schreiben könnte.

dd if=/dev/sdd of=/path/to/store/sdd.img

Davon abgesehen sieht es so aus, als wären Daten, die auf diesen Dingen gespeichert sind, erschreckend resistent gegenüber eigenwilligen Resynchronisationen. Lies weiter, es gibt Hoffnung, und dies könnte der Tag sein, an dem ich das Antwortlängenlimit erreicht habe.


Das Best-Case-Szenario

Ich habe eine VM zusammengestellt, um dein Szenario neu zu erstellen. Die Laufwerke sind nur 100 MB, also würde ich nicht für jede Resynchronisation ewig warten, aber das sollte eine ziemlich genaue Darstellung sein.

Das Array wurde so generisch und standardmäßig wie möglich erstellt - 512 KB große Blöcke, linkssymmetrisches Layout, Festplatten in der Reihenfolge der Buchstaben. 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; Lass uns ein Dateisystem erstellen und ein paar Daten hinzufügen.

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

OK. Wir haben ein Dateisystem und einige Daten ("Daten" in datafile, und 5MB wert von zufälligen Daten mit diesem SHA1 Hash in randomdata) darauf; 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 Resynchronisation endete sehr schnell mit diesen winzigen Festplatten, aber es ist passiert. Also, hier ist, was mich von früher nervte; Ihre fdisk -l Ausgabe. Keine Partitionstabelle auf dem md Gerät ist überhaupt kein Problem, wird erwartet. 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

Perfektes Dateisystem nach einer Neusynchronisierung. Das ist gut. Lass 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

Solid - keine Datenkorruption! Aber das ist mit den exakt gleichen Einstellungen, also wurde nichts anders zwischen den beiden RAID-Gruppen zugeordnet. Lass uns das Ding fallen lassen, bevor wir versuchen es zu brechen.

root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md1

Einen Schritt zurück machen

Bevor wir versuchen, das zu brechen, wollen wir darüber reden, warum es schwer ist, zu brechen. RAID 5 funktioniert mit einem Paritätsblock, der einen Bereich mit der gleichen Größe wie der Block auf jeder anderen Festplatte im Array schützt. Die Parität ist nicht nur auf einer bestimmten Festplatte, sondern sie wird gleichmäßig um die Festplatten herumgedreht, um die Leselast im Normalbetrieb besser auf die Festplatten zu verteilen.

Die XOR-Operation zum Berechnen 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

Also ist die Parität unter den Platten verteilt.

DISK1  DISK2  DISK3  DISK4  DISK5
DATA   DATA   DATA   DATA   PARITY
PARITY DATA   DATA   DATA   DATA
DATA   PARITY DATA   DATA   DATA

Eine Neusynchronisierung wird normalerweise durchgeführt, wenn eine leere oder fehlende Festplatte ersetzt wird. es ist auch fertig mdadm create um sicherzustellen, dass die Daten auf den Festplatten mit denen der RAID-Geometrie übereinstimmen. In diesem Fall ist die letzte Festplatte in der Array-Spezifikation diejenige, mit der "synchronisiert" wurde - alle vorhandenen Daten auf den anderen Festplatten werden für die Synchronisierung verwendet.

Alle Daten auf der neuen Festplatte werden gelöscht und neu erstellt. entweder neue Datenblöcke aus Paritätsblöcken für das aufbauen, was dort hätte sein sollen, oder aber neue Paritätsblöcke aufbauen.

Was ist cool ist, dass das Verfahren für diese beiden Dinge genau das gleiche ist: eine XOR-Operation über die Daten von den restlichen Festplatten. Der Resync-Prozess in diesem Fall kann in seinem Layout haben, dass ein bestimmter Block ein Paritätsblock sein sollte, und denken, dass er einen neuen Paritätsblock baut, wenn er tatsächlich einen alten Datenblock neu erstellt. Also auch wenn es denkt es baut das auf:

DISK1  DISK2  DISK3  DISK4  DISK5
PARITY DATA   DATA   DATA   DATA
DATA   PARITY DATA   DATA   DATA
DATA   DATA   PARITY DATA   DATA

... es könnte nur neu aufgebaut werden DISK5 aus dem Layout oben.

Es ist also möglich, dass Daten konsistent bleiben, auch wenn das Array falsch aufgebaut ist.


Einen Affen in die Arbeiten werfen

(kein Schraubenschlüssel; der ganze Affe)

Test 1:

Lassen Sie uns das Array in der falschen Reihenfolge machen! sdc, dann sdd, dann 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 gut 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 512KB von A, dann 512KB von B, A, B usw. war, wurde nun zu B, A, B, A gemischt. Die Platte sieht nun wie ein Jibberish für den Dateisystemprüfer aus, sie läuft nicht. Die Ausgabe von mdadm --misc -D /dev/md1 gibt 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

Wenn es so aussehen sollte:

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 gut und gut. Wir haben dieses Mal eine ganze Reihe von Datenblöcken mit neuen Paritätsblöcken überschrieben. Re-create, mit der richtigen Reihenfolge jetzt:

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 immer noch ein Dateisystem da! Haben Sie 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, lassen Sie uns die Chunk-Größe ändern und sehen, ob uns das etwas kaputt macht.

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

Erfolg, wieder!

Test 3

Dies ist der, von dem ich dachte, er würde die Daten sicher töten - machen wir einen anderen Layout-Algorithmus!

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).

Gruselig und schlecht - es denkt, dass es etwas gefunden hat und etwas reparieren will! Strg+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 Resyncing 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 nur beweisen, dass Superblock-Nullsetzung ist nicht wirklich schnell schädlich:

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

Lass uns einfach alles umwerfen, was wir haben. Alle 4 vorherigen Tests kombiniert.

  • Falsche Reihenfolge der Geräte
  • Falsche Chunkgröß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

Beeindruckend.

Es sieht also so aus, als ob keine dieser Aktionen Daten in irgendeiner Weise beschädigt hätte. Ich war ehrlich überrascht über dieses Ergebnis. Ich erwartete eine moderate Wahrscheinlichkeit von Datenverlusten bei der Chunk-Größenänderung und einen gewissen Verlust bei der Layoutänderung. Ich habe heute etwas gelernt.


Also .. Wie bekomme ich meine Daten?

So viele Informationen über das alte System wären für Sie sehr hilfreich. Wenn Sie den Dateisystemtyp kennen, wenn Sie alte Kopien von Ihrem haben /proc/mdstat mit Informationen zu Laufwerksreihenfolge, Algorithmus, Chunk-Größe und Metadatenversion. Haben Sie die Email-Benachrichtigungen von mdadm eingerichtet? Wenn ja, finde einen alten; Wenn nicht, überprüfen Sie /var/spool/mail/root. Überprüfe dein ~/.bash_history um zu sehen, ob dein Original Build dort ist.

Also, die Liste der Dinge, die Sie tun sollten:

  1. Sichern Sie die Festplatten mit dd bevor du irgendwas machst !!
  2. Versuchen zu fsck die aktuelle, aktive md - Sie haben vielleicht zufällig in der gleichen Reihenfolge wie zuvor gebaut. Wenn Sie den Dateisystemtyp kennen, ist das hilfreich. benutze das spezifisch fsckWerkzeug. Wenn eines der Tools irgendetwas reparieren lässt, lass es nicht zu, es sei denn, du bist sicher, dass es tatsächlich das gültige Dateisystem gefunden hat! Wenn ein fsck Angebote, um etwas für Sie zu reparieren, zögern Sie nicht, einen Kommentar zu hinterlassen, um zu fragen, ob es tatsächlich hilft oder nur um Daten zu vernichten.
  3. Versuchen Sie, das Array mit verschiedenen Parametern zu erstellen. Wenn du ein altes hast /proc/mdstat, dann kannst du einfach nachahmen, was es zeigt; Wenn nicht, dann bist du irgendwie im Dunkeln - es ist vernünftig, alle verschiedenen Laufwerksbefehle auszuprobieren, aber es ist zwecklos, jede mögliche Chunkgröße mit jeder möglichen Reihenfolge zu überprüfen. Für jeden, fsck es zu sehen, wenn Sie etwas vielversprechendes bekommen.

Also, das ist es. Sorry für den Roman, zögern Sie nicht, einen Kommentar zu hinterlassen, wenn Sie Fragen haben, und viel Glück!

Fußnote: unter 22.000 Zeichen; 8k + schüchtern von der Längengrenze


87
2018-01-08 08:27



Das ist eine erstaunliche Antwort. - Antoine Benkemoun
Ich weiß nicht mal was ich sagen soll ... BRAVO !!! Ein großes Lob an Shane Madden. Ich werde die Festplatten sichern und mit Ihren Vorschlägen beginnen. Danke, nein wirklich ein großes Dankeschön !!! - Brigadieren
Ich bin einfach ... wow. Glänzende Antwort. Ich denke, die einzige Antwort, um die Grenze von 30.000 Zeichen zu durchbrechen, ist Evan Andersons "How Subnetting Work" -Aufsatz. - tombull89
Beste Antwort auf SF, soweit es mich betrifft. - Chopper3
Sie, Sir, gewinnen Sie das Internet. - Mark Henderson♦


Wenn du bist Glücklich Sie haben vielleicht Erfolg damit, Ihre Dateien mit einer Wiederherstellungssoftware wiederherzustellen, die ein defektes RAID-5-Array lesen kann. Zero-Übernahme-Wiederherstellung ist einer, mit dem ich schon einmal Erfolg hatte.

Ich bin mir jedoch nicht sicher, ob der Prozess des Erstellens eines neuen Arrays alle Daten gelöscht und zerstört hat, daher könnte dies eine letzte Chance sein.


5
2018-01-07 07:33



Vielen Dank, Mark. Ich werde es versuchen. Weißt du, ob es die Laufwerke ändert? Wenn das der Fall ist, werde ich eine Disk kopieren und auch mit anderen Tools versuchen. - Brigadieren
@Brigadieren - nein, tut mir leid, mir sind die Feinheiten der Funktionsweise von RAID5 nicht vertraut genug. - Mark Henderson♦
@Brigadieren Nach dem mdadm Dokumentation, der Erstellungsvorgang wird keine Daten zerstören, sondern nur resync - aber wenn es eine Geometrie ausgewählt hat, die nicht mit Ihrem Original übereinstimmt, dann hat es möglicherweise Daten mit dem Schreiben neuer Parität zerstört. Wenn ich später etwas Freizeit habe, kann es passieren, dass ich Ihre Situation in einer VM neu erstelle, um zu sehen, ob ich etwas hinzufügen kann. Ich würde empfehlen, vollständige Kopien der Laufwerke zu nehmen, bevor Sie irgendwelche Wiederherstellungsschritte unternehmen, die überhaupt auf die Festplatten schreiben - Sie sollten vielleicht nach zusätzlichen Laufwerken suchen, um Kopien zu erstellen. - Shane Madden♦
Ich bin nur nicht sicher, was die Synchronisierung verursacht hat - die Tatsache, dass das Array in erster Linie (wegen Stromausfall) oder etwas anderes verschlechtert wurde? Ich frage mich, ob mdadm - create unterscheidet, ob ich die Laufwerksreihenfolge anders als ursprünglich angegeben habe? - Brigadieren
@Brigadieren Sync tritt immer beim erstellen auf. - Shane Madden♦


Ich hatte ein ähnliches Problem:
Nach einem Ausfall eines Software-RAID5-Arrays habe ich gefeuert mdadm --create ohne es zu geben --assume-clean, und konnte das Array nicht mehr mounten. Nach zwei Wochen des Grabens habe ich endlich alle Daten wiederhergestellt. Ich hoffe, dass das folgende Verfahren jemandes Zeit spart.

Um es kurz zu machen

Das Problem wurde dadurch verursacht, dass mdadm --create ein neues Array, das sich in zwei Aspekten vom Original unterscheidet:

  • unterschiedliche Reihenfolge der Partitionen
  • unterschiedlicher RAID-Datenoffset

Wie es im Brillianten gezeigt wurde Antwort von Shane Madden, mdadm --create zerstört die Daten in den meisten Fällen nicht! 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-Superblocks, also 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. Eine weitere wichtige Erkenntnis war eine Kopie einer Datei, die ebenfalls auf dem RAID-Array gespeichert wurde.

Werkzeuge

Xubuntu 12.04.1 Live-CD wurde verwendet, um die ganze Arbeit zu erledigen. Abhängig von Ihrer Situation benötigen Sie möglicherweise einige der folgenden Tools:

Version von mdadm, die es ermöglicht, Datenoffset anzugeben 

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

bgrep - Suche nach Binärdaten 

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 vollständiger Sicherung

Benennen von Gerätedateien, z.B. /dev/sda2  /dev/sdb2 usw., ist nicht persistent, so ist es besser, die Seriennummern Ihrer Laufwerke zu notieren

sudo hdparm -I /dev/sda

Dann schließen Sie 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

Verschiedene Layouts werden hier beschrieben: http://www.accs.com/p_and_p/RAID/LinuxRAID.html
Um herauszufinden, wie die Datenstreifen auf dem ursprünglichen Array organisiert wurden, benötigen Sie eine Kopie einer zufällig aussehenden Datei, von der Sie wissen, dass sie im Array gespeichert wurde. Die Standard-Chunk-Größe, die derzeit von verwendet wird mdadm ist 512KB. Für ein Array von N Partitionen benötigen Sie eine Datei der Größe mindestens (N + 1) * 512 KB. Ein JPEG oder Video ist gut, da es relativ eindeutige Teilstrings von Binärdaten liefert. Angenommen, unsere Datei wird aufgerufen picture.jpg. Wir lesen 32 Byte Daten 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 aller dieser Bytestrings auf all unseren unformatierten Partitionen, also insgesamt (N + 1) * N-Befehle, so:

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 38GB Partition dauerte ungefähr 12 Minuten. In meinem Fall wurde jede 32-Byte-Zeichenfolge nur einmal unter allen acht Laufwerken gefunden. Wenn Sie Offsets vergleichen, die von bgrep zurückgegeben werden, erhalten Sie ein Bild wie dieses:

| 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 eine Normale linkssymmetrisch Layout, das ist Standard für mdadm. Noch wichtiger ist, jetzt kennen wir die Reihenfolge der Partitionen. Wir wissen jedoch nicht, welche Partition die erste im Array ist, da sie zyklisch verschoben werden kann.

Beachten Sie auch die Entfernung zwischen gefundenen Offsets. In meinem Fall war es 512KB. Die Chunk-Größe kann tatsächlich kleiner als diese Entfernung sein, in welchem ​​Fall das tatsächliche Layout anders sein wird.

Finden Sie Original Chunk Größe

Wir verwenden dieselbe Datei picture.jpg um 32 Bytes von Daten in verschiedenen Intervallen voneinander zu lesen. Wir wissen von oben, dass die Daten bei Offset 100k liegen /dev/sdh2, bei Offset 612k ist bei /dev/sdb2und bei 1124k ist es /dev/sdd2. Dies zeigt, dass die Chunk-Größe nicht größer als 512 KB ist. Wir verifizieren, dass es nicht kleiner als 512 KB ist. Dafür werfen wir die Bytestring bei Offset 356k und schauen auf welche Partition es sitzt:

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

Es ist auf der gleichen Partition wie Offset 612k, die angibt, dass die Chunk-Größe nicht 256 KB ist. Wir eliminieren kleinere Chunk-Größen in ähnlicher Weise. Ich endete damit, dass 512KB Chunks die einzige Möglichkeit waren.

Finden Sie die erste Partition im Layout

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

Zu Beginn 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 verifizieren, dass die Bestellung befolgt 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

Jetzt bestimmen wir Offsets der N + 1 bekannten Bytestrings im RAID-Array. Ich führe ein Skript für eine Nacht (Live-CD fragt kein 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 dritte String nicht gefunden wurde. Dies bedeutet, dass der Brocken an /dev/sdd2 wird für die Parität verwendet. Hier sehen Sie eine Illustration 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, abzuleiten, von welcher Partition das Array gestartet werden soll, um die Paritätsblöcke an die richtige Stelle zu verschieben. Da die Parität um zwei Chunks nach links verschoben werden sollte, sollte die Partitionsfolge um zwei Schritte nach rechts verschoben werden. Somit ist das korrekte Layout für diesen Datenoffset 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 

An dieser Stelle enthält unser RAID-Array Daten in der richtigen Form. Sie können sich glücklich schätzen, dass der RAID-Datenoffset der gleiche wie im ursprünglichen Array ist und Sie dann höchstwahrscheinlich die Partition mounten können. Leider war das nicht mein Fall.

Überprüfen Sie die Datenkonsistenz

Wir verifizieren, dass die Daten über einen Chunkstreifen konsistent sind, indem Sie eine Kopie davon extrahieren picture.jpg aus dem Array. Dazu suchen 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 in skip= Parameter für dd. Das count= ist die Größe von picture.jpg in Bytes:

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

Prüfe das extract.jpg ist das gleiche wie picture.jpg.

Finden Sie den RAID-Daten-Offset

Eine Nebenbemerkung: Standarddatenverschiebung für mdadm Version 3.2.3 ist 2048 Sektoren. Aber dieser Wert wurde im Laufe der Zeit geändert. Wenn das ursprüngliche Array einen kleineren Datenoffset als Ihr aktueller verwendet hat mdadm, dann mdadm --create ohne --assume-clean kann den Anfang des Dateisystems überschreiben.

Im vorherigen Abschnitt haben wir ein RAID-Array erstellt. Überprüfen Sie, welchen RAID-Daten-Offset es hatte, indem Sie für einige der einzelnen Partitionen angeben:

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

2048 512-Byte-Sektoren sind 1 MB. Da die Chunk-Größe 512 KB beträgt, beträgt der aktuelle Datenoffset zwei Chunks.

Wenn Sie zu diesem Zeitpunkt einen Offset von zwei Blöcken haben, ist dieser wahrscheinlich klein genug und Sie können diesen Absatz überspringen.
Wir erstellen ein RAID5-Array mit dem Datenoffset von einem 512KB-Chunk. Wenn ein Chunk früher gestartet wird, verschiebt sich die Parität um einen Schritt nach links, also kompensieren wir, indem wir die Partitionsfolge um einen Schritt nach links verschieben. Daher ist für 512 KB Datenoffset das korrekte Layout hbdcefga. Wir verwenden eine Version von mdadm unterstützt den Datenoffset (siehe Abschnitt Tools). Es dauert Offset in Kilobyte:

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 scannen den Anfang des Arrays nach Vorkommen der magischen Zahl s_magic gefolgt von s_state und s_errors. Die zu suchenden Bytestrings sind:

53EF01000100
53EF00000100
53EF02000100
53EF01000200
53EF02000200

Beispielbefehl:

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

Die magische Zahl startet 0x38 Bytes in den 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_size Feld bei 0x18 ist 0002, was bedeutet, dass die Blockgröße 2 ^ (10 + 2) = 4096 Bytes ist. s_blocks_count_lo bei 0x4 ist 03f81480 Blöcke, die 254GB ist. Sieht gut aus.

Wir suchen nun nach den Vorkommen der ersten Bytes des Superblocks, um seine Kopien zu finden. Beachten Sie das Umdrehen 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 beginnt das Dateisystem bei dem Offset 0xdc80000, d. H. 225792 KB ab dem Start der Partition. Da wir 8 Partitionen haben, von denen eine für Parität ist, teilen wir den Offset durch 7. Dies ergibt 33030144 Byte Offset auf jeder Partition, was genau 63 RAID-Chunks ist. Und da der aktuelle RAID-Daten-Offset ein Chunk ist, schlussfolgern wir, dass der ursprüngliche Daten-Offset 64 Chunks oder 32768 KB betrug. Verschiebung hbdcefga63 mal rechts gibt das Layout an bdcefgah.

Wir bauen schließlich 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à!


4
2017-07-08 01:19



Ausgezeichnete Lösung. Eine Anmerkung - 53EF00000100 scheint kein gültiger Anker für den EXT4-Header zu sein. Gemäß ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#The_Super_Block die zwei Bytes nach 53EF könnten nur 0100, 0200 oder 0400 sein. - matt


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

Es sagte, dass es keinen gültigen Superblock oder eine Partition hatte.

Als ich den mdadm raid gestoppt habe, konnte ich das reguläre Gerät nicht mehr montieren.

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

Das stellte den Superblock wieder her, damit ich das Laufwerk mounten und lesen konnte.

Um das Array zum Laufen zu bringen, ohne den Superblock oder die Partitionen zu zerstören, habe ich Build verwendet:

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

0
2018-01-10 23:34





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

Ich hatte zwei Backups von "wichtigen" Sachen und eine Menge zufälliger Dinge, die ich aus verschiedenen Teilen des Internets geschnappt hatte, die ich wirklich hätte durchgehen und selektiv wegwerfen müssen. Die meisten Backups wurden in .tar.gz-Dateien mit 25 GB oder weniger aufgeteilt, und eine separate Kopie von / etc wurde ebenfalls gesichert.

Der Rest des Dateisystems wurde auf zwei kleinen Raid0-Disketten von 38 GB gehalten.

Meine neue Maschine war der alten Hardware ähnlich, und ich habe die Maschine zum Laufen gebracht, 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, dass die Festplatten in der richtigen Reihenfolge waren, und musste eine neue Version von Debian Jessie installieren, um sicher zu sein, dass ich die Maschine bei Bedarf aktualisieren und andere aussortieren konnte Probleme.

Mit dem neuen generischen System, das auf zwei Raid0-Platten installiert war, begann ich, die Arrays wieder zusammenzusetzen. Ich wollte sicher sein, dass ich die Festplatten in der richtigen Reihenfolge hatte. Was ich hätte tun sollen, war:

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

Aber ich tat es nicht. Es scheint, dass MDADM ist ziemlich schlau und mit einer UUID, kann herausfinden, welche Laufwerke wohin gehen. Selbst wenn das BIOS / dev / sdc als / sda bezeichnet, wird mdadm es korrekt zusammensetzen (YMMV though).

Stattdessen gab ich heraus: mdadm --create /dev/md2 without the --assume-clean, und erlaubte die Resync auf / dev / sde1 abzuschließen. Der nächste Fehler, den ich gemacht habe, war die Arbeit an / dev / sdc1 anstelle des letzten Laufwerks in / dev / md2, / sde1. Immer wenn mdadm denkt, dass ein Problem vorliegt, wird das letzte Laufwerk gelöscht oder neu synchronisiert.

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

Nachdem ich diese Seite gefunden hatte, ging ich durch die Prozedur, um die Reihenfolge der Laufwerke zu finden (erledigt), nach gültigen Daten zu suchen (verifizierte 6MB einer 9MB Datei), habe die Festplatten in der richtigen Reihenfolge, cde, die UUIDs gepackt von / md2 und / md3 aus der alten /etc/mdadm.conf und versuchte Assembling.

Gut, /dev/md3 gestartet, und mdadm --misc -D /dev/md3 zeigte 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 Superblocks finden. Bei der Überprüfung auf Superblöcke, wie oben beschrieben, stimmte die Gesamtblockzahl, die als a880 0076 oder a880 0076 oder 5500 1176 gefunden wurde, nicht mit der Plattenkapazitätsgröße von 1199,79 überein, die von meinem mdadm gemeldet wurde. Auch keiner der Standorte der "Superblocks" stimmte mit den Daten in den obigen Posts überein.

Ich habe alles von / var gesichert und mich darauf vorbereitet, die Platten zu löschen. Um zu sehen, ob es möglich war, gerade / md2 zu löschen (ich hatte an dieser Stelle nichts anderes zu verlieren), entscheide 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, außer dem Wechsel zum Uuid. Nach ein paar weiteren Überprüfungen schrieb ich 600 GB gesicherte Daten auf / dev / md2. Dann, unmounted und versucht, das Laufwerk neu 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 verarschen? Was ist mit meinen 600 GB auf der Datei?

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

Ah - leicht behoben. unkommentierte eine 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!


0
2018-02-04 14:19