Contexte / besoin
La plateforme héberge des données qui ne m’appartiennent pas : sites clients en production, documents d’un cabinet client, données applicatives. Un disque qui meurt, une mise à jour qui tourne mal, une erreur humaine : la question est de savoir quand ça arrivera. Et ce jour-là, avoir des sauvegardes ne suffit pas. Il faut pouvoir restaurer.
Contraintes
- Données de tiers. La perte n’est pas négociable, et la copie hors-site doit être chiffrée puisqu’elle quitte l’infrastructure.
- Le jour où on restaure est un mauvais jour : la procédure doit déjà être écrite, et un humain fatigué doit pouvoir la suivre.
- Automatique. Une sauvegarde manuelle est une sauvegarde qui finira par ne pas être faite.
Options envisagées
- Snapshots ou images disque uniquement : simples, mais opaques. Restaurer un service précis ou une base précise devient une opération lourde, et la cohérence applicative n’est pas garantie.
- Sauvegardes applicatives par service : des dumps propres (bases, données, configurations), granulaires, testables, lisibles.
- Le choix : l’applicatif d’abord, le niveau disque en complément.
Décision & pourquoi
Stratégie 3-2-1 : plusieurs copies, sur des supports distincts, dont une hors-site chiffrée. Chaque service reçoit sa sauvegarde applicative (dump de base, données, configuration) avec une rotation automatique : l’espace reste borné et les points de restauration s’étagent dans le temps.
Et surtout, un runbook de restauration : pour chaque type de donnée, la procédure exacte, dans l’ordre, avec les pièges connus. Écrit à froid, pour être déroulé à chaud.
Où en est le déploiement. La stratégie tourne aujourd’hui sur la plateforme du cas client : versions locales et copie hors-site chiffrée. Côté serveur, la généralisation est en cours ; avec les tests de restauration chronométrés, elle constitue le chantier Sauvegardes éprouvées de la roadmap.
Tradeoff assumé
Les restaurations complètes ne sont pas encore testées de façon régulière et outillée : tant que ce n’est pas fait, le temps de reprise reste une estimation (chantier roadmap). La granularité applicative demande aussi un peu de maintenance par service, le prix de la lisibilité.
Résultat
- Fiable : sur le périmètre déployé, la perte d’un fichier, d’un dossier ou du matériel a un chemin de sortie documenté, avec des points de restauration étagés ; le serveur rejoint le même contrat au fil du chantier.
- Sécurisé : la copie qui quitte l’infrastructure est chiffrée, et les sauvegardes suivent la même hygiène d’accès que le reste (secrets).
Ce que contient le runbook de restore
Sans recopier le document, qui reste interne, sa structure :
- Par scénario. Perte d’un service, corruption d’une base, perte du serveur complet : chaque scénario a sa procédure propre.
- Prérequis explicites : où sont les copies, comment déchiffrer la copie hors-site, quels secrets sont nécessaires et où ils vivent.
- Ordre de remontée : quoi restaurer d’abord (les données, puis les services, puis l’edge) et comment vérifier chaque étape avant de passer à la suivante.
- Les pièges connus, notés au fil des restaurations réelles et des essais.