Récupération de données Raid 5 HP Proliant

Un de nos clients nous a apporté son serveur Raid. Il s'agit d'un serveur HP Proliant LM350 avec une carte contrôleur Smart Array P420i. Ce serveur contient 4 disques durs SAS en Raid5, et géré par un système d'exploitation Windows Server. Le serveur ne fonctionne plus, les données ne sont plus accessibles. Voici les détails de ce cas de défaillance d'un serveur Raid.

Le serveur HP Proliant Raid 5 contient 4 disques durs en SAS, 3 disques durs pour le Raid5 et un disque de remplacement (Hot Spare). Très souvent, lors de l'acquisition d'un serveur Raid ou bien d'un support de stockage multi-disques, l'utilisateur ne fait pas attention à un détail très important et à prendre sérieusement en compte pour la sécurité des données et la possibilité de récupérer les données du serveur. Ce détail découle d'une observation purement expérimentale et n'a absolument rien à voire avec le principe de fonctionnement du serveur et du Raid 5.

Ce détail concerne les disques durs membres du Raid. Très souvent, ces disques sont identique : marque,modèle, Firmware et ils ont un numéro de série très proche. Ce qui suppose que les disque font partie du même lot. Comme dans toutes les industries, ces disques ont les mêmes caractéristiques physiques et fonctionnelles. Par conséquent, ils ont les mêmes défauts. Ces disques sont exposés aux mêmes conditions de fonctionnement : température, humidité et charge. Il est tout à fait cohérent, que ces disques sont exposés au même degré d'usure. La durée séparant leurs pannes, pour les mêmes raison, ne dépasse pas la marge d'erreur dans la fabrication de leurs composants électroniques. Le paradoxe est que si les composants électroniques sont de bonne qualité et leurs marges d'erreurs est très étroits, cela va se répercuter sur la durée qui sépare leurs pannes. Une qualité qui génère défaut ! Par conséquent, lorsqu'un disque tombe en panne ou entame sa période du début de la fin, les autres disques suivront très rapidement.

Cette précédente présentation est l'histoire type de chaque Raid tombant en panne. C'est exactement ce qui est arrivé à notre client. Plus précisément, un des disques du Raid5 était en difficulté, mais fonctionne toujours. Peut-être le disque "Hot Spare" est entré en action, ou non. Le client a essayé d'entrer en contact avec la Hot Line de la marque. Ils ont effectué certainement des manipulations dont le client ne parle pas. Par contre, le client confirme qu'un des disque a été remplacé et le serveur a tenté une reconstruction du Raid 5. Bref, trop de dires en contradiction.

En fin de compte, nous avons reçu trois disques SAS, un noté HS, et les deux autres sans aucune mention. La seule information fiable est que ces disques formaient un Raid 5 dont on ne connais absolument aucun paramètre. Le client était très pressé et a commandé un traitement en urgence. L'aventure a commencé !

Lors de l'analyse des trois disque afin de déterminer les paramètres du Raid, plusieurs difficultés ont été rencontrées :

• Il n'y avait aucune information sur les paramètres les plus importants du Raid 5 : bloc size, ordre des disque, synchronisation et décalage.
  
• Toutes les analyses convergent vers un seul constat : le disque du Raid 5 supposé parfaitement fonctionnel ne peut pas faire partie du Raid 5.
  
• Le client assure qu'il n'a pas d'autre disque à faire parvenir et qu'il n'a pas effectué des manipulations pouvant compromettre le Raid 5, de type permutation de disques par exemple.
  

• Le Raid5 HP Proliant était un Raid simple et conventionnel.
• Le bloc size était de 256 KB, soit 512 secteurs.
• Aucun décalage de blocs du Raid5 n'a été détecté.
• La synchronisation du Raid5 est à gauche (backward).
• Le Raid5 était synchrone.
• Deux disques sur trois (les plus lents) ont été utilisés pour construire le Raid 5.
• Le disque en bon état a été exclu de la grappe du Raid 5.

• La bonne nouvelle est que des fichiers de l'ordre de plusieurs méga-octets et plusieurs giga-octets ont été parfaitement fonctionnels. CVe qui prouve que le Raid5 a bien été construit.
• La mauvaise nouvelle est que lors de test des fichiers *.pst (base mails Outlook), pesant plusieurs giga-octets, ilk manque des mails datant d'une quinzaine d jours. Ce sont les données les plus importantes pour le client.

Vu ces résultats critiquables de la part de l'utilisateur et très parfait de notre part, on peut en arriver aux conclusions suivantes :

• Le Raid 5 a été auto corrompu par le serveur HP Proliant lui même.
• Comme il y a deux disques lents sur trois formant le Raid5, l'enregistrement des bloc et les calculs des bloc de parité, n'étaient pas effectués correctement, car ces disques lents ne pouvaient pas suivre la cadence de distribution des blocs de données.
• Comme il y avait un seul disque déclaré HS, le serveur HP Proliant n'a pas réussit à détecter le deuxième disque défaillant. Par conséquent, il ne s'est pas arrêté à temps et a continuer à fonctionner en mode dégradé. Ce qui a dégradé davantage les données.
• Nous avons la certitude que si le serveur avait détecté la défaillance d'un deuxième disque les données n'auraient pas été auto-corrompues et manquantes.