Lorsqu'un incident majeur par ransomware touche une quarantaine de serveurs représentant l'ensemble d'un datacenter, la continuité opérationnelle dépend directement de l'état réel des sauvegardes et de la capacité à restaurer le socle de données. En tant que Database Engineer et responsable des sauvegardes, voici mon retour d'expérience sur la restauration des bases de données critiques en 48 heures sur quatre moteurs de bases de données : SQL Server, PostgreSQL, MySQL et Oracle.
1. Contexte de l'incident et répartition des rôles
L'incident a touché une quarantaine de serveurs, soit l'ensemble du datacenter. Dès le premier jour, les rôles ont été clairement répartis pour organiser la réponse : une équipe s'est occupée du confinement de l'incident, tandis que l'équipe infrastructure provisionnait en parallèle de nouveaux serveurs et machines virtuelles avec leur système d'exploitation.
Pendant un incident majeur, la clarté des rôles est essentielle : l'infrastructure provisionne les environnements sains pendant que le responsable des bases prépare la restauration des données.
2. Restauration des bases de données à partir des sauvegardes
Une fois les nouvelles machines virtuelles et serveurs provisionnés et mis à disposition par l'équipe infrastructure, mon intervention en tant que Database Engineer et responsable des sauvegardes s'est concentrée sur la restauration des bases de données à partir des sauvegardes saines disponibles sur les moteurs de production : SQL Server, PostgreSQL, MySQL et Oracle.
L'objectif était de restaurer méthodiquement les bases critiques sur ces nouveaux serveurs sans compromettre l'intégrité des données.
3. Résultats obtenus en 48 heures
Grâce à la disponibilité des sauvegardes et au provisionnement rapide des environnements d'accueil, les bases critiques ont été restaurées : 99,9 % des données du segment base de données ont été récupérées dans les 48 heures suivant l'incident.
4. Leçons apprises et retours d'expérience
Cette intervention a conduit à des évolutions concrètes dans la stratégie de résilience :
- Sauvegarder les données ne suffit pas si l'on ne peut pas recréer rapidement le serveur qui les reçoit : d'où la mise en place de sauvegardes au niveau machine virtuelle pour les serveurs qui hébergent les moteurs de bases de données (SQL Server, PostgreSQL, MySQL et Oracle).
- Mise à jour de la politique de sauvegarde : révision des processus pour raccourcir les temps de reprise des systèmes financiers.
- Une sauvegarde non testée n'est pas une sauvegarde : seules des restaurations régulières prouvent la capacité réelle de reprise opérationnelle.
- Isolement des sauvegardes : les cibles de sauvegarde doivent être strictement cloisonnées pour prévenir tout accès non autorisé ou compromission.
- Documentation des procédures : disposer de procédures de restauration claires, tenues à jour et accessibles hors de l'infrastructure principale.
