Oui une histoire de fou ...

Mardi 11/3 je suis à Gand pour l'event Microsoft Server 2008 Launch (pas mal d'ailleurs), vers 14h51, un disque tombe en panne dans notre SAN sur l'array principal (un énorme volume RAID 5 de 28 disques en cours de migration vers des plus petits). Personne ne s'en rend compte, apparemment l'envent analyzer est tombé en rade

Jusque là rien de bien grave on est en RAID 5, une panne d'un disque n'a jamais tué personne !

Plus tard dans le nuit, 23h49, un deuxième disque de ce même array crash. Mail d'alerte de l'Enterprise Manager sur nos BlackBerry, la base Oracle n'est plus accessible. A cette heure là, personne ne voit le mail.

Le lendemain vers 6h58, un troisième disque plante toujours dans le même array!

8h20, appel d'un collègue : Plus de mail et plus d'accès au billing system. le SAN est rouge, trois disques sont morts !!!!!!

J'arrive au boulot tant bien que mal (c'était le jours de l'entretien de la voiture) et je constate l'ampleur des dégâts :

- Exchange : tous les stores sont tombés (BE, UK, CH, et un autres store énorme qui nous est sous traité pour une société soeur réppartie un peu partout en Afrique)
- Oracle : tout planté : 300 Gb de données corrompue.
- File server : la partition dédiée à l'IT est inaccessible

Je remplace immédiatement par des disques de spare, je réactive les volumes et je laisse le rebuild se faire.

Une fois les volumes accessible, on est partit avec chkdsk ... sur 300 Gb je vous dis pas la durée.

Résultat :

- Exchange, les transactions logs sont ok mais j'ai 3 stores de corrompu dont le plus gros.
- File : drive IT toujours illisible et carrément perdu par le système
- Oracle : 40% des datafiles de 4 Gb sont à 0 Kb !

On sort l'artillerie lourde et on commence à restaurer.

- File : Pas de soucis, le drive IT est sur pied en 3 minutes (merci le LTO2).
- Exchange : on passe la nuit avec ESEUTIL -p mais on y arrive tant bien que mal.
- Oracle : impossible de restaurer le control file !!!!!! (sans lui pas de base).

Après 6 jours avec le support HP (Data Protector) en Inde, 3 jours avec le support Oracle, 3 nuits totalement blanche et 6l de coke, on a restauré 480 Gb depuis nos bandes (Data File et Archive Logs) et un control file +/- viable ...
Par contre, on a jamais réussi à retrouver le control file valable qui a pourtant été sauvegardé.

Au moment où j'écris ces lignes, on est pas encore 100% sauvé car la base joue les logs en ce moment et ce depuis 15h30 ... 160 logs file de 350 Mb chacun ... c'est loooonnnngg.

D'après HP : "on a pas eu de chance" ... des commentaires comme ça je m'en passe bien surtout après tout ce stress ...

Moralité : on est jamais à l'abri de _RIEN_

Sur ce, bonsoir

Benh dis, ça fait mal

Dans le futur, cela sent les tests de "récupération en cas d'incident" à partir des backups?

outch

ca fait mal

quand je pense que je me plaignait d'avoir perdu un raid 0 et un raid 5 mais ce n'était que des données privées, j'ai encore les disques en l'état pour le cas ou, je suis triste mais pas de conséquences pour autruit

p'tain

C'est exactement le genre d'histoire que je ne dois *pas* lire en ce moment, vu que je pars en vacances samedi 22 pour une semaine et je suis le seul resp IT au boulot, les systèmes *doivent* tenir !!...

Ca y est je recommence à stresser comme un veau merci Vector

Bon, l'histoire se termine bien. Mais voici la suite :

Application de tous les archive logs terminé aujourd'hui à 6h35. Manque de bol ... il nous en manquait un !!!

Re-restore depuis la bande, re-application ... depuis 8h30 la base tourne et nos développeurs font les cross check. Dès que c'est validé : BACKUP SUR DISQUE et ensuite backup file système sur bande.

L'histoire avec HP est loin d'être terminée mais ... mon cœur a reprit un rythme normal et mon près hypotécaire sur 30 ans sera remboursé ... jusque ici ... dedjeu ... quel stress pendant une semaine je vous raconte pas !!!



Ovh> ne t'en fait pas trop ... mais la leçon à tirer est : ça n'arrive pas qu'aux autres

Zion> Clair que la politique de backup va changer, je dis NON à toutes les intégrations, rien ne vaut un bon file système backup.

Sphynx> Oui j'ai aussi perdu des photos lors d'un crash disque perso ... mais perde toutes les données qui servent à facturer nos clients c'est pire que tout ... on facture 4 millions d'USD par mois ... c'est vraiment pas le truc où il faut se louper

J'espère que mon expérience servira à d'autres. Ne faites jamais de RAID trop grand ... même si vous êtes convaincu des performances (plus le RAID est grand, plus il y a d'IO plus c'est rapide ...). Par contre quand ça plante ... c'est CATA

Sur ce je vais voir où en sont les autres ... j'ai bossé une semaine jour et nuit ... ils peuvent travailler un peu maintenant

Bon repos

On a tous (quasi) connu quelques jours de crise, chacun à son niveau, faudra bien quelques semaines pour t'en remettre

Le tout représente quoi, 300GB de données? Vous avez pas pensé à une réplication sur un système moins performant?

Parce que la crainte est forte dans notre profession vis à vis des disques, mais il n'y a pas que les disques qui claquent, un deuxième système répliqué en temps réel ou synchronisé une fois par jour peut être intéressant et pas trop coûteux, non?

question, les disques venaient tous du meme lot ?

car cela augmente le risque de claquage en cascade il me semble

sphinx> +1

Vector> Le point faible dans ton histoire, c'est la notification de la panne de RAID. Un RAID qui ne prévient pas qu'il lâche, ça sert à rien, la preuve...

Le deuxième point faible aurait sans doute été la disponibilité immédiate de pluseurs disque spare. En général on en prévoit un, mais c'est une bonne leçon à tirer...

C'est pas de bol en effet.
Les disques d'une même série ne doivent jamais faire partie du même RAID
2 machines/storages répliqués dans 2 batiments différents aurait pu vous éviter tout ce stress. Et en cas de désastre (incendie dans la salle,etc) de pouvoir redémarrer la production presque instantanément.
Ca coûte plus cher à l'achat, mais c'est vite amorti dès qu'un problème de ce genre survient

Philfr> En général , c'est 1 disque spare par RAID, ça laisse de temps de remplacer le disque défectueux.

En fait on envisage depuis quelques temps déjà de faire un environnement stand-by ... mais vu les couts ... personne n'a encore donné sont feu vert.

Je pense que ce genre d'incident aussi stressant et critique soit-il nous servira pour justifier ce système redondant !

(Oracle RAC et mirroring)

C'est ce que HP a dit ... même batch avec numéro de série consécutifs = plus grande chance de problème ...

Mais faut pas exagéré !

Finalement on a analysé les logs et les disques 3 et 4 on crashé dans la même seconde ... ça pue de chez pue ....

Ok 1 point ...

On a deux bâtiments, séparé par 12 paires de fibres de 100m ... le problème c'est que la redondance avec le second SAN n'a jamais marché ... et un EVA c'est au dessus de nos moyens ...

Comme je disais plus haut, les désastres justifient les investissements !

Voilà, on s'est sorti d'affaire jusque ici ... la base se met à jour avec les données quotidiennes ... ça devrait être 100% à jour samedi, mais au moins, les gens peuvent travailler. Les Cubes Cognos sont en cours de mise à jour également

Le backup disque à mis 3h ... au lieu des 17h sur bande, suffit maintenant de les copier su bande mais on souffle ...

But du jeu aujourd'hui, relancer tous les backup jobs et les vérifier. Mise à jour des procédures et autre ...

Tout roule !!!

Rapport envoyé au top management ... la réaction ne devrait pas être longue à tomber