Incident du 12 janvier 2016¶

Résumé d'incident¶

Comme vous avez pu le constater, une panne est venue troubler le fonctionnement normal de notre infrastructure le 12 janvier dernier.

Vers 19h40, nous avons constaté qu’un de nos principaux serveurs ne répondait plus. Devant l'impossibilité de prendre la main dessus nous l’avons redémarré.
Là, nous avons découvert que le système de fichier était endommagé.

Après une nuit et une matinée complètes à le remettre en état, nous dressons le bilan suivant:

• plusieurs bases de données ont été endommagées (notamment notre gestionnaire de liste de diffusion et ses archives) ;
• le service d’email a été sévèrement endommagé, avec des courriels potentiellement perdus ;
• de nombreux autres problèmes plus ou moins mineurs sont présents.

Cette panne est intervenue à une période critique sur une machine dont les sauvegardes ne s’effectuaient plus. Il n’était donc pas possible de réinstancier une sauvegarde récente sur la machine.

Les services ont commencé à refonctionner au compte goutte à partir du 13 janvier, dans l’après-midi. Le mail n’est revenu que le 14 dans la journée.

Conséquences¶

La conséquence principale a été la corruption du systeme de fichiers. La remise en service a occasionné une interruption de services de deux jours.
En outre, nous n'avons pas pu récupérer tous les fichiers de notre serveur. Ainsi, certains courriels adressés a nos permanents et adhérents ont pu etre perdus.
De même, il est possible que de légers dysfontionnements puissent apparaitre dans les jours ou semaines à venir, le temps de stabiliser la machine et de restaurer les derniers services.

Mesures prises ou à prendre¶

[-] remise en route des backups de pavot
[X] vérification des dumps des DB de pavots
[ ] remise en route des backups de ns1
[ ] vérification des dumps des DB de ns1
[ ] sauvegarde des sélections de paquets debian
[ ] sauvegarde stabilisée du svn
[ ] monitoring plus fin des erreurs de backup
[X] remise au vert du monitoring (52 services HS jeadi midi)
[ ] mise en place d'un nouveau lieu de backup

La raison première est complètement inconnue.

Une hypothèse que j'ai est que pour une raison inconnue, le journal de la partition a été corrompu et le fsck au redémarage nous a déchiqueté de gros morceaux de FS. Il n'y a rien de signifiant dans les logs de pavot. Les logs de storm, les données smart et les logs des vserveurs restent à examiner.

[X] voire avec les outil debian si on peut lister les fichiers qui devraient théoriquement se trouver sur le FS car installés par dpkg mais qu'on a perdu dans la bataille.

[-] remise en route des backups de pavot
=> projet échoué avec bpc. 0n travail sur un nouveau déploiement. En attendant le serveur est rsync par fred/benj sur une machine perso.
[X] vérification des dumps des DB de pavots
[X] remise en route des backups de ns1
[X] vérification des dumps des DB de ns1
[X] sauvegarde des sélections de paquets debian
=> Pavot, ns1 et tous leurs guests dumpent leur db dpkg dans /srv/backup/dpkg.bz2
[ ] sauvegarde stabilisée du svn
=> à voire sur la future infra
[ ] monitoring plus fin des erreurs de backup
=> à voire sur la future infra
[X] remise au vert du monitoring (52 services HS jeadi midi)
[ ] mise en place d'un nouveau lieu de backup
=> en cours