# Restaurer une sauvegarde WordPress en conditions réelles : notre exercice

> Beaucoup d'agences sauvegardent sans jamais tester la restauration. Voici comment nous avons organisé cet exercice périodique, et ce qu'il a révélé sur nos procédures.

- Auteur : Clément Hadrot
- Publié le : 2021-08-26
- Mis à jour le : 2021-08-26
- Catégorie : Hébergement & serveurs
- URL : https://wpmoderne.dev.wordpress-developpement.fr/hebergement/restaurer-sauvegarde-wordpress-conditions-reelles/

## L’essentiel

- Une sauvegarde jamais restaurée reste une hypothèse, pas une certitude
- L'exercice a révélé des scripts obsolètes que personne n'utilisait plus
- Chronométrer la restauration change la conversation avec le client

La phrase qui a déclenché cet exercice venait d'un collègue, lors d'une réunion d'équipe anodine : « On sauvegarde tout, tous les jours, mais est-ce que quelqu'un ici a déjà réellement restauré un de ces fichiers, en dehors d'un vrai incident ? » Le silence qui a suivi valait toutes les réponses. Nous avions des sauvegardes automatisées, vérifiées par leur seule existence sur le disque, jamais par leur capacité réelle à reconstruire un site fonctionnel.

Cet article documente cet exercice, mené sur un échantillon de sites représentatifs de notre parc, sans prétendre couvrir le choix de l'outil de sauvegarde lui-même : nos outils (export WP-CLI et snapshots serveur) restaient inchangés, seule leur capacité de restauration réelle était mise à l'épreuve.

## Préparer l'exercice sans prévenir personne à l'avance

La première règle que nous nous sommes fixée : la personne qui exécute la restauration ne doit pas être celle qui a configuré la sauvegarde initiale. Ce choix, volontairement inconfortable, visait à tester non seulement la sauvegarde elle-même mais aussi la documentation qui l'accompagne : si seule une personne sait comment restaurer, l'agence dépend d'une seule tête, un risque en soi.

1. Choisir un site représentatif, ni le plus simple ni le plus complexe de notre parc.
2. Provisionner un serveur de test totalement vierge, sans aucune configuration héritée du site d'origine.
3. Donner uniquement la documentation existante à la personne chargée de la restauration, sans intervention orale des autres membres de l'équipe.
4. Chronométrer chaque étape, du début du provisionnement jusqu'au moment où le site est jugé fonctionnel.

## Ce que le premier exercice a révélé

> L'essentiel à retenir : Une sauvegarde jamais restaurée reste une hypothèse, pas une certitude ; L'exercice a révélé des scripts obsolètes que personne n'utilisait plus ; Chronométrer la restauration change la conversation avec le client

Le résultat a été instructif, et pas dans le sens que nous espérions. Le site que nous pensions pouvoir restaurer en une vingtaine de minutes en a pris près de trois heures. Les causes de ce retard n'avaient rien d'exotique, ce qui les rendait d'autant plus gênantes :

- Le script de restauration documenté référençait une version de PHP qui n'était plus celle utilisée en production depuis la dernière montée de version, provoquant une incompatibilité immédiate au premier lancement.
- Une extension tierce, nécessaire au fonctionnement correct du site, n'était mentionnée nulle part dans la documentation, alors qu'elle avait été installée manuellement plusieurs mois auparavant par un collègue depuis parti.
- Le fichier `wp-config.php` restauré contenait encore les identifiants de connexion à la base de production, qu'il a fallu réajuster manuellement pour pointer vers la base restaurée sur le nouveau serveur, une étape qui n'était pas explicitée dans la procédure existante.

Aucun de ces trois points n'aurait été détecté par une simple vérification que le fichier de sauvegarde existait bien et n'était pas corrompu. Seule la restauration réelle, exécutée par quelqu'un qui n'avait pas toute l'information en tête, a permis de les faire remonter.

## Ce que nous avons corrigé après coup

À la suite de ce premier exercice, plusieurs actions concrètes ont été mises en place, toutes vérifiables lors de l'exercice suivant :

1. La documentation de restauration de chaque site mentionne désormais explicitement la version de PHP en production et les extensions installées manuellement en dehors du dépôt de code versionné.
2. Un script de restauration générique, testé et versionné, remplace les scripts ad hoc créés à la volée site par site, avec des variables clairement identifiées à adapter (nom de base, identifiants, domaine).
3. L'exercice de restauration complet est désormais planifié tous les trimestres, sur un échantillon tournant de sites du parc, avec chronométrage systématique consigné dans un tableau de suivi.

## Ce que cet exercice change dans la relation client

Au-delà du bénéfice technique, cet exercice a changé la façon dont nous présentons nos garanties de sauvegarde aux clients. Annoncer un délai de restauration théorique sans jamais l'avoir mesuré en conditions réelles revient à promettre un chiffre inventé. Après plusieurs exercices consolidés, nous sommes désormais en mesure d'annoncer un délai réaliste, mesuré, pour chaque catégorie de site de notre parc, ce qui renforce sensiblement la crédibilité de nos engagements contractuels.

> Une sauvegarde qui n'a jamais été restaurée en conditions réelles n'est pas une sauvegarde fiable : c'est une hypothèse de fiabilité, qui ne demande qu'à être démentie le jour où elle compte vraiment.

## En résumé

L'exercice périodique de restauration ne remplace aucun des outils de sauvegarde déjà en place : il vérifie simplement, en conditions proches du réel, que ces outils produisent quelque chose d'effectivement restaurable, par quelqu'un d'autre que celui qui a tout configuré. Le premier exercice révèle presque toujours des angles morts que personne n'avait anticipés ; les suivants servent surtout à confirmer que ces angles morts ont bien été corrigés.