Backup et PRA : REX suite à la destruction du datacenter OVH à Strasbourg

Comme je l’écrivais en 2018 dans mon article « Comment gérer le PRA de ses données personnelles« , il est primordial de faire des sauvegardes de ses serveurs sur un autre site. La perte des datacenters OVH SBG2 et SBG1 prouve bien tout son intérêt. Retour sur un mercredi noir.

Etat de mon infrastructure

Chez OVH, je disposais de plusieurs VPS qui étaient majoritairement sur Strasbourg. Voici le détail :

• serveur de mail : SBG2
• serveur site meteo-four38.fr : SBG1
• serveur sites cuisine.gougoux.com et sla99.fr : SBG1
• serveur domotique : GRA2
• serveur Bitwarden : GRA2

Le plus critique à remonter pour moi était le serveur de mail, les sites web sont plus annexes mais il est important de retrouver ses mails au plus vite.

Des backups de tous ces serveurs étaient faits chaque nuit sur mon synology chez moi via les mécanismes Plesk. Et je les vérifie presque tous les jours ! Ca m’a sauvé.

Le film du 10 mars 2021

• 06h15 : je me lève comme tous les matins, et je commence par lire mes mails. Je ne percute pas encore que le serveur est KO car j’ai des mails de 2h du matin (mon monitoring externe indique que serveur n’a plus été dispo à 3h32)

• 6h17 : j’allume l’écran de ma console domotique dans ma cuisine pour voir combien il fait dehors : problème, la page est KO
• 6h20 : j’allume l’ordi et essaie de lancer une connexion SSH sur le serveur : tout est KO
• 6h24 : je vais sur le site travaux OVH et là c’est la stupeur

• 6h30 : je fais un tour de tous mes serveurs et je commence à mesurer l’ampleur des dégâts : plus de mail et plus de site web … ca va être long
• 6h35 : je check les sauvegardes sur le synology. Comme je fais des backups autour de 4h du matin, je comprends que mes dernières sauvegardes viables datent du 9 mars 2021 à 4h du matin : un moindre mal !
• 6h40 : je commence à éplucher le net pour avoir des infos et voir ce qui se passe. Je comprends réellement à ce moment là l’ampleur des dégâts. Ce n’est pas un simple incendie dans un coin, c’est une destruction totale du datacenter.

• 7h30 : il faut se décider quoi faire. Pour gérer l’urgence, et ne pas me retrouver empêtrer chez OVH, j’ouvre un compte chez IONOS (avec mon mail Gmail) et commande un VPS M dans la foulée. Ce que je ne sais pas encore, c’est que ca peut prendre jusqu’à 48h pour l’avoir …
• 8h56 : j’appelle le support IONOS qui me dit que ca peut en effet prendre 48h, mais que en moyenne c’est plutôt 1/2 journée … ca tombe mal et je vais devoir changer mon fusil d’épaule
• 9h : je décide de commander un nouveau VPS chez OVH (je suis en prélèvement automatique) mais problème pour valider : ca m’envoie un mail sur mon adresse qui est sur mon serveur qui est KO ! et pour changer l’adresse mail, il faut avoir accès à son mail d’origine. Pas de nouveau VPS possible chez OVH donc …
• 9h10 : il me reste 2 serveurs viables : mon serveur domotique jeedom et mon serveur de password bitwarden : c’est ce dernier que je vais « sacrifier » pour réinstaller Plesk. Mais problème : il n’a que 40Go d’espace disque là où il en faut le double (20Go de mail à restaurer il faut donc 40Go le temps de copier les archives et les dézipper). C’est là que commence ma galère : pour upgrader mon VPS, il faut accéder à la console OVH qui est en vrac car tout le monde cherche à avoir des infos sur son infra.
• 9h30 : je réussi à lancer un upgrade vers un VPS Essential (2 vcpus 2 Go de ram 80 Go de SSD) (je suis dans un mode « quoi qu’il en coute » pourvu que je relance le service).

• 9h45 : le VPS est upgradé, je me lance dans une install Plesk. Je n’ai pas de licence dispo, je vais donc sur le site Plesk et prend un trial 15j le temps de. De toutes façons, je basculerais chez IONOS dès que le VPS sera dispo.
• 10h : Plesk est installé, je repointe sur le FTP de mon synology pour remonter les backups. Je ne fais pas attention à ce moment là mais Plesk me montre le backup full du samedi soir et les incrémentales jusqu’au mardi. Comme au boulot, je me dis que je vais restaurer la full plus l’incrémentale. En fait, si on choisit dans Plesk la dernière incrémentale il restaure tout tout seul … mais je ne le sais pas encore !
• 10h05 : le backup se restaure …
• 12h45 : le backup est restauré, je vais pour lancer la restauration de l’incrémentale et m’aperçoit que ca restaure tout. Je viens de perdre 2h30 …

• 12h55 : je commande un 2ème VPS chez IONOS pour héberger tous mes sites web, vu le temps que ça prend, je remonterais ça le soir même.
• 13h00 : je relance le backup incrémental du 9 mars
• 14h30 : le backup est restauré, je fais un check du serveur mail et tout semble OK. Reste à modifier le MX sur le site d’OVH … et là même combat que le matin : l’interface est très très lente, bugge et ne me permet d’accéder à la gestion des noms de domaine.
• 15h05 : le MX est enfin changé à coups de F5 sur la page. Je fais tous les tests croisés et ca fonctionne bien. J’informe ma communauté que les mails sont repartis.

• 15h16 : IONOS m’informe que le VPS est prêt …

• 15h30 : je reparamètre les backups sur le nouveau serveur de mail.

A ce moment là, je souffle un peu. Les mails sont répartis moins de 12h après plantage, avec une sauvegarde J-1. Je crois qu’on peut difficilement faire plus efficace.

Pour les sites web, mon VPS a été livré vers 17h, j’ai donc remonté les sauvegardes petit à petit. Le plus important pour moi était le serveur météo, qui est remonté vers 18h.

Puis le soir, j’ai remonté ce site sla99 et le blog de cuisine.

A 22h, l’ensemble de mes services étaient remontés, le serveur de mail en temporaire et les sites web de manière définitive.

Le jour d’après

Le jeudi soir 11 mars, j’ai remigré mon serveur de mail chez IONOS grâce au Plesk Migrator. Ca permet de migrer les données d’un Plesk à un autre de manière automatique. En 1h, c’était migré !

J’ai aussi commandé un 3ème VPS pour remonter ma solution bitwarden. Ce serveur aura vocation à héberger une copie de mes sauvegardes en plus du synology.

J’ai donc revu et augmenté ma politique de backup depuis cet incident. Non seulement les backups viennent toujours sur mon synology, mais je les réplique désormais sur Onedrive (avec mon offre Office365 family 1 To 6 comptes) et sur le VPS de backup. Ca fait 3 copies physiques de la sauvegarde, ca devrait permettre d’assurer les arrières.

Conclusion

Si l’épisode reste inédit (un datacenter qui brule ce n’est pas tous les jours), il reste donc primordial de faire ses sauvegardes et de maitriser son infrastructure. Savoir comment c’est monté, savoir remonter rapidement le serveur, vérifier ses backups régulièrement, monitorer son infra, … sont autant de précautions à prendre qu’elles permettent de repartir au plus vite.

Sans attendre de savoir si les VPS vont revenir, j’ai donc décidé de restaurer le service ailleurs. Il est impensable pour moi d’attendre 2 à 3 semaines pour voir si mes données sont potentiellement accessibles. Les backups sont faits pour ça, la décision a été rapide à prendre …

Fan d’OVH depuis 2004, je dois dire que je suis assez déçu malgré la gestion de crise faite par Octave Klaba. Je ne pense pas remettre les VPS là bas et je conserverais que la gestion des noms de domaine. Ca pose beaucoup de questions sur la sécurité des datacenters, la technique de sprinklage et comment l’incendie a pu tout bruler et n’est pas resté cantonné à une seule salle.