Une sauvegarde qui se termine au vert est une affirmation. L’affirmation, c’est qu’un matin futur, ces fichiers deviendront un site qui fonctionne. Je ne crois pas l’affirmation tant que je n’ai pas fait ce matin exprès, sur une machine de rechange, pendant que personne n’attend. Une sauvegarde non testée est une histoire que vous vous racontez. Une restauration que vous avez lancée est une sauvegarde.
Restaurer sur rien, selon un calendrier
L’environnement d’essai n’est ni la production ni le staging que les rédacteurs utilisent. Il commence vide. La sauvegarde est la seule porte d’entrée. Je le mets en route, je me connecte, et je parcours un chemin qui compterait pendant un incident : une page de commande, un envoi de formulaire encore dans la base, un fichier média qui doit être dans l’archive et pas seulement sur l’ancien disque. Ensuite je jette la copie d’essai.
Si cela échoue, je préfère l’apprendre un mardi que pendant la panne pour laquelle la sauvegarde existait. Les échecs habituels sont ennuyeux. Le dump de la base est plus récent que les uploads. Une table de l’extension pointe vers un fichier qui a été exclu. L’archive suppose une version de PHP que la machine de rechange n’a pas. Rien de tout cela n’apparaît dans la coche verte de l’extension de sauvegarde.
Les mises à jour ont besoin d’un retour
Prendre une mise à jour est facile. La prendre avec un moyen de revenir en arrière est le service. Un instantané avant, un court test de fumée après, et un retour écrit si le test échoue. Dire que la sauvegarde peut être restaurée n’est pas un retour en arrière tant que la restauration n’a pas une durée que vous avez mesurée. Je veux cette durée de l’essai sur la machine de rechange, pas de la brochure de l’extension.
Ce que j’ouvre vraiment sur la copie à vide
Connectez-vous comme un utilisateur réel, pas comme l’administrateur de l’installation, si la sauvegarde contient des utilisateurs. Ouvrez une commande qui a un statut, un total et au moins une note. Ouvrez une page qui contient une image, et confirmez que l’image est le fichier de l’archive, pas un lien chaud vers la production. N’envoyez rien. Je vérifie que le passé est revenu, je ne crée pas un présent nouveau sur un hôte jetable.
J’écris la durée à côté de la date. « Dernière restauration, 18 minutes, échec sur l’archive uploads, exclusion corrigée, relancée. » Cette note vaut plus qu’un badge de surveillance. Quand on me demande si le plan inclut les sauvegardes, je peux répondre avec une date. Un plan qui ne peut pas répondre avec une date est un cron avec une facture.
Un délai de réponse dans un plan de suivi ne veut rien dire le premier jour si je n’ai encore rien restauré. L’horloge que j’accepte d’écrire commence après la base, l’accès et une restauration qui a réussi. Avant cela, j’apprends encore comment le site est assemblé. Promettre une réponse le jour même dans ce brouillard, c’est ainsi que les plans de suivi deviennent des excuses.
Demandez quand la dernière restauration d’essai a été faite. Le silence avant la réponse est la réponse.
Le suivi n’est pas un onglet ouvert pour de nouvelles fonctions
Un plan qui promet surveillance, mises à jour, restaurations et aussi tout ce que vous imaginerez ensuite est tarifé pour un fantasme, ou il sera renégocié la première fois que le fantasme arrive. De nouvelles pages, une refonte, une migration : cela a son propre périmètre. Le plan que je défendrai est plus étroit. Le site continue de faire ce qu’il fait déjà. La sauvegarde a été prouvée. Une personne répond dans les heures qui ont été écrites. C’est moins excitant qu’une retenue sans bords. C’est aussi un plan que vous pouvez vérifier.
