Szenario: Ein Rechner mit Linux RAID (Multiple Devices a.k.a 'md'), konfiguriert auf Spiegelung (RAID 1). Eine Platte stirbt. Was tun?

Eindringliche Warnung vorweg: Eine Platte, die einen Fehler aufweist, stirbt. Sie wird sofort getauscht. Alle "modernen" (= jünger als 2002) Festplatten haben einen internen Fehlerspeicher, der die ersten paar hundert Lesefehler völlig eigenständig reparieren kann. D.h. wenn das Betriebssystem anfängt, Fehler zu bemerken, dann ist die Platte hin. Es ist nur noch eine Frage der Zeit, bis die Fehler sich häufen, und den Stress, den man dann hat, das ist es einfach nicht wert. Also: sofort tauschen!

Anfang

So sieht das im Systemprotokoll aus, wenn in einem Linux RAID eine Platte stirbt. Darf ich in diesem Zusammenhang die Verwendung von smartd und logcheck ganz eindringlich empfehlen? Sonst hätte ich davon erst Tage später Wind bekommen. Und einen Produktionsserver tagelang mit einer kaputten Platte zu betreiben, ist ... ungesund.

smartd[1076]: Device: /dev/hdc, SMART Prefailure Attribute:
        198 Offline_Uncorrectable changed from 253 to 100
kernel: raid1: Disk failure on hdc6, disabling device.
kernel: hdc: dma_intr: status=0x59
        { DriveReady SeekComplete DataRequest Error }
kernel: hdc: dma_intr: error=0x01 { AddrMarkNotFound },
        LBAsect=40253068, high=2,low=6698636, sector=8990512
  (... davon etliche ...)
Mar 30 09:04:52 master kernel: hdc: DMA disabled
Mar 30 09:04:52 master kernel: ide1: reset: success
smartd[1076]: Device: /dev/hdc, 1 Offline uncorrectable sectors
smartd[1076]: Device: /dev/hdc, SMART Usage Attribute:
        196 Reallocated_Event_Count changed from 253 to 100
kernel: end_request: I/O error, dev 16:06 (hdc), sector 8990515
kernel: ^IOperation continuing on 1 devices
kernel: raid1: hdc6: rescheduling block 8990512
kernel: md: updating md3 RAID superblock on device
kernel: md: (skipping faulty hdc6 )
kernel: raid1: hda6: redirecting sector 8990512 to another mirror
kernel: md: recovery thread got woken up ...
kernel: md3: no spare disk to reconstruct array! -- continuing in degraded mode
kernel: md: recovery thread finished ...

Ich hatte LILO mit folgender Konfigration laufen

disk=/dev/hda
bios=0x80
lba32
boot=/dev/md0
raid-extra-boot="/dev/hdc,/dev/hda"
root=/dev/md0
install=menu
map=/boot/map
prompt
timeout=50
vga=normal
default=Linux

image=/vmlinuz
        label=Linux
        read-only

Damit schreibt er seinen Bootblock auf beide Festplatten und man kann im Ernstfall von beiden booten.

Recovery

Durch die gute Vorbereitung war das Problem einfach zu lösen. Da ich keinen Hotswap-Controller für die Festplatten hatte, musste die Möhre runtergefahren werden, die defekte Platte getauscht, und wieder hochgefahren. Danach fuhr Linux das RAID im 'degraded mode' hoch, weil er pro Partition nur ein Spiegelelement fand:

kernel: md: multipath personality registered as nr 7
kernel: md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27
kernel: md: Autodetecting RAID arrays.
kernel:  [events: 00000025]
kernel:  [events: 00000026]
kernel: md: autorun ...
kernel: md: considering hda6 ...
kernel: md:  adding hda6 ...
kernel: md: created md3
kernel: md: bind
kernel: md: running: 
kernel: md3: removing former faulty hdc6!
kernel: raid1: md3, not all disks are operational -- trying to recover array
kernel: raid1: raid set md3 active with 1 out of 2 mirrors
kernel: md: updating md3 RAID superblock on device
kernel: md: recovery thread got woken up ...
kernel: md3: no spare disk to reconstruct array! -- continuing in degraded mode
kernel: md: recovery thread finished ...

Das ist auch völlig OK so (solange einem dann nicht ausgerechnet auch die zweite Platte stirbt). Mit der neuen Platte verfährt man dann so:

sfdisk -d /dev/hda > hda.sfdisk-d     # Partitionstabelle synchronisieren
sfdisk /dev/hdc < hda.sfdisk-d
fdisk -l                              # Partitionstabellen vergleichen
mdadm --add /dev/md0 /dev/hdc1        # Neue Partitionen in die RAIDs einfügen
mdadm --add /dev/md1 /dev/hdc2
  ( ... für jede Partition ... )
lilo -v                               # Bootmanager auf beide Platten schreiben
watch cat /proc/mdstat                # beim Rebuild zugucken

Fertig!

Wichtig

Das RAID-Wiederherstellen läuft im Hintergrund ab und mit niedriger Priorität, so dass der Server schon wieder (quasi) voll einsatzbereit ist. Aber: es verlangsamt alle Plattenaktivititaeten ERHEBLICH, also sollte man die Kiste währenddessen in Ruhe lassen und aufwändige Aktionen wie z.B. das Prüfen von MySQL-Tabellen (mysqlcheck) oder Backups möglichst erst später machen!

Grobe Faustregel: Rebuilds bei heutigen Festplattengeschwindigkeiten dauern ca. 1h pro 100GB Plattengröße, wenn der Server parallel noch mit moderater Last weiterläuft. Weniger bei schnellen Platten.