LINUX RAID5 beim Reshapen zerschossen

[Jofrie]

Hallo liebe Leute,

ich habe gestern echt einen Bock geschossen. Ich wollte das RAID5 von 3 auf 5 Festplatten erweitern und hatte den Reshape schon angestoßen. Bei etwa 5% habe ich dann bemerkt, dass die Festplatten etwas warm werden und ich den zusätzlichen Lüfter wieder anstecken muss. Dazu habe ich den Server heruntergefahren. Beim Neustart hing er dann immer nur noch in fsck-timeouts, da er mit den neuen Festplatten nichts anfangen konnten. Ohne diese beiden startet der Server problemlos, startet aber auch das RAID nicht mehr. Da kein Hotplug möglich ist, musste ich die 2 neuen Platten anderweitig platt machen und wieder einstecken.
Jetzt sitze ich zwischen zwei Stühlen und weiß nicht vor und zurück. Da das Filesystem noch nicht erweitert wurde, gehe ich davon aus, dass noch alle Daten auf den alten Platten liegen. Die neuen haben aber keine Superblock-Informationen.

Könnt Ihr mir dort weiterhelfen?

Ein paar Informationen zu den Platten:

sda: Systemplatte mit Debian und einer Nutzpartition
sdb: Neue Festplatte
sdc: Neue Festplatte
sdd: Alte Festplatte
sde: Alte Festplatte
sdf: Alte Festplatte


fdisk -l

root@Rechenknecht:~# fdisk -l

Disk /dev/sda: 120.0 GB, 120034123776 bytes
255 heads, 63 sectors/track, 14593 cylinders, total 234441648 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x000c67b2

Device Boot Start End Blocks Id System
/dev/sda1 * 2048 16779263 8388608 83 Linux
/dev/sda2 224862206 234440703 4789249 5 Extended
Partition 2 does not start on physical sector boundary.
/dev/sda3 16779264 224860159 104040448 83 Linux
/dev/sda5 224862208 234440703 4789248 82 Linux swap / Solaris

Partition table entries are not in disk order

Disk /dev/sdb: 2000.4 GB, 2000398934016 bytes
255 heads, 63 sectors/track, 243201 cylinders, total 3907029168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

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

Disk /dev/sdc: 2000.4 GB, 2000398934016 bytes
255 heads, 63 sectors/track, 243201 cylinders, total 3907029168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

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

WARNING: GPT (GUID Partition Table) detected on '/dev/sdd'! The util fdisk doesn't support GPT. Use GNU Parted.

Disk /dev/sdd: 2000.4 GB, 2000398934016 bytes
256 heads, 63 sectors/track, 242251 cylinders, total 3907029168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x00000000

Device Boot Start End Blocks Id System
/dev/sdd1 1 4294967295 2147483647+ ee GPT
Partition 1 does not start on physical sector boundary.

WARNING: GPT (GUID Partition Table) detected on '/dev/sdf'! The util fdisk doesn't support GPT. Use GNU Parted.

Disk /dev/sdf: 2000.4 GB, 2000398934016 bytes
256 heads, 63 sectors/track, 242251 cylinders, total 3907029168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x00000000

Device Boot Start End Blocks Id System
/dev/sdf1 1 4294967295 2147483647+ ee GPT
Partition 1 does not start on physical sector boundary.

WARNING: GPT (GUID Partition Table) detected on '/dev/sde'! The util fdisk doesn't support GPT. Use GNU Parted.

Disk /dev/sde: 2000.4 GB, 2000398934016 bytes
256 heads, 63 sectors/track, 242251 cylinders, total 3907029168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x00000000

Device Boot Start End Blocks Id System
/dev/sde1 1 4294967295 2147483647+ ee GPT
Partition 1 does not start on physical sector boundary.

blkid

[/b]root@Rechenknecht:~# blkid
/dev/sda1: UUID="e7e7cdf3-373a-4edf-bb60-4a12972cd4e8" TYPE="ext4"
/dev/sda5: UUID="d05d1658-d1f0-4279-aea3-ac8a7e43b460" TYPE="swap"
/dev/sdd: UUID="9312a8cb-f94d-beac-e0c0-ddffbe166253" UUID_SUB="ed3dda91-6db0-c7c4-94af-0dbd6c8b5a47" LABEL="Rechenknecht:Datengrab" TYPE="linux_raid_member"
/dev/sda3: LABEL="Schnellschnell" UUID="236f481e-443c-4a97-acc6-ae9e9d4dd440" TYPE="ext4"
/dev/sde: UUID="9312a8cb-f94d-beac-e0c0-ddffbe166253" UUID_SUB="95edfb77-127f-ed49-e6ea-4a53020a3bc6" LABEL="Rechenknecht:Datengrab" TYPE="linux_raid_member"
/dev/sdf: UUID="9312a8cb-f94d-beac-e0c0-ddffbe166253" UUID_SUB="a87c4f5f-835f-ac90-ea99-acdbe7f6f5ec" LABEL="Rechenknecht:Datengrab" TYPE="linux_raid_member"[b]

cat /proc/mdstat

root@Rechenknecht:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : inactive sdd[0](S) sdf[2](S) sde[1](S)
5860150536 blocks super 1.2

mdadm --examine

root@Rechenknecht:~# mdadm --examine /dev/sd[b-f]
mdadm: No md superblock detected on /dev/sdb.
mdadm: No md superblock detected on /dev/sdc.
/dev/sdd:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x4
Array UUID : 9312a8cb:f94dbeac:e0c0ddff:be166253
Name : Rechenknecht:Datengrab (local to host Rechenknecht)
Creation Time : Fri Sep 11 20:46:24 2015
Raid Level : raid5
Raid Devices : 5

Avail Dev Size : 3906767024 (1862.89 GiB 2000.26 GB)
Array Size : 7813531648 (7451.56 GiB 8001.06 GB)
Used Dev Size : 3906765824 (1862.89 GiB 2000.26 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : active
Device UUID : ed3dda91:6db0c7c4:94af0dbd:6c8b5a47

Reshape pos'n : 439736320 (419.37 GiB 450.29 GB)
Delta Devices : 2 (3->5)

Update Time : Wed Feb 3 20:47:36 2016
Checksum : b4703e4a - correct
Events : 433

Layout : left-symmetric
Chunk Size : 512K

Device Role : Active device 0
Array State : AAAAA ('A' == active, '.' == missing)
/dev/sde:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x4
Array UUID : 9312a8cb:f94dbeac:e0c0ddff:be166253
Name : Rechenknecht:Datengrab (local to host Rechenknecht)
Creation Time : Fri Sep 11 20:46:24 2015
Raid Level : raid5
Raid Devices : 5

Avail Dev Size : 3906767024 (1862.89 GiB 2000.26 GB)
Array Size : 7813531648 (7451.56 GiB 8001.06 GB)
Used Dev Size : 3906765824 (1862.89 GiB 2000.26 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : active
Device UUID : 95edfb77:127fed49:e6ea4a53:020a3bc6

Reshape pos'n : 439736320 (419.37 GiB 450.29 GB)
Delta Devices : 2 (3->5)

Update Time : Wed Feb 3 20:47:36 2016
Checksum : 34d57680 - correct
Events : 433

Layout : left-symmetric
Chunk Size : 512K

Device Role : Active device 1
Array State : AAAAA ('A' == active, '.' == missing)
/dev/sdf:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x4
Array UUID : 9312a8cb:f94dbeac:e0c0ddff:be166253
Name : Rechenknecht:Datengrab (local to host Rechenknecht)
Creation Time : Fri Sep 11 20:46:24 2015
Raid Level : raid5
Raid Devices : 5

Avail Dev Size : 3906767024 (1862.89 GiB 2000.26 GB)
Array Size : 7813531648 (7451.56 GiB 8001.06 GB)
Used Dev Size : 3906765824 (1862.89 GiB 2000.26 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : active
Device UUID : a87c4f5f:835fac90:ea99acdb:e7f6f5ec

Reshape pos'n : 439736320 (419.37 GiB 450.29 GB)
Delta Devices : 2 (3->5)

Update Time : Wed Feb 3 20:47:36 2016
Checksum : 120481ef - correct
Events : 433

Layout : left-symmetric
Chunk Size : 512K

Device Role : Active device 2
Array State : AAAAA ('A' == active, '.' == missing)

assemble Versuch

root@Rechenknecht:~# mdadm --assemble /dev/md0 /dev/sdd /dev/sde /dev/sdf
mdadm: /dev/md0 assembled from 3 drives - not enough to start the array.

Ich bin für jede Hilfestellung dankbar.

Gruß
Jofrie

 

[Madman1209]

Hi,

gibt es kein Backup von den Daten?

VG,
Mad

 

[rille]

Bestimmt nicht, das RAID war vermutlich das Backup

 

[Jofrie]

Es ist eigentlich nur ein Filmarchiv, also nix kritisches. Wenn futsch dann futsch. Wäre bloß ärgerlich, das alles nochmal durch die Leitung zu pressen.

 

[Sannyboy111985]

Mein Tipp wäre dafür zu sorgen, dass das RAID beim booten nicht hochgefahren oder gemountet wird.
Dann den Rechner mit allen Platten neu hoch fahren und das Raid von hand starten. Wenn der Reshape dann anläuft alles gut.

Wenn du auch nur einen Block von Hand an einer der Platten, egal ob neu oder alt, änderst war es das für das Raid.

 

[Jofrie]

Sprich: Da ich die neuen Platten ja platt gemacht habe ergo keinen Block mehr auf diesen haben, ist das RAID hinüber? Meine Hoffnung war, den Reshape zu canceln und das alte RAID wiederherzustellen.

 

[KillerCow]

Wenn der reshape schon angelaufen war, dürften sich bereits einige Daten auf den neuen Platten ihr neues Zuhause gesucht haben. Durch das platt machen hast du dir damit wohl dein Raid zerledert.

Kannst dir ja mal das hier anschauen, vielleicht bekommt man damit noch was gerettet: https://www.haage-partner.de/datenrettung/RStudio.html

(Habe das selbst noch nie benutzt, bin neulich nur mal drüber gestolpert)

 

[Holt]

habe gestern echt einen Bock geschossen.

Das kann man wohl sagen!

Bei etwa 5% habe ich dann bemerkt, dass die Festplatten etwas warm werden
...
musste ich die 2 neuen Platten anderweitig platt machen und wieder einstecken.

Wie konnstest Du nur? Weder unterbrincht man sowas noch macht man danach die Platten platt.

Da das Filesystem noch nicht erweitert wurde, gehe ich davon aus, dass noch alle Daten auf den alten Platten liegen.

Nein, denn bei der Aktion wurden die Daten schon neu auf Platten umverteilt. Vorher war es so, Datenblock (entsprechend dem Stripsize also 64k, 128k, etc) 1 auf Platte 1, Datenblock 2 auf Platte 2, auf Platte 3 dann die Parity für die beiden Block und Datenblock 3 dann auch Platte 1, auf Plate die nächsten Paritydaten (für die Blöcke 3 und 4) und Datenblock 4 auf Platte 3, dann auf Platte 1 Paritydaten (für die Datenblöcke 5 und 6), Datenblock 5 auf Platte 2 und Datenblock 6 auf Platte 3 etc. pp.. So geht ein RAID 5.

Nun wurde es so umverteilt: Datenblock 1 bleibt auf Platte 1, Datenblock 2 bleibt auf Platte zwei, Datenblock 3 kommt auf die Platte 3, Datenblock 4 auf die Platte 4, auf Platte 5 kommen die neuen Paritydaten für die Blöcke 1 bis 4. Auf die Platte 1 kommt nun anstelle des Datenblock 3 der Datenblock 5, auf der Platte 2 werden die alten Paritydaten mit dem Datenblock 6 überschrieben, auf Platte 3 nimmt der Datenblock 7 den Platz von Datenblock 4 ein, auf Platte 4 landet die Parity für die Datenblöcke 5 bis 8 und der Datenblock 8 kommt auf Platte 5, dann kommt Datenblock 9 auf Platte 1, Datenblock 10 auf Platte 2, die Parity für die blöcke 9 bis 12 auf Platte 3, Datenblock 11 auf Platte 4 und Datenblock 12 auf Platte 5 und so weiter.

Nun hast Du die beiden Platten 4 und 5 platt gemacht, damit fehlen Dir nun Daten, aus dem kurzen Beispoiel über 3 Stripes schon die Datenblöcke 4, 8, 11 und 12, alsoein Drittel und schlimmer noch, die Paritydaten nutzen Dir nichts, weil diese nur zur Rekonstruktion taugen, wenn eine Platte fehlt, aber es fehlen in dem schon bearbeiteten Bereich zwei Platten, eben die beiden neuen die Plattgemacht wurden. Damit sind also 5% des Fileystems verloren.

RAIDs ersetzen keine Backups! Hoffentlich hast Du das vorher gewusst, sonst hast Du jetzt echt ein Problem, denn ob Recoverytools die auch RAIDs recovern können damit noch klarkommen, kann ich nicht sagen.

 

[Jofrie]

Alles klar, das ein RAID kein Backup ist, ist klar. Es lief lediglich ein Plex Server darauf, der möglichst verfügbar sein sollte. Dann werde ich halt alle Platten löschen, ein frisches RAID5 aufsetzen und beim nächsten Mal mit Schnellschüssen abwarten

Danke trotzdem!

 

[TK-Shockwave]

Versuch mal ob du mit MDADM zumindest das Assemble mit den alten Platten hinbekommst.
Ich vermute, wie bereits angesprochen wurde, das Metadaten sowie einige Bits, Parity ein neues Zuhause gesucht haben.

Das Assemble löst kein Rebuild oder so aus - es mapped nur die Platten im gewünschten Raid Layout. Sollten die Daten noch passen - sprich Partitionstabelle etc. kannst du es auch wieder Builden lassen.

 

[Jofrie]

Hab ich schon versucht, erfolglos. Wie gesagt, ich mach da jetzt nen Cut und setz die Kiste neu auf.

 

[snaxilian]

Einen mdadm-rebuild kann man relativ sorgenfrei unterbrechen sofern das System sauber runter- & raufgefahren wird und nicht durch einen Stromausfall o.ä.
Ist natürlich nicht ganz so geil aber es geht... Ansonsten stimme ich Holt zu. Das Dateisystem ist zwar nicht vergrößert aber trotzdem bereits umverteilt. Nach erfolgreichem grow des Raids hättest du anschließend das Dateisystem erweitern können.

Hast du die jetzt nicht mehr erkannten Platten schon "geplättet" oder werden sie einfach nur nicht erkannt?
Wenn nicht erkannt: mdadm --assemble /dev/md0 --uuid=<UUID>

Das klappt, solange du mit mdadm --examine die UUID von einer der Platten auslesen kannst.

Falls das nicht klappt, wäre Option 2:
sudo mdadm --create /dev/md0 -v -l 5 -n 5 /dev/sdb /dev/sdc /dev/sdd /dev/sde /dev/sdf
Danach:
sudo mdadm --assemble /dev/md0 /dev/sda /dev/sdb /dev/sdc /dev/sdd /dev/sde /dev/sdf


Einfacher wäre aber: Raid plätten, komplett neu erstellen und die Daten aus dem Backup wieder zurück spielen. Ein Backup hast du doch sicherlich vorher angelegt, oder?