Tester la restauration d'une sauvegarde client : procédure agence

Le guide sur la stratégie 3-2-1 avec Restic et S3 décrit un contrôle automatique : un fichier sentinelle restauré chaque semaine, qui alerte quand la chaîne de sauvegarde casse. C'est utile et il faut le garder. Mais il répond à la question « le dépôt se lit-il ? », pas à « le site du client repart-il, et en combien de temps ? ». Restaurer un fichier de quelques octets ne dit rien d'une base de données, des fichiers téléversés, de la version de PHP attendue ou des secrets absents.

L'exercice de ce guide restaure un site entier, à la main, sur une machine neuve, et en tire trois mesures : une durée, un âge des données et une liste d'anomalies. Les deux dispositifs ne se concurrencent pas. Le contrôle automatique détecte la panne chaque semaine ; l'exercice trimestriel prouve la reprise, avec une signature et une date. C'est cette preuve qu'un client, un appel d'offres ou un audit finit par demander.

À ne pas confondre non plus avec le contrôle de restauration de la checklist d'audit mensuel d'un VPS client : celui-là vérifie chaque mois qu'un fichier ou une base se restaure ; l'exercice trimestriel de ce guide remet en route un site entier, chronomètre en main.

Choisissez un site par client et par trimestre, en alternant les profils : un site adossé à une base de données, un autre aux fichiers téléversés volumineux, un troisième avec des tâches planifiées. Avant de commencer, rassemblez trois éléments hors du serveur du site : l'accès au dépôt, le mot de passe ou la clé qui l'ouvre, et la liste des secrets de l'application.

Louez ensuite un VPS de test jetable, avec le même système que la production, et prévoyez de le détruire en fin de séance. Pour l'effort, comptez à titre d'ordre de grandeur éditorial une demi-journée par trimestre pour un site type, davantage pour un dépôt volumineux, moins quand la procédure est rodée. Notez l'heure de début avant la première commande, jamais après.

Le RTO constaté est l'heure de fin de restauration vérifiée moins l'heure de début du test. Le RPO constaté est l'écart entre l'heure de l'incident simulé et l'horodatage du snapshot restauré. Prenons un exemple fictif : incident simulé à 14 h 00, dernier snapshot pris à 03 h 00 le même jour, soit 11 heures de données perdues. Si le contrat promet 24 heures, c'est conforme ; s'il en promet 4, c'est non conforme, et le journal doit l'écrire tel quel.

Un RTO mesuré en test reste un plancher optimiste : machine neuve, personne n'attend, aucune pression. Il vaut pourtant mieux qu'un calcul de coin de table, surtout quand le dépôt est volumineux : sur un débit modeste, le temps de téléchargement suffit à rendre un RTO théorique irréaliste. Mesurez le débit réel au moment de la restauration et notez-le dans le journal.

Fatal: wrong password or no key found — Restic ne trouve aucune clé qui s'ouvre avec le mot de passe fourni. Causes fréquentes à écarter une à une : mot de passe saisi avec des caractères spéciaux altérés par le shell, mot de passe lu sur l'entrée standard, URL de dépôt S3 au mauvais style, fichier de clé abîmé. Essayez --password-file ou la variable RESTIC_PASSWORD, vérifiez l'URL du dépôt puis restic key list. Si le mot de passe est réellement perdu, les données du dépôt sont perdues avec lui : inscrivez-le en anomalie critique.

Aucun point de restauration récent — restic snapshots ne liste rien de la semaine : le job de sauvegarde s'arrête en silence. Corrigez le timer et ajoutez une alerte.

pg_restore se termine avec des erreurs ignorées — par défaut, il continue et affiche un décompte à la fin. Rejouez avec --exit-on-error pour vous arrêter à la première erreur, et lisez-la avant de déclarer le test réussi.

Les fichiers sont là mais le site répond 403 — la restauration en root a laissé les fichiers au mauvais propriétaire. Rendez-les à l'utilisateur du serveur web.

Le journal tient sur une page : en-tête avec client, site et date ; tableau des huit champs ; conclusion d'une phrase, conforme ou non aux cibles de RPO et de RTO ; plan correctif daté ; signature. Réservez un encart final « Non testé dans cet exercice » : boîtes e-mail et délivrabilité, DNS et délégation, certificats TLS, services tiers comme le paiement ou un CRM, et tout autre site du compte.

Un journal qui n'écrit pas ses limites se lit comme « tout est sauvegardé », et c'est la promesse qu'on ne peut pas tenir. Conservez les journaux de chaque trimestre : un seul test prouve un jour, une série prouve une pratique. Relevez aussi les versions de PHP de chaque site, comme dans le guide sur l'inventaire des versions d'un parc de clients : c'est le piège le plus fréquent au moment de rejouer.

Une clause utile nomme sept points : le périmètre (fichiers, bases, configuration), la fréquence, la rétention, les cibles de RPO et de RTO, la fréquence et la preuve des tests, la responsabilité si la restauration échoue, et la personne qui détient les accès au dépôt. Ce n'est pas un avis juridique : faites relire le texte par un juriste. Et ne promettez jamais ce que l'infrastructure sous-jacente ne garantit pas.

Sur ce point, les sauvegardes ServOrbit.com sont hebdomadaires en entrée de gamme, quotidiennes sur Pro et sur toutes les offres d'hébergement revendeur. Le RPO plancher se déduit de cette fréquence : jusqu'à sept jours avec une sauvegarde hebdomadaire, jusqu'à un jour avec une quotidienne. Un RPO de moins d'un jour exige donc une sauvegarde applicative propre à l'agence, en plus. Quant à la durée de restauration, aucun engagement ne se déduit d'une fréquence : elle se mesure, avec l'exercice ci-dessus.

L'objection est connue : le client ne le demande pas, et le temps n'est pas facturé. Deux réponses. Intégrez au forfait de maintenance une ligne « test de restauration trimestriel, journal remis », ou facturez la demi-journée à part. Et considérez le journal comme un livrable : en cas d'incident, il montre ce qui avait été testé et corrigé ; en phase de vente, il répond à « prouvez-le » avant que la question soit posée.

Pour tenir le rythme sur un portefeuille, prévoyez une rotation : un site par client et par trimestre, calendrier fixé en début d'année. Le VPS de test se loue et se détruit à la demande ; les conditions figurent sur la page de l'offre.