Construire la reprise avant d’en avoir besoin

Le problème

L’infrastructure disposait de sauvegardes. Elle ne disposait ni d’une procédure de restauration écrite, ni de la preuve qu’une restauration fonctionnait, ni d’une estimation du temps nécessaire pour remettre un service en état.

Les charges applicatives sur Kubernetes n’étaient, elles, pas sauvegardées du tout — un point que le passage d’Azure Web Apps à AKS avait rendu critique sans que le dispositif suive.

La solution

Sauvegarde des clusters AKS mise en place avec Velero, couvrant les ressources Kubernetes et les volumes persistants.

Plan de reprise d’activité conçu et documenté : scénarios de bascule, ordre de reprise des services, procédure opératoire lisible par quelqu’un qui n’a pas construit le système.

Restaurations testées, pas seulement planifiées. C’est la partie que la plupart des dispositifs omettent, et celle qui fait la différence le jour où l’on en a besoin.

Les résultats

• Sauvegarde et restauration des clusters opérationnelles
• Plan de reprise documenté et exploitable par un tiers
• Scénarios de bascule éprouvés par des tests réels

Ce que j’en retiens

Un dispositif de reprise ne vaut que par sa dernière restauration réussie. Un rapport de sauvegarde au vert ne prouve rien : il prouve qu’un fichier a été écrit, pas qu’un service peut redémarrer.