La sauvegarde automatique tournait depuis deux ans. Le jour de la panne, personne ne savait restaurer : mauvais snapshot, base corrompue, DNS toujours pointé vers l'ancien serveur. « On avait des backups » — oui. Aucun plan de reprise.
Ce scénario se répète dès qu'une équipe confond copie et continuité. Un PRA (plan de reprise d'activité) répond à des questions précises : combien de temps pouvez-vous rester sans service (RTO), combien de données pouvez-vous perdre (RPO), qui fait quoi, dans quel ordre, et comment informer clients et partenaires. Les sauvegardes proposées par l'hébergeur ne sont qu'une brique — pas le plan. Croisez avec Le mythe des 99,99 % : les crédits SLA ne remplacent jamais une organisation qui sait rebondir.
Définir RTO et RPO métier
Le RTO et le RPO ne se choisissent pas au feeling technique. Ils traduisent une tolérance au risque métier : perte de ventes, impossibilité de facturer, violation contractuelle envers un client B2B. Commencez par une table simple, validée avec le responsable produit ou la direction.
| Site | RPO indicatif | RTO indicatif |
|---|---|---|
| E-commerce | 15 min – 1 h | 1–4 h |
| SaaS B2B | 5–15 min | < 1 h |
| Site corporate | 24 h | 4–24 h |
| Blog | 24 h | 48 h |
Un RPO d'une heure implique une sauvegarde horaire, voire des journaux binaires si la base le permet. Un RTO de quatre heures exige une procédure documentée et une restauration déjà testée — pas une première tentative sous stress un dimanche soir. Si personne n'a chronométré une restauration complète, votre RTO affiché est une hypothèse.
Architecture minimale et rôle de l'hébergeur
La règle 3-2-1 reste la base : trois copies, deux médias, une hors site. Dressez un inventaire complet : code dans Git, base de données, fichiers uploadés, enregistrements DNS, secrets et certificats. Rédigez un runbook numéroté : qui appelle l'hébergeur, qui bascule le DNS, qui valide la base restaurée — voir redirects domaine pour les pièges de bascule.
Préparez un environnement de reprise : VPS froid, image prête, ou second hébergeur documenté. Prévoyez la communication externe via une page statut et des messages incident rédigés à l'avance. L'hébergeur fournit souvent des snapshots ; vous devez exporter la base, chiffrer une copie hors site, tester la restauration et gérer une bascule DNS secondaire si l'enjeu le justifie.
Tester la restauration : la seule preuve qui compte
Une sauvegarde qui n'a jamais été restaurée est une promesse. Chaque trimestre, exécutez un exercice complet : restauration sur staging, vérification des uploads, test de connexion applicative, mesure du temps réel. Notez les écarts entre durée mesurée et RTO annoncé.
Les échecs typiques apparaissent ici : plugin de backup qui exclut le répertoire uploads, snapshot trop ancien, version PHP incompatible sur le serveur de reprise, secrets manquants dans le coffre. Corrigez le processus après chaque exercice — pas seulement la panne imaginaire.
Bascule, DNS et second hébergeur
Pour les sites critiques, un second hébergeur ou une zone de reprise pré-configurée réduit le RTO. La bascule DNS reste le point fragile : TTL élevé, cache résolveur, certificats liés à l'ancien serveur. Documentez la séquence : réduction TTL la veille d'un changement planifié, bascule A/AAAA, vérification HTTPS, retour arrière si échec.
Un standby froid coûte moins qu'un standby chaud, mais allonge le délai de remise en service. Le choix se fait sur le RTO accepté et le budget — pas sur l'ego technique de l'équipe.
Le sommet : la sauvegarde rassure ; seul le restore prouve
Décider et avancer sans angle mort
Commencez par fixer un RTO et un RPO par service critique, validés avec le métier. Automatisez ensuite les sauvegardes hors site et tenez à jour un inventaire des secrets et des dépendances. Planifiez un test de restauration trimestriel et consignez la durée réelle observée. Comparez les hébergeurs qui documentent leurs snapshots et leurs procédures via l'annuaire. Envisagez un second hébergeur ou une zone de reprise si l'enjeu financier ou réputationnel dépasse le coût de la redondance.
Questions fréquentes
Quelle différence entre sauvegarde et plan de reprise ?
La sauvegarde copie des données. Le plan de reprise définit qui restaure quoi, en combien de temps, avec quelle perte acceptable, et comment continuer si l'hébergeur est indisponible. Sans procédure écrite et testée, la copie reste théorique le jour de la crise.
Les backups automatiques de l'hébergeur suffisent-ils ?
Non, pas seuls. Fréquence, rétention et restauration ne sont pas toujours garanties contractuellement. Il faut une copie hors site, un test trimestriel et une procédure documentée — voir CGV hébergement.
Quels RTO/RPO pour un site e-commerce ?
Indicatif : RPO inférieur à une heure pour les commandes, RTO inférieur à quatre heures pour reprendre le commerce — à calibrer sur le chiffre d'affaires perdu par heure. Un blog vitrine tolère souvent vingt-quatre heures ; un panier bloqué en journée coûte bien plus.
Faut-il un second hébergeur ?
Pour les sites critiques, oui : bascule DNS, infrastructure en veille, runbook validé. Le coût se compare au risque. Sur mutualisé, un second hébergeur n'est pas obligatoire si un RTO long reste acceptable — à condition de l'assumer explicitement.
Un backup que vous n'avez jamais restauré est une promesse. Un PRA, c'est la promesse tenue devant un chronomètre.