rssLink RSS for all categories
 
icon_orange
icon_green
icon_green
icon_orange
icon_red
icon_green
icon_green
icon_orange
icon_red
icon_red
icon_green
icon_green
icon_green
icon_blue
icon_orange
icon_red
icon_green
icon_blue
icon_red
icon_red
icon_green
icon_red
icon_red
icon_blue
icon_orange
icon_green
icon_green
icon_red
icon_green
icon_blue
icon_green
icon_green
 

FS#5897 — xc11.mail.ovh.net

Attached to Project— Emails
Incident
exchange
CLOSED
100%
De nombreuses base de données de ce serveur semblent corrompues, nous tentons de réparer les bases de données et récupérons
le backup interne en parallèle, par sécurité
Date:  Thursday, 03 November 2011, 08:20AM
Reason for closing:  Done
Comment by OVH - Monday, 10 October 2011, 16:15PM

Nous récupérons le snapshot de midi. La copie est en cours. Elle est à 60% terminée.


Comment by OVH - Monday, 10 October 2011, 22:39PM

La récupération depuis le snapshot de midi n'a pas fonctionné.
Nous sommes en train de reprendre le backup le plus vieux.


Comment by OVH - Monday, 10 October 2011, 23:27PM

Nous mettons en place un serveur Exchange sur lequel nous allons brancher les disques de backup.
A partir de là nous devrions pouvoir récupérer la base initiale.

En parallèle nous regardons les snapshot au niveau de l'infrastructure. Un snapshot non terminé le 08 octobre semble
être à l'origine du problème. Nous essayons de récupérer ce snapshot.


Comment by OVH - Tuesday, 11 October 2011, 01:05AM

Nous avons remis le service avec un nouveau serveur Exchange pour que les nouveaux emails soient reçus
et puissent être récupérés.

En parallèle nous travaillons sur 2 versions du backup, la première datant de hier 20h, et l'autre
datant de 5 jours.
Quand un des backup sera recupéré, nous reinjecterons les emails dans le nouveau serveur Exchange en production.


Comment by OVH - Tuesday, 11 October 2011, 03:45AM

Nous avons reussi à corriger le snapshot qui était à l'origine de toute la chaine de problèmes.
Ainsi nous avons pu récupérer le serveur d'origine sans avoir à revenir en arrière.

Nous faisons l'état du serveur récupéré et de toutes les bases Exchange.


Comment by OVH - Tuesday, 11 October 2011, 10:28AM

la VM xc11 qui assure le service d'exchange pour
quelques clients a planté vers 11h10 sans raison.
Apres un essai de redemarrage, on s'est apperçu
que les données ont été corrompues et qu'il n'était
pas possible de remonter la VM dans l'état.

Nous avons alors regardé les backups afin de
recuperer un backup de la VM en question. On
effectue un backup VMware toute les heures. On
s'est apperçu que les données étaient corrempus
sur tous les backups sur 2 jours.

Nous avons aussi un 2ème systeme de backup basé
sur le ZFS, mais qui garde les backups sur 24H
seulement. Donc comme les données étaient pas
bonnes sur 2 jours, le backup ZFS n'était pas
utiles.

Nous avons donc travailé sur 2 directions: essayer
de recuperer la VM dans l'état de fonctionnement
il y a 5 jours et essayer de corriger l'état de
la VM de 11h15.

A chaque fois il faut copier les 60Go de données
pour remonter la VM puis il faut retravailer les
données pour les rendre bootable. Cela prend 1h30
à chaque opération.

C'est pourquoi on a decidé de demarrer une
VM avec tous les comptes de clients mais vierges
en emails. Tres tardivement on aurait dû le faire
dés 13H00 hier. Au moins tous les emails nouveaux
arriveraient sans retard. Et on s'occuperait de
recuperer les emails anciens uniquement

Vers 3h30 nous avons reussi à remonter la VM de
11h10 en RO et on recupere actuellement les emails
de cette VM pour les reinjecter dans la nouvelle
VM.

Cette opération est toujours en cours.

Plusieurs consequences à ce probleme inhabituel:
- nous allons augmenter la durée de vie de backup ZFS
afin de recuperer une VM en etat de fonctionnement
très rapidement
- mettre en place une procedure automatique de
demarrage d'une nouvelle VM vierge en cas de probleme
aussi grave
- comprendre ce qui a pu se passer au niveau de la VM
et voir comment on peut l'eviter, il s'agit de corruption
de bases de données de l'Exchange lui-meme et donc de
problemes interne au systeme


Comment by OVH - Tuesday, 11 October 2011, 11:56AM

63 domaines (avec ses emails) ont été recuperé
sur 77 domaines que la VM héberge. On regarde
pour la recuperation du reste.


Comment by OVH - Tuesday, 11 October 2011, 16:58PM

Nous allons ajouter un dossier 'ovh-recover' pour les comptes concernés.
Nous sommes actuellement entrain d'insérer les emails manquants progressivement.


Comment by OVH - Wednesday, 12 October 2011, 00:35AM

Les databases sont toujours en cours de réparation.
Les données comptes sur les domaines les plus importants ont été restaurées avec succès.

Le travail continue toute la nuit, nous espérons pouvoir terminer dans la journée.


Comment by OVH - Wednesday, 12 October 2011, 12:52PM

Sur 77 domaines il nous restait 14 domaines à recuperer. 7 ont été
recuperés. Les 7 restants il n'y a plus aucun espoir de les recuperer.

Le systeme de backup remonte à quelques jours et les base de données
exchange sont abimés depuis bien plus longtemps. Apparement les bases
ont commencé à se corromprent il y a 10-14 jours. Il aurait fallu
d'avoir le backup brute d'il y a 2 semaines pour recuperer ces 7 domaines.
En ayant le backup logique de seulement quelques jours en arriere ce
n'est pas suffisant dans ce cas figure.

L'origine du probleme a été idéntifiée. C'est le fait de faire
les backups qui a mis en défaut les bases de données. Pendant
les backups la VM est gelée quelques secondes et visiblement un
jour sur un VM ça a provoqué une corruption de bases de données.
Comme le backup globale est la somme de tous les backup, et
dedans il y a ce backup pourri, la somme n'est plus exploitable.
Nous avons quand meme reussi à remonter dans le temps et enlever
les snaps mauvais pour essayer de recuperer certaines bases.
Nous avons dû enlever les snaps puis checker le systeme et recuperer
base par base sur chaque (backup-snap de l'heure). 70 bases de
données ont été recuperés, mais pour les 7 restants il aurait fallu
remonter encore plus dans le temps c'est à dire à plus d'1 semaine.

Donc meme si on a le backup de 10h30, soit 1H avant la panne, ce
backup n'est pas exploitable puisqu'il s'additionne sur l'ensemble
de backup que nous avons fait chaque heure depuis quelques semaines.

Les correctives en cours:
- 3 niveaux de backup:
- on installe un backup applicatif, c'est à dire que Exchange
lui-meme a son propre systeme de backup et on va donc l'utiliser.
Exchange va backuper ses propres bases de données
- on installe un backup systeme, c'est à dire que via
le VMware Data Recovery on va backuper les vmdk de chaque VM
- on installe un backup stockage, c'est à dire que sur le ZFS
on va pouvoir remonter à 1 mois, au lieu de 1 heure. ce backup
est en plus backupé sur un autre media dans un autre datacentre

- la gestion de panne automatique et en quelques minutes
- on met en place une procedure automatique lors d'une panne d'une
VM. dés que nous avons un downtime de quelques minutes sur un systeme
Exchange, nous allons désormais demarrer un nouveau systeme Exchange
pre-configuré avec tous les comptes email et nous allons le mettre
en production au bout de 15 minutes de panne. Ainsi, les clients
pourront toujours recevoir les nouveaux emails et continuer à communiquer.
Et en parallele on va s'occuper de recuperer les emails ancien du 1er,
du 2ème et du 3ème backup. Le but est d'avoir le minimum de downtime
sur le present.

On va contacter l'ensemble des clients impactés par cette panne
pour leur expliquer. Sur les 77 domaines, uniquement 2 clients sont
entrés en contact avec le support d'Ovh. Il est donc important
d'expliquer aux 75 autres ce qu'il s'est passé et ce qu'on va faire
dés maintenant pourque ça n'arrive plus.

Les 7 domaines deviennent gratuit à vie.
Les 70 domaines sont gratuits jusqu'à la fin de l'année.


Comment by OVH - Thursday, 13 October 2011, 14:51PM

Nous continuons de récupére les données et de les insérer dans les comptes correspondant.

15% des domaines concernés ont été recouvrés, l'opération est longue car exchnage n'autorise qu'un
seul montage de base de donnée en état de réparation à la fois.


Comment by OVH - Friday, 14 October 2011, 03:08AM

20% des données sont récupérées.

Chaque client concerné a été/sera appelé par notre équipe afin d'avoir un retour plus précis sur l'avancement.


Comment by OVH - Wednesday, 19 October 2011, 13:49PM

L'ensemble des comptes ont été recouvrés dimanche 16 octobre.