[fedora] schijf uit raid5 gecrashed, problemen bij vervangen

[codemann]

Het begon allemaal met een schijf uit m'n raid5 configuratie die stuk bleek te zijn.
Geen probleem, schijf was nog in garantie, dus een nieuwe schijf gehaald, de huidige drive uit m'n raid als faulty gezet (-f) en uit de raid gehaald (-r).

Daarna de server afgesloten, de schijf vervangen, en opnieuw opgestart. Partitie op de schijf gemaakt en deze op "linux raid autodetect" gezet. Geformatteerd en alles in orde.

Nu had ik ondertussen gezien dat de raid niet goed terug in orde gekomen was, maar dat zou ik wel even in orde maken... Dacht ik.

Ik assemble de array opnieuw :

# mdadm --assemble /dev/md0 --verbose /dev/sd[bcefg]1
mdadm: looking for devices for /dev/md0
mdadm: /dev/sdb1 is identified as a member of /dev/md0, slot 6.
mdadm: /dev/sdc1 is identified as a member of /dev/md0, slot 1.
mdadm: /dev/sde1 is identified as a member of /dev/md0, slot 3.
mdadm: /dev/sdf1 is identified as a member of /dev/md0, slot 5.
mdadm: /dev/sdg1 is identified as a member of /dev/md0, slot 4.
mdadm: no uptodate device for slot 0 of /dev/md0
mdadm: no uptodate device for slot 2 of /dev/md0
mdadm: added /dev/sde1 to /dev/md0 as 3
mdadm: added /dev/sdg1 to /dev/md0 as 4
mdadm: added /dev/sdf1 to /dev/md0 as 5
mdadm: added /dev/sdb1 to /dev/md0 as 6
mdadm: added /dev/sdc1 to /dev/md0 as 1
mdadm: /dev/md0 assembled from 4 drives and 1 spare - not enough to start the array.

Dat begint al niet goed... Hoe kan hij zowel op slot 0 als slot 2 geen uptodate device vinden?
Er zaten maar 6 schijven in de raid array en hij vindt er toch 5.

Als ik dan het resultaat bekijk zie ik :

# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : inactive sdc1[1](S) sdb1[6](S) sdf1[5](S) sdg1[4](S) sde1[3](S)
      3662859520 blocks

unused devices: <none>

Allemaal spares? Hoe kan dat?

Als ik dan toch probeer om de andere schijf toe te voegen krijg ik :

# mdadm --manage /dev/md0 --add /dev/sdd1
mdadm: cannot get array info for /dev/md0

Iemand enig idee? Ik zit al een uur te zoeken en ik lees altijd hetzelfde, ik weet niet meer waar ik nog op kan zoeken...

[codemann]

Ik heb nog wat verder zitten zoeken, als ik "mdadm --examine --scan" doe met mijn nieuwe schijf dan geeft hij een optie met 4 schijven en 1 spare, of met 6 schijven en 2 spares... Allebei fout dus.

Ik heb dan maar voorlopig mijn oude schijf terug ingestoken, met de gedachte dat mocht ik iets vinden morgen dat ik met die situatie terug zou moeten beginnen, dat ik dan toch mijn raid terug hebben kunnen laten recoveren.

Ik krijg dan :

# mdadm --assemble /dev/md0 /dev/sd[bcdefg]1
mdadm: /dev/md0 assembled from 4 drives and 1 spare - not enough to start the array.

Waarna ik probeerde :

# mdadm --assemble /dev/md0 /dev/sd[bcdefg]1 --force
mdadm: forcing event count in /dev/sdd1(2) from 506634 upto 506642
mdadm: clearing FAULTY flag for device 2 in /dev/md0 for /dev/sdd1
mdadm: /dev/md0 has been started with 5 drives (out of 6) and 1 spare.

Nu is hij aan het recoveren, maar ik begin er minder en minder in te geloven...


Ik moet trouwens ook nog iets anders vertellen, bij het booten vindt hij altijd default 2 raids, die ik dan moet stoppen en opnieuw assemblen. Ik heb hier heel vroeger al eens achter gezocht, maar ik vond hier geen reden voor. Gezien mijn server hooguit 1x per jaar ofzo afgezet wordt, is dit een beetje vergeten.
Maar nu ben ik aan het denken... Vond hij misschien altijd 2 raids omdat er 2 spares waren?

[gertvdijk]

codemann schreef op donderdag 10 december 2009 @ 23:52:
Ik assemble de array opnieuw :

# mdadm --assemble /dev/md0 --verbose /dev/sd[bcefg]1

Dat begint al niet goed... Hoe kan hij zowel op slot 0 als slot 2 geen uptodate device vinden?
Er zaten maar 6 schijven in de raid array en hij vindt er toch 5.

Kijk eens naar je ingevoerde commando: je geeft zelf maar 5 schijven op!
Weet je trouwens wel welke sdX welke schijf is? Dat kan elke boot verschillen natuurlijk.

codemann schreef op donderdag 10 december 2009 @ 23:52:
Als ik dan het resultaat bekijk zie ik :

# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : inactive sdc1[1](S) sdb1[6](S) sdf1[5](S) sdg1[4](S) sde1[3](S)
      3662859520 blocks

unused devices: <none>

Allemaal spares? Hoe kan dat?

Heel vreemd inderdaad.

codemann schreef op vrijdag 11 december 2009 @ 01:16:
Ik moet trouwens ook nog iets anders vertellen, bij het booten vindt hij altijd default 2 raids, die ik dan moet stoppen en opnieuw assemblen. Ik heb hier heel vroeger al eens achter gezocht, maar ik vond hier geen reden voor. Gezien mijn server hooguit 1x per jaar ofzo afgezet wordt, is dit een beetje vergeten.
Maar nu ben ik aan het denken... Vond hij misschien altijd 2 raids omdat er 2 spares waren?

Dat lijkt op een gevalletje dat ik ook een keer op een Debian Etch bak (met historie vanaf Woody) heb meegemaakt. Om de één of andere reden moest ik hem altijd handmatig vertellen dat een bepaalde schijf ook bij de array hoorde. Nooit echt opgelost, er is later een reinstall gedaan.

[codemann]

gertvdijk schreef op vrijdag 11 december 2009 @ 02:18:
[...]

Kijk eens naar je ingevoerde commando: je geeft zelf maar 5 schijven op!
Weet je trouwens wel welke sdX welke schijf is? Dat kan elke boot verschillen natuurlijk.

Moet dat dan niet zo? Ik dacht om de array met de nieuwe schijf aan te maken dat ik eerste de assemble op de 5 resterende schijven moest doen om daarna de nieuwe schijf apart te adden?


Mijn RAID5 staat er nu trouwens weer met mijn oude schijf (die wordt gedetecteerd als Faulty) :

# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 sdc1[1] sdb1[6](S) sdf1[5] sdg1[4] sde1[3] sdd1[7](F)
      3662859520 blocks level 5, 64k chunk, algorithm 2 [6/4] [_U_UUU]

unused devices: <none>

En ik zie het volgende :

# mdadm --examine --scan
ARRAY /dev/md0 level=raid5 num-devices=4 UUID=b61485d6:d5786671:7ae46221:e01c5828
   spares=1
ARRAY /dev/md0 level=raid5 num-devices=6 UUID=d0d2f966:d26aef14:33b05f34:0ae3abfb
   spares=1

[gertvdijk]

codemann schreef op vrijdag 11 december 2009 @ 08:49:
Moet dat dan niet zo? Ik dacht om de array met de nieuwe schijf aan te maken dat ik eerste de assemble op de 5 resterende schijven moest doen om daarna de nieuwe schijf apart te adden?

Ah ja, true.
Maar dat zou ie toch moeten autodetecten? Juist, dat is je probleem.

codemann schreef op vrijdag 11 december 2009 @ 08:49:
Mijn RAID5 staat er nu trouwens weer met mijn oude schijf (die wordt gedetecteerd als Faulty) :

Weet je zeker dat je sdd eruit haalt, btw?

codemann schreef op vrijdag 11 december 2009 @ 08:49:
En ik zie het volgende :

# mdadm --examine --scan
ARRAY /dev/md0 level=raid5 num-devices=4 UUID=b61485d6:d5786671:7ae46221:e01c5828
   spares=1
ARRAY /dev/md0 level=raid5 num-devices=6 UUID=d0d2f966:d26aef14:33b05f34:0ae3abfb
   spares=1

Dat is wel heel spannend. Zo te zien is er nog metadata aanwezig op de harddisks van een oudere/vroegere array... Naar welke devices wijzen die UUIDs? (/dev/disk/by-uuid/ bijv. of blkid) Want 2x md0 lijkt me beetje sterk.

[codemann]

gertvdijk schreef op vrijdag 11 december 2009 @ 13:26:
Dat is wel heel spannend. Zo te zien is er nog metadata aanwezig op de harddisks van een oudere/vroegere array... Naar welke devices wijzen die UUIDs? (/dev/disk/by-uuid/ bijv. of blkid) Want 2x md0 lijkt me beetje sterk.

Ah dat is van mijn oude array, dat verklaart inderdaad. Daarom heeft hij misschien ook problemen om de raid goed samen te stellen bij het booten? Kan ik die oude array verwijderen?

Hij maakt altijd /dev/md0 en /dev/md_d0 als je dat bedoelt.

# blkid
/dev/mapper/VolGroup00-LogVol00: UUID="4262fd92-d638-4c2d-9197-5db2c541c99e" TYPE="ext3"
/dev/mapper/VolGroup00-LogVol01: TYPE="swap" UUID="73d6af1b-6593-49df-9e34-414f27efb9eb"
/dev/sda1: LABEL="/boot" UUID="53d3bdd2-63c8-461f-bdf7-fecdb4fe6bb6" TYPE="ext3" SEC_TYPE="ext2"
/dev/sda2: LABEL="/tmp" UUID="48952d62-58da-46e8-8c3b-f9ffe42c953b" TYPE="ext3" SEC_TYPE="ext2"
/dev/sda3: UUID="A06cPC-ImbF-LplA-vFGR-ioVh-K93l-zjavGt" TYPE="lvm2pv"
/dev/VolGroup00/LogVol00: UUID="4262fd92-d638-4c2d-9197-5db2c541c99e" TYPE="ext3"
/dev/VolGroup00/LogVol01: TYPE="swap" UUID="73d6af1b-6593-49df-9e34-414f27efb9eb"
/dev/sdb: UUID="d68514b6-7166-78d5-2162-e47a28581ce0" TYPE="mdraid"
/dev/sdb1: UUID="66f9d2d0-14ef-6ad2-345f-b033fbabe30a" TYPE="mdraid"
/dev/sdc: UUID="d68514b6-7166-78d5-2162-e47a28581ce0" TYPE="mdraid"
/dev/sdc1: UUID="66f9d2d0-14ef-6ad2-345f-b033fbabe30a" TYPE="mdraid"
/dev/sdd: UUID="d68514b6-7166-78d5-2162-e47a28581ce0" TYPE="mdraid"
/dev/sdd1: UUID="66f9d2d0-14ef-6ad2-345f-b033fbabe30a" TYPE="mdraid"
/dev/sde1: UUID="66f9d2d0-14ef-6ad2-345f-b033fbabe30a" TYPE="mdraid"
/dev/sde: UUID="d68514b6-7166-78d5-2162-e47a28581ce0" TYPE="mdraid"
/dev/mapper/VGRAID-LVRAID: UUID="0b9cd9f4-e56b-4fe6-9206-7fa4887eb1c5" TYPE="ext3"
/dev/sdg1: UUID="66f9d2d0-14ef-6ad2-345f-b033fbabe30a" TYPE="mdraid"
/dev/sdf1: UUID="66f9d2d0-14ef-6ad2-345f-b033fbabe30a" TYPE="mdraid"

Ik zie de link wel niet tussen deze info en die ik krijg met "mdadm --examine --scan"

En in de map /dev/disk/by-uuid/

# ls -al /dev/disk/by-uuid/
total 0
drwxr-xr-x 2 root root  80 2009-12-11 01:11 .
drwxr-xr-x 6 root root 120 2009-12-11 01:11 ..
lrwxrwxrwx 1 root root  10 2009-12-11 01:11 48952d62-58da-46e8-8c3b-f9ffe42c953b -> ../../sda2
lrwxrwxrwx 1 root root  10 2009-12-11 01:11 53d3bdd2-63c8-461f-bdf7-fecdb4fe6bb6 -> ../../sda1

Maar sda is de schijf waar linux op staat, geen schijf uit de RAID.

[gertvdijk]

Het ging me om de UUID van md0 van de array die je wil 'redden', maar blijkbaar staat die er niet tussen.
Je kan mogelijk iets forceren in mdadm met UUIDs misschien (geen idee).
Heb je zelf enig idee waar je 'oude' array staat dan? heb je nog partities op je schijven die daarvan waren? of heb je ooit wat geklooid met RAID op een LVM volume?

Maar even terug naar een paar posts terug: heb je nou je array lopen rebuilden met een faulty schijf?

[codemann]

gertvdijk schreef op vrijdag 11 december 2009 @ 14:03:
Maar even terug naar een paar posts terug: heb je nou je array lopen rebuilden met een faulty schijf?

Ja als ik de oude schijf terug aanhang dan kan hij de array recoveren, hij staat nu actief, maar wel niet gemount ofzo. En er is inderdaad ook een LVM actief op de RAID.

[ Voor 6% gewijzigd door codemann op 11-12-2009 14:15 ]

[codemann]

Iemand nog een idee? Als ik al aan de huidige data zou kunnen geraken om het even over te kopieren en daarna vanaf 0 de raid terug op te bouwen is mij goed... Maar momenteel ben ik alles kwijt

[jayvol09]

Als ik jou was had ik die array assembled met alle schijven, dan ziet ie misschien de nieuwe schijf als een spare en gaat ie rebuilden. Ik weet niet of t wel nodig is de nieuwe schijf te partitioneren en formateren maar zou geen kwaad gedaan kunnnen hebben. Probeer evt optie --scan mee te geven met assemble. Als je een config file voor mdadm gebruikt kan dit misschien een probleem veroorzaakt hebben?

[codemann]

jayvol09 schreef op maandag 14 december 2009 @ 00:52:
Als ik jou was had ik die array assembled met alle schijven, dan ziet ie misschien de nieuwe schijf als een spare en gaat ie rebuilden. Ik weet niet of t wel nodig is de nieuwe schijf te partitioneren en formateren maar zou geen kwaad gedaan kunnnen hebben. Probeer evt optie --scan mee te geven met assemble. Als je een config file voor mdadm gebruikt kan dit misschien een probleem veroorzaakt hebben?

Met 7 schijven ipv de 6 waaruit de raid array bestond? Het is het proberen waard, maar ik betwijfel dat dit gaat lukken.

[jayvol09]

ja of met 6 zonder de faulty

[codemann]

jayvol09 schreef op maandag 14 december 2009 @ 12:59:
ja of met 6 zonder de faulty

Met 6 zonder de faulty lukt onmogelijk, als ik hem dan geforced assemble dan detecteert hij altijd 2 spares. Met 7 heb ik nog nie geprobeerd, maar ik betwijfel dat dat iets gaat geven.

[swbr]

Niet dat je er nu iets aan hebt, maar als je een bestaande array afbreekt kun je het beste het volgende commando uitvoeren voor elke disk die je uit de array hebt gehaald:

# mdadm --zero-superblock /dev/sdX

Op die manier staat er niets meer op je disk waarvan mdadm in de war kan raken.