Software RAID5 + LVM gecrasht; tips?

[Spider.007]

Momenteel zit ik met een 900 Gb RAID5+LVM array waar belangrijke data opstaat, waarvan de backup niet nieuw genoeg is en data die ik niet terug kan vinden. Wat hulp wordt dus gewaardeerd. Het volgende is gebeurt:

• Mijn data-set bestond uit 4 x 300Gb schijven, allen opgedeeld in 2 partities, een kleine RAID1 en grote RAID5
• Naarmate de schijven uitvielen heb ik ze vervangen door 500 Gb schijven, echter heb ik ze gerebuild binnen 300 Gb partities
• Inmiddels waren er 3 schijven vervangen door grotere exemplaren
• Die 300 Gb partities waren natuurlijk niet handig; dus heb ik alle drie de schijven 1-voor-1 gefailt; ge-removed, partities vergroot en weer toegevoegd.
• Gister wilde ik de laatste schijf (sdb) vervangen; dus schijf gefailt en geremoved
• Vervolgens de schijf hardwarematig vervangen
• Hierna kon de RAID5 set (md0) plots niet meer gevonden worden; dus gestart vanaf een USB-stick
• Op dat moment kon er geen enkele RAID superblock worden gevonden; dus heb ik de nieuwe schijf weer vervangen door de 300 Gb schijf
• Hierop vond mdadm inderdaad nog een superblock, maar deze schijf was plots geen sdb, maar sdd geworden?
• Hierop heb ik mijn RAID5 set ge-recreate om de superblocks opnieuw aan te maken
• mdadm begon hierop met rebuilden van een van de disks. Dit leek mij niet juist; dus heb ik de array gestopt met mdadm --stop /dev/md0; op dit moment waren enkele honderden MB's gerebuilt
• LVM vond hierna nog steeds geen array; dus ben ik aan de slag gegaan met de gewijzigde volgorde van de disks. Aan de hand van de RAID1 volgorde heb ik de RAID5 opnieuw aangemaakt (dus niet sda2 sdb2 sdc2 sdd2; maar sdc2 sdb2 sda2 sdd2)
• LVM vond toen weer een pv; dus kon ik mijn LVM weer opbrengen.
• Hierop vond ReiserFS echter geen geldig filesysteem...
• Vervolgens heb ik 4 verschillende configs de RAID5 set geprobeerd te assemblen; telkens met 1 van de schijven minder, om de foutief gerebuilde schijf te omzeilen; dit hielp echter niet
• Toen heb ik dus reiserfck zijn tree laten rebuilden; maar deze is geabort tijdens PASS2

Ik begrijp dat het een lastig en lang verhaal is; evenwel hoop ik nog wat tips over wat ik fout heb gedaan; en wat ik eventueel nog kan redden.

[Pim.]

Ik heb geen directe tip voor je maar ik heb hier wat forensische apparatuur en programmatuur die dit soort dingen zou moeten kunnen (rebuild raid, terug vinden data)

DM me anders even

[Nvidiot]

Een mailtje met gedetailleerde info naar de linux-raid mailinglist wil ook nog wel eens helpen, de developers daar posten nogal eens om mensen te helpen met de rebuild van een gefailde raid5 setup.

[Boudewijn]

Pim. schreef op zaterdag 28 februari 2009 @ 15:48:
Ik heb geen directe tip voor je maar ik heb hier wat forensische apparatuur en programmatuur die dit soort dingen zou moeten kunnen (rebuild raid, terug vinden data)

DM me anders even

Heb je wat namen hiervan?

Dit is geen warez request oid, maar ben gewoon benieuwd welke software dit kan.

[Verwijderd]

@Boudewijn

The Sleuth Kit (gebruikt door de Nederlandse overheid) en FCCU (gebruikt in Belgie) wordt wel veel voor forensic doeleinden gebruikt. Het is vrije software dus je kunt het zo downloaden.

http://www.sleuthkit.org/

http://www.lnx4n6.be

Bekijk anders deze site eens: http://www.forensicswiki.org/wiki/Main_Page

[Spider.007]

Nog een update;

Spider.007 schreef op zaterdag 28 februari 2009 @ 13:57:
• mdadm begon hierop met rebuilden van een van de disks. Dit leek mij niet juist; dus heb ik de array gestopt met mdadm --stop /dev/md0; op dit moment waren enkele honderden MB's gerebuilt

De aanname die ik hierin deed was dat het door elkaar gooien van de schijfvolgorde automatisch tot corruptie zou leiden; deze was bij nader inzien niet correct. Het XOR algoritme dat gebruikt wordt leidt tot dezelfde resultaten; ongeacht de volgorde waarin uitvoert. Blijkbaar klopten mijn parity blokken voor een groot gedeelte gewoon niet; wat voorkomen had kunnen worden door maandelijks een (preventieve) resync uit te laten voeren

Hiernaast heb ik dus niets meer van de disks kunnen redden; gelukkig nog wel een extra backup terug gevonden dus de belangrijkste data weer terug.