Contrôler une sauvegarde client, c’est vérifier quatre choses, dans cet ordre : elle a une date récente, sa taille n’est pas nulle ni ridiculement plus petite que la fois d’avant, elle n’est pas uniquement sur le disque du site, et quelqu’un l’a déjà restaurée jusqu’à obtenir une page WordPress identifiable. L’e-mail sauvegarde réussie de l’extension ou de l’hébergeur ne couvre que le premier point, et encore, seulement si vous l’ouvrez.
Lire un jeu de sauvegarde
| Contrôle | Conforme | À traiter tout de suite |
|---|---|---|
| Date | Dans la fréquence promise (la nuit dernière si c’est quotidien) | Fichier plus vieux que la fréquence, ou absent |
| Contenu | Archive des fichiers plus un export de base, ou snapshot qui inclut les deux | Fichiers seuls, ou base seule, si vous avez promis les deux |
| Taille | Du même ordre que la précédente | 0 octet, ou chute brutale sans suppression de médias connue |
| Emplacement | Une copie hors de la machine du site | Un seul dossier backups dans le même compte, même disque |
| Restauration | Déjà faite ce trimestre, avec la date dans le registre | Jamais faite, ou dernière date inconnue |
La taille se compare à la ligne précédente du registre, pas à une intuition. Un site dont on a retiré une galerie peut légitimement baisser. La baisse se note. Une baisse sans explication se traite comme un export de base échoué, fréquent quand le dump s’arrête au milieu sans que l’e-mail le dise clairement.
L’essai de restauration
- Choisissez une sauvegarde datée. Notez son identifiant dans le registre avant de commencer.
- Restaurez-la sur une copie ou une base vide, jamais par-dessus la production. Si l’hébergeur ne permet qu’un remplacement, vous n’êtes pas en train de tester : vous êtes en train de changer le site. Arrêtez et demandez un autre environnement.
- Pointez un fichier hosts ou une URL de copie vers cette restauration. Ouvrez l’accueil et
wp-login.php. - Connectez-vous avec un compte de test, ou vérifiez qu’un contenu publié avant la date de sauvegarde est là. Un accueil sans feuille de style peut vouloir dire que les fichiers n’ont pas suivi la base.
- Notez : date de la sauvegarde, date de l’essai, réussite ou point bloquant, nom de la personne. Effacez la copie si elle ne doit pas rester en ligne. Une copie de restauration laissée en 200 public est un second site, souvent sans mot de passe.
Le pas à pas côté WordPress, extension par extension ou outil d’hébergeur, se complète avec vérifier une sauvegarde WordPress. L’essai lui-même, y compris ce qu’il faut observer après import, est développé dans tester une sauvegarde.
Le registre
Une ligne par site : fréquence promise, emplacement de la copie externe, dernière archive (date et taille), dernier essai de restauration (date et résultat). La ligne se met à jour le jour du contrôle, pas en fin de mois de mémoire. Si vous tenez vingt sites, le registre est le seul endroit où un site sans essai depuis un an se voit. La boîte mail, elle, montre les succès et cache les absences : un site qui ne sauvegarde plus n’envoie plus d’e-mail.
Quand l’essai échoue, le registre ne dit pas à revoir. Il dit le point bloquant : archive illisible, base qui refuse l’import, URL encore en dur vers la production, identifiants inconnus. Le prochain créneau sert à ce point-là, pas à refaire un essai identique en espérant.
Une restauration réelle, le jour d’un incident, utilise une sauvegarde d’avant la casse. Si vous n’avez testé que des archives déjà infectées ou déjà cassées, le test était conforme et inutile. Croisez la date avec le début de l’incident. Les fichiers modifiés juste avant la panne se lisent comme dans fichiers WordPress modifiés sans raison : la sauvegarde d’après cette modification copie parfois le problème.
Le livrable est le registre, avec des essais datés. Une case sauvegardes OK dans un rapport mensuel, sans date d’essai, est une apparence. Le client peut la lire. Elle ne restaurera rien.