Le Feu à Strasbourg !
Dans la nuit du 10 au 11 mars 2021, OVH a connu un incident majeur avec la perte d'une grande partie de son datacentre de Strasbourg. J'ai lu que de nombreux clients avaient "tout perdu". Certains fustigent leur hébergeur. Un tel incident peut pourtant toujours arriver. Si vous avez vos données à un seul endroit, sans sauvegarde distante avec test de restauration, sans plan de reprise d'activité régulièrement validé, alors tôt ou tard elles seront perdues.
Journalisation en continu, sauvegarde
Restauration et relance du service
Conclusion
La machine virtuelle de pgphil.ovh, un VPS "starter" que je loue 3 euros par mois, était stockée dans le datacentre parti en fumée. J'héberge deux petits forums en plus du site, celui consacré à PostgreSQL et un autre, beaucoup plus actif, de jeu de rôle. Anxiété chez les joueurs, ont-ils perdu les milliers de messages postés pendant les nombreux mois de leur "campagne" ?
Ces forums s'appuient évidemment sur un cluster PostgreSQL, sauvegardé via pgBackRest avec archive_timeout à 10 minutes. Je ramène par ailleurs la stanza (le repository de sauvegarde) ainsi que le dossier applicatif html via rsync, sur un serveur local, une station de travail Linux allumée en permanence. La tâche est planifiée via cron toutes les heures. Un test automatique de restauration pgBackRest est par ailleurs planifié tous les mois sur la station de travail et elle fait l'objet d'une sauvegarde complémentaire. Le RPO (recovery point objective) n'est pas de 0 mais j'ai jugé suffisant ce mécanisme au vu de la nature des données que je dois protéger.
Alors qu'OVH analysait l'incident, j'ai loué un nouveau serveur à Gravelines pour 3 euros. OVH l'a mis à disposition en quelques minutes malgré le désastre en cours sur un autre de leurs datacentres. J'ai réinstallé les binaires, restauré le cluster PostgreSQL depuis pgBackRest et remis en place le site web via rsync.
Après une vérification applicative, j'ai associé l'IP du nouveau serveur au nom de domaine pgphil.ovh. Le 13 mars, OVH m'envoie un mail pour me prévenir que le serveur de Strasbourg, ainsi que le stockage associé, sont définitivement perdus. Mais cela fait belle lurette que pgphil.ovh est à nouveau en ligne. Je dors la nuit, je travaille la journée et ce site personnel ne fait évidemment pas l'objet d'une astreinte. Mais il m'a fallu moins d'une heure, le 11 mars, pour rendre le service lorsque j'ai pu commencer à travailler sur le sujet. C'est en fait la propagation DNS qui a pris le plus de temps dans le processus, j'ai fourni l'adresse IP aux joueurs les plus pressés de reprendre.
La sauvegarde, ce n'est pas optionnel. La solution que j'avais mise en place, similaire pour la partie locale à celle que je déploie dans les hôpitaux, peut sembler très basique. Mais elle s'est révélée précieuse. De nombreux clients dont les données sont autrement plus critiques n'avaient apparemment pas pensé à sauvegarder leurs données, à tester leur processus de restauration et leur PRA/PRI (plan de reprise d'activité/plan de reprise sur incident).
D'aprés le monitoring du serveur, j'ai perdu une demi-heure de transactions validées, entre 1h23 et l'incident. J'aurais donc pu perdre quelques messages car certains joueurs postent la nuit. Pour m'amuser plutôt que par nécessité, afin d'atteindre un RPO proche de 0, je compte mettre en place une solution que je propose en option aux hôpitaux, une hot standby. C'est une puissante solution PostgreSQL native sur laquelle appuyer un plan de reprise sur incident. Oracle propose un mécanisme similaire en option de son Enterprise Edition sous le nom commercial "Active Dataguard". Avec PostgreSQL, c'est gratuit et inclus. Je vais donc garder les deux petits serveurs afin de créer un flux de journalisation entre eux. Les sauvegardes pgBackRest s'intègrent dans ce cas au mécanisme global de protection. Les informations de journalisation sont en effet transférées par streaming WAL ou par archive-get depuis la stanza lorsque c'est nécessaire, de manière transparente.
J'interviens dans un secteur spécifique mais je ne peux que vous encourager, si ce n'est déjà fait, à vous appuyer sur les conseils d'une entreprise disposant d'une expertise PostgreSQL pour mettre en place, ou valider, vos procédures de protection des données. L'assurance ne parait chère qu'avant l'accident. Voici une liste non exhaustive d'entreprises sérieuses que vous pouvez contacter :
Mise à jour : 13/03/2021