OVHcloud Web Hosting Status

Current status
Legend
  • Operational
  • Degraded performance
  • Partial Outage
  • Major Outage
  • Under maintenance
xc11.mail.ovh.net
Incident Report for Web Cloud
Resolved
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é

Update(s):

Date: 2011-10-19 11:49:20 UTC
L'ensemble des comptes ont été recouvrés dimanche 16 octobre.



Date: 2011-10-14 01:08:21 UTC
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.

Date: 2011-10-13 12:51:59 UTC
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.

Date: 2011-10-12 10:52:04 UTC
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.


Date: 2011-10-11 22:35:01 UTC
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.



Date: 2011-10-11 14:58:34 UTC
Nous allons ajouter un dossier 'ovh-recover' pour les comptes concernés.
Nous sommes actuellement entrain d'insérer les emails manquants progressivement.

Date: 2011-10-11 09:56:14 UTC
63 domaines (avec ses emails) ont été recuperé
sur 77 domaines que la VM héberge. On regarde
pour la recuperation du reste.

Date: 2011-10-11 08:28:56 UTC
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


Date: 2011-10-11 01:45:17 UTC
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.

Date: 2011-10-10 23:05:21 UTC
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.

Date: 2011-10-10 21:27:09 UTC
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.

Date: 2011-10-10 20:39:36 UTC
La récupération depuis le snapshot de midi n'a pas fonctionné.
Nous sommes en train de reprendre le backup le plus vieux.

Date: 2011-10-10 14:15:09 UTC
Nous récupérons le snapshot de midi. La copie est en cours. Elle est à 60% terminée.
Posted Oct 10, 2011 - 11:14 UTC
This incident affected: Collaborative solutions || Hosted Exchange (Reception).