recover mdadm RAID5 – nach einem Controllerdefekt

1. Tag

Jetzt ist schon wieder was passiert!

Nach einem defekt des SATA-Controllers sind 2, der 4 Festplatten innerhalb kurzer zeit ausgefallen. Da auch keine Spare-Festlatte vorhanden war konnte das RAID nicht einfach mit assemble wiederhergestellt werden. Juhuu da kommt Freude auf!

Nun sind aber noch nahezu alle Daten vorhanden. Der Trick besteht darin das RAID neu zu erstellen (exakt so wie es vorher gebaut war). Bevor ich allerdings auf den Original Platten herum fuhrwerke, fertige ich Kopien an.

Ich habe vor die 4x1TB Originalplatten mit ddrescue auf vier neue 2TB-Festplatten zu spiegeln. Mit diesen Kopien wird dann weiter gearbeitet. Zum retten der Daten und zum erstellen der Kopien verwende ich GRML. Es funktioniert auch jede andere Distribution wenn die entsprechende Software darauf zu finden ist. Ich muss zu einer LiveCD greifen da nur 4 SATA Anschlüsse auf dem Motherboard vorhanden sind.

Zum anfertigen der Kopien der Festplatten verwende ich ddrescue.

ddrescue [options] infile outfile [logfile]

Das jeweilige in und outfile sind natürlich die Festplatten. Wenn also /dev/sda auf /dev/sdb kopiert werden soll lautet der Befehl:

ddrescue -f /dev/sda /dev/sdb /root/md0.disk0.ddrescue.log

Das Logfile ist nur eine Datei, in der abgespeichert wird welche Blöcke nicht kopiert werden konnten. Wenn die Festplatte in Ordnung ist sollten beim Kopiervorgang keine Fehler auftreten. Die Option -f (force)wird mitgegeben weil das Blockdevice /dev/sdb natürlich vorhanden ist und überschrieben werden soll.

Bei diesen Arbeitsschritten bitte unbedingt darauf achten was man tut. Nicht das man aus versehen die wichtigen Daten, mit den Daten der leeren neuen Platte überschreibt.

Welche Platte auf welche geschrieben wird kann man einfach mit smartctl und fdisk -l überprüfen. Ich habe mir die Platten mit der RAID-Device-Nummer beschriftet (kleine PostIt’s). Welche RAID Device Nummer kann man mit mdadm -E [device] heraus finden. Ich beschrifte also sauber alle Festplatten, nicht dass da was verwechselt wird. Da ich nur vier SATA Ports habe, stöpsle ich mal die vermeintlich defekten Platten an und starte den Kopiervorgang. Danach lege ich mich schlafen.

2. Tag

Wie vermutet konnten die Platten fehlerfrei kopiert werden. Ich stöpsle also die nächsten zwei Platten an und vertreibe mir weitere Stunden mit anderen Dingen die Zeit. Am Abend dann die Erleichterung, vier saubere Kopien auf neuen Festplatten. Jetzt kann endlich mit dem spannenden Teil begonnen werden. Die vier Kopien kommen an meinem Testrechner, die Originale werden sicher im Kasten verstaut.

Als erstes checke ich noch schnell die Superblöcke (mdadm) der Partitionen

root@grml ~ # mdadm -E /dev/sda1
/dev/sda1:
Magic : a92b4efc
Version : 0.90.00
UUID : 48ddfd4c:9abb782d:5e8e8034:e6138775
Creation Time : Thu Jul 23 19:59:08 2009
Raid Level : raid5
Used Dev Size : 976759936 (931.51 GiB 1000.20 GB)
Array Size : 2930279808 (2794.53 GiB 3000.61 GB)
Raid Devices : 4
Total Devices : 4
Preferred Minor : 0

Update Time : Tue Apr 17 20:33:37 2012
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 2
Spare Devices : 0
Checksum : a5c2c4c7 - correct
Events : 1455732

Layout : left-symmetric
Chunk Size : 64K

Number Major Minor RaidDevice State
this 0 8 81 0 active sync

0 0 8 81 0 active sync
1 1 8 97 1 active sync
2 2 0 0 2 faulty removed
3 3 0 0 3 faulty removed
root@grml ~ # mdadm -E /dev/sdb1
/dev/sdb1:
Magic : a92b4efc
Version : 0.90.00
UUID : 48ddfd4c:9abb782d:5e8e8034:e6138775
Creation Time : Thu Jul 23 19:59:08 2009
Raid Level : raid5
Used Dev Size : 976759936 (931.51 GiB 1000.20 GB)
Array Size : 2930279808 (2794.53 GiB 3000.61 GB)
Raid Devices : 4
Total Devices : 4
Preferred Minor : 0

Update Time : Thu Apr 12 14:53:19 2012
State : clean
Active Devices : 4
Working Devices : 4
Failed Devices : 0
Spare Devices : 0
Checksum : a5bbcf27 - correct
Events : 1453878

Layout : left-symmetric
Chunk Size : 64K

Number Major Minor RaidDevice State
this 3 8 129 3 active sync

0 0 8 81 0 active sync
1 1 8 97 1 active sync
2 2 8 113 2 active sync
3 3 8 129 3 active sync
root@grml ~ # mdadm -E /dev/sdc1
/dev/sdc1:
Magic : a92b4efc
Version : 0.90.00
UUID : 48ddfd4c:9abb782d:5e8e8034:e6138775
Creation Time : Thu Jul 23 19:59:08 2009
Raid Level : raid5
Used Dev Size : 976759936 (931.51 GiB 1000.20 GB)
Array Size : 2930279808 (2794.53 GiB 3000.61 GB)
Raid Devices : 4
Total Devices : 4
Preferred Minor : 0

Update Time : Tue Apr 17 20:33:37 2012
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 2
Spare Devices : 0
Checksum : a5c2c4d9 - correct
Events : 1455732

Layout : left-symmetric
Chunk Size : 64K

Number Major Minor RaidDevice State
this 1 8 97 1 active sync

0 0 8 81 0 active sync
1 1 8 97 1 active sync
2 2 0 0 2 faulty removed
3 3 0 0 3 faulty removed
root@grml ~ # mdadm -E /dev/sdd1
/dev/sdd1:
Magic : a92b4efc
Version : 0.90.00
UUID : 48ddfd4c:9abb782d:5e8e8034:e6138775
Creation Time : Thu Jul 23 19:59:08 2009
Raid Level : raid5
Used Dev Size : 976759936 (931.51 GiB 1000.20 GB)
Array Size : 2930279808 (2794.53 GiB 3000.61 GB)
Raid Devices : 4
Total Devices : 4
Preferred Minor : 0

Update Time : Mon Apr 16 19:38:10 2012
State : clean
Active Devices : 3
Working Devices : 3
Failed Devices : 1
Spare Devices : 0
Checksum : a5c1662f - correct
Events : 1455708

Layout : left-symmetric
Chunk Size : 64K

Number Major Minor RaidDevice State
this 2 8 113 2 active sync

0 0 8 81 0 active sync
1 1 8 97 1 active sync
2 2 8 113 2 active sync
3 3 0 0 3 faulty removed

Da haben wir nun den Salat ein RAID5 mit zwei als defekt markierten Platten. Mit mdadm assemble kann man den Verbund natürlich nicht mehr herstellen. Nach dem ich die manpages etwas studiert habe. Ist mir die Option –assume-clean beim Create Mode aufgefallen. Die Option gibt an das das RAID noch in Ordnung ist und es nicht neu gesynct werden soll. Also wird das RAID ohne sync neu erstellt. Super genau das was ich brauche.

Gesagt getan:

root@grml ~ # mdadm --create /dev/md0 --verbose --level=5 --raid-devices=4 --chunk=64 --assume-clean --metadata=0.90 /dev/sda1 /dev/sdc1 /dev/sdd1 /dev/sdb1
mdadm: layout defaults to left-symmetric
mdadm: layout defaults to left-symmetric
mdadm: /dev/sda1 appears to be part of a raid array:
level=raid5 devices=4 ctime=Thu Jul 23 19:59:08 2009
mdadm: layout defaults to left-symmetric
mdadm: /dev/sdc1 appears to contain an ext2fs file system
size=976760000K mtime=Thu Jan 1 01:00:00 1970
mdadm: /dev/sdc1 appears to be part of a raid array:
level=raid5 devices=4 ctime=Thu Jul 23 19:59:08 2009
mdadm: layout defaults to left-symmetric
mdadm: /dev/sdd1 appears to contain an ext2fs file system
size=976760000K mtime=Thu Jan 1 01:00:00 1970
mdadm: /dev/sdd1 appears to be part of a raid array:
level=raid5 devices=4 ctime=Thu Jul 23 19:59:08 2009
mdadm: layout defaults to left-symmetric
mdadm: /dev/sdb1 appears to be part of a raid array:
level=raid5 devices=4 ctime=Thu Jul 23 19:59:08 2009
mdadm: size set to 976759936K
Continue creating array? y
mdadm: array /dev/md0 started.

root@grml ~ # mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 sdb1[3] sdd1[2] sdc1[1] sda1[0]
2930279808 blocks level 5, 64k chunk, algorithm 2 [4/4] [UUUU]

unused devices:

tadaa sieht mal ganz gut aus. RAID wieder up. Ist darauf direkt ein Filesystem zu finden kann das Filesystem überprüft werden (fsck). Und hoffentlich ist nicht all zu viel im Eimer.

Bei mir kommt auf dem RAID noch LVM zum Einsatz. Darum scanne ich erst mal nach Physical Volumes, Volume Groups und Logical Volumes.

root@grml ~ # pvscan
PV /dev/md0 VG LVM1 lvm2 [2.73 TiB / 1.50 TiB free]
Total: 1 [2.73 TiB] / in use: 1 [2.73 TiB] / in no VG: 0 [0 ]
root@grml ~ # lvscan
inactive Original '/dev/LVM1/home' [300.00 GiB] inherit
inactive '/dev/LVM1/musik' [500.00 GiB] inherit
inactive '/dev/LVM1/software' [458.00 GiB] inherit
inactive Snapshot '/dev/LVM1/home-backup-30-10-2010' [500.00 MiB] inherit

Also die Logical Volumes sind ebenfalls vorhanden.

Allerdings kommt es bei so einem brutalem Ausfall natürlich zu etwas Datenverlust (in der Zeit wo die 2 Platte ausgefallen ist fehlt natürlich einiges). Also muss ein Filesystemcheck bei allen Volumes durchgeführt werden.

root@grml /dev # fsck.ext3 /dev/LVM1/home
...
...
..

Ein Weilchen und viele Fehler später. Können und die überprüften Filesysteme endlich gemountet werden.

root@grml /dev # mount /dev/LVM1/home /mnt/lvm1/home
root@grml /dev # mount /dev/LVM1/musik /mnt/lvm1/musik
root@grml /dev # mount /dev/LVM1/software /mnt/lvm1/software
root@grml /dev # df -h
Filesystem Size Used Avail Use% Mounted on
tmpfs 5.0M 4.0K 5.0M 1% /lib/init/rw
tmpfs 327M 396K 327M 1% /run
udev 1.6G 0 1.6G 0% /dev
rootfs 1.6G 1.3M 1.6G 1% /
/dev/sr0 652M 652M 0 100% /live/image
tmpfs 1.6G 1.3M 1.6G 1% /live/cow
tmpfs 1.6G 0 1.6G 0% /live
/dev/mapper/LVM1-home 296G 145G 136G 52% /mnt/lvm1/home
/dev/mapper/LVM1-musik 493G 294G 175G 63% /mnt/lvm1/musik
/dev/mapper/LVM1-software 451G 398G 31G 93% /mnt/lvm1/software

Endlich Daten da und RAID wieder OK. Jetzt geschwind eine externe Platte raus geholt. Mit cp -a die Daten rauf kopiert und schnell zum Server, auf dem schon ein neu gebasteltes RAID auf die Daten wartet.

Ich hoffe ich kann mit dieser netten Erfahrung den einer oder anderem helfen.

About Florian