Une sauvegarde WordPress qui marche vraiment : faites le test de restauration avant la catastrophe

Presque tous les propriétaires de sites WordPress dorment tranquilles parce qu'ils « ont une sauvegarde ». Le problème, c'est que la plupart n'ont jamais ouvert cette archive et n'ont jamais essayé de reconstruire le site à partir d'elle. Or une sauvegarde que vous n'avez jamais restaurée n'est pas un filet de sécurité, c'est une promesse non testée.

Le moment où vous découvrez si votre sauvegarde est réelle est le pire possible : après un piratage, après une mise à jour qui a cassé le site, ou après que l'hébergeur a perdu vos données. C'est là que vous constatez que l'archive était corrompue, que les images manquaient, ou que vous ne sauvegardiez que la moitié de l'essentiel. Cet article vous apprend à vérifier, calmement et à l'avance, que votre sauvegarde fonctionne vraiment.

Ce que contient réellement une sauvegarde complète

Une vraie sauvegarde WordPress comporte trois parties à enregistrer ensemble :

• les fichiers du site : le thème, les extensions et surtout le dossier wp-content avec toutes les images de la médiathèque ;
• la base de données MySQL : elle contient les textes, les pages, les articles, les commentaires et les réglages ;
• les fichiers de configuration (wp-config.php, parfois .htaccess).

Si vous ne sauvegardez que la base de données, à la restauration vous avez le contenu mais pas les images. Si vous ne sauvegardez que les fichiers, vous obtenez un site vide, sans articles. Beaucoup d'extensions gratuites ne sauvegardent qu'une partie par défaut, ou excluent les gros dossiers « pour tenir ». Ouvrez votre archive une fois et regardez à l'intérieur. Si vous ne voyez pas un fichier .sql (ou un dossier de base de données) et un dossier uploads rempli d'images, vous n'avez pas une sauvegarde complète.

La règle 3-2-1 : l'endroit où vous gardez les copies compte

Une sauvegarde gardée sur le même serveur que le site ne vous protège de presque rien. Si l'hébergeur tombe, brûle ou suspend votre compte, le site et sa copie disparaissent en même temps.

La règle simple utilisée par les professionnels est le 3-2-1 :

• 3 copies des données (l'original plus deux sauvegardes) ;
• sur 2 types de stockage différents ;
• avec 1 copie hors site, totalement séparée de l'hébergeur (Google Drive, Dropbox, un bucket S3, ou au moins votre propre ordinateur).

Au moins une copie doit se trouver là où un attaquant qui pirate votre site ne peut pas accéder. Si la sauvegarde s'exécute automatiquement mais reste sur le compte d'hébergement, considérez-la comme zéro sauvegarde pour les scénarios graves. La copie hors serveur est celle qui vous sort vraiment de la crise.

Le test de restauration : la seule preuve que ça marche

C'est là que tout se joue. Vous ne savez pas que vous avez une sauvegarde tant que vous n'avez pas reconstruit le site à partir d'elle, dans un endroit qui n'abîme rien. Les étapes, en bref :

• Créez un environnement séparé : un sous-domaine de test (staging), ou une installation locale sur votre ordinateur avec un outil comme LocalWP ou XAMPP.
• Importez l'archive : remettez les fichiers en place et restaurez la base de données depuis le fichier .sql.
• Ouvrez le site restauré et vérifiez de vos yeux : la page d'accueil se charge-t-elle ? les images apparaissent-elles ? le menu, le formulaire de contact, la boutique fonctionnent-ils ?
• Connectez-vous à /wp-admin avec l'utilisateur de la sauvegarde. Si vous entrez et voyez les articles, vous avez une preuve.

Si quelque chose manque ou renvoie une erreur, vous l'avez appris maintenant, quand rien ne brûle. Faites ce test au moins une fois après chaque changement majeur du site.

Les façons les plus fréquentes dont une sauvegarde vous déçoit

Dans la pratique, les sauvegardes échouent presque toujours pour les mêmes quelques raisons :

• Archive corrompue ou incomplète : le processus s'est arrêté à mi-chemin (serveur trop faible, délai dépassé) et le fichier est inutilisable, mais l'extension a signalé « succès ».
• Uploads manquants : le dossier d'images a été exclu pour réduire la taille, donc le site restauré n'a pas de photos.
• Base de données seule, sans fichiers (ou l'inverse) — voir la première section.
• Sauvegarde ancienne et oubliée : l'automatisation s'est arrêtée il y a des mois et personne ne l'a remarqué.
• Stockage externe expiré : le compte cloud a manqué d'espace ou le jeton d'accès est tombé.

La seule vraie façon de repérer tout cela à temps est le test de restauration. Un journal vert n'est pas une preuve ; un site qui se reconstruit proprement, oui.

À quelle fréquence, combien de temps garder, et par où commencer

La fréquence dépend de la vitesse à laquelle le site change. Un blog actif ou une boutique qui reçoit des commandes mérite une sauvegarde quotidienne. Un site vitrine qui change rarement peut être sauvegardé chaque semaine. Bonne règle : vous ne voulez pas perdre plus de travail que vous n'êtes prêt à refaire.

Gardez plusieurs versions dans le temps, pas seulement la dernière. Si le site est infecté depuis une semaine et que vous n'avez qu'une copie d'hier, vous avez sauvegardé l'infection. Quelques sauvegardes échelonnées (quelques quotidiennes, quelques hebdomadaires) vous laissent le choix.

Chez MPO Web Studio, nous construisons des sites premium livrés à distance dans tout le pays, et pour les clients que nous entretenons nous configurons des sauvegardes automatiques hors site et faisons régulièrement le test de restauration, pour que ce soit une preuve, pas une supposition. Si vous n'êtes pas sûr que la vôtre fonctionne, écrivez-nous sur WhatsApp et nous la vérifions ensemble.