Pages : 1
Bonjour,
Un serveur du node "india" a rencontré un incident impactant la partie MySQL.
Début d'incident : 13:25
Fin d'incident : ~16:30
Nombre de sites web impactés : ~70 à 80
Le serveur MySQL concerné a rencontré une corruption de son système de fichiers dédié et spécifique.
La corruption aurait pour conséquence un disque HS, puis une erreur de re-sync RAID (probablement du controlleur). Ce type de situation étant relativement rare. Naturellement, la situation n'était malheureusement pas prévisible nous n'avons pas eu de remonté SMART/erreur en logs SQL au préalable.
Nous avons donc, afin de rétablir les services, été sous la contrainte de restaurer des sauvegardes du dit serveur MySQL sur à la fois des disques neufs, et un serveur MySQL à neuf matériellement et logiciellement.
Typiquement MySQL dispose de 4 protections :
- Les volumes du dit serveur étaient en RAID.
- Trois sauvegardes / jour sont opérées sur des temps différents, en fonction des tailles de bases, utilisateurs du serveur, etc. Par un script interne + par JetBackup.
Nous avons alors restauré la sauvegarde globale, qui était la plus pertinente au collectif, dont la date s'étale entre ~minuit et 3h du matin.
Le différentiel du matin est alors, forcement, et malheureusement perdu.
Il est possible que des dumps plus récents de quelques minutes/heures existent, en fonction des comptes, depuis l'outil JetBackup du cPanel.
Dès lors, si cela s'avère nécessaire vous pouvez réaliser en toute autonomie une restauration depuis l'outil mis à disposition.
Si vous avez de votre côté eu des exigences plus fortes et vos propres systèmes de backups à des intervalles plus adaptées à votre situation, vous pouvez demander à notre équipe de réaliser pour vous une restauration à partir d'un de vos propres fichiers. Fichier à fournir au format .sql non compressé.
Cordialement
Service Technique
Hors ligne
Pages : 1