À quelle fréquence tester vos sauvegardes WordPress ?

La plupart des sites WordPress disposent d’une forme de sauvegarde. L’hébergeur en fait une, un plugin en fait une autre, et quelqu’un a peut-être téléchargé une copie à un moment donné.

La question qui dérange n’est pas de savoir si une sauvegarde existe. C’est de savoir si cette sauvegarde peut réellement remettre le site en ligne quand quelque chose tourne mal.

Les sauvegardes échouent plus souvent qu’on ne le pense. Un fichier peut être incomplet, la base de données peut manquer, le dossier des médias peut avoir été exclu pour gagner de la place, ou la seule copie peut se trouver sur le serveur qui vient justement de tomber en panne. En général, personne ne s’en aperçoit avant le jour où l’on a besoin de la sauvegarde.

La bonne nouvelle, c’est que cela se prévient facilement. Un test de restauration, mené calmement et à intervalles réguliers, vous indique si vos sauvegardes fonctionnent tant qu’il est encore temps de les corriger.

Ce guide explique ce qu’est un test de restauration, à quelle fréquence le réaliser selon le type de site, quoi vérifier et qui doit en être responsable.

Pourquoi une sauvegarde n’est-elle utile que si elle se restaure ?

Une sauvegarde est une promesse : si le site casse, est piraté ou supprimé, vous pouvez revenir à un état sain connu.

Cette promesse repose sur plusieurs conditions qui doivent être réunies en même temps :

• la sauvegarde contient tous les fichiers dont le site a besoin
• la sauvegarde contient la base de données, où se trouvent les pages, les réglages, les utilisateurs et les commandes
• la sauvegarde est assez récente pour être utile
• la sauvegarde est stockée à un endroit que vous pouvez encore atteindre si le serveur n’est pas disponible
• quelqu’un sait la restaurer et dispose des accès nécessaires

S’il manque un seul de ces éléments, la sauvegarde peut sembler correcte dans un tableau de bord et rester pourtant inutilisable.

Les problèmes fréquemment découverts lors des tests de restauration sont :

• des archives qui ont cessé d’être créées il y a des semaines sans que personne ne s’en rende compte
• des sauvegardes qui contiennent les fichiers mais pas la base de données, ou l’inverse
• des médias exclus parce que la sauvegarde était trop volumineuse
• des sauvegardes chiffrées avec un mot de passe dont personne ne se souvient
• des copies conservées uniquement sur le même compte d’hébergement que le site
• des procédures de restauration que seul le développeur d’origine comprenait

Aucun de ces cas n’est inhabituel. Ils restent simplement invisibles jusqu’à ce que quelqu’un tente une restauration.

Qu’est-ce qu’un test de restauration ?

Un test de restauration consiste à prendre une sauvegarde, à la restaurer réellement dans un endroit sûr, puis à vérifier que le site restauré fonctionne.

Ce n’est pas la même chose que :

• voir une coche verte dans un plugin de sauvegarde
• vérifier qu’un fichier de sauvegarde existe
• lire la taille de la sauvegarde dans le panneau d’hébergement

Ce sont des signaux utiles, mais ils ne prouvent pas que la sauvegarde permet de reconstruire le site.

Un vrai test de restauration se fait normalement sur :

• une copie de staging fournie par l’hébergeur
• un domaine ou un sous-domaine de test distinct
• une copie locale sur l’ordinateur d’un développeur

Il ne doit jamais se faire en écrasant le site en ligne. L’objectif est de tester la sauvegarde sans mettre le vrai site en danger.

À quelle fréquence tester vos sauvegardes ?

Il n’existe pas de réponse unique. La bonne fréquence dépend de la fréquence à laquelle le site change et de ce que coûterait à l’entreprise la perte des données récentes.

Comme point de départ, voici quelques repères.

Sites vitrines ou informatifs

Les sites qui changent quelques fois par mois, sans commandes ni comptes utilisateurs, peuvent généralement être testés moins souvent. Un test de restauration tous les quelques mois, et après tout changement important comme une refonte, une migration ou un changement d’hébergeur, constitue une base raisonnable.

Sites avec formulaires, réservations ou espaces membres

Si le site recueille des demandes, des réservations, des inscriptions ou des données de membres, la base de données change plus souvent. Tester plus régulièrement, par exemple tous les mois ou tous les deux mois, permet de confirmer que les données récentes sont bien sauvegardées.

Boutiques WooCommerce et sites très actifs

Les boutiques en ligne changent en permanence : commandes, clients, niveaux de stock et paiements. Ici, un test de restauration mensuel est un minimum raisonnable, et beaucoup d’entreprises préfèrent vérifier plus souvent. Il est aussi utile de vérifier que la fréquence des sauvegardes elle-même correspond au volume de commandes. Le guide pour savoir si une boutique WooCommerce a besoin de sauvegardes en temps réel traite cette question plus en détail.

Après tout changement important

Quel que soit le type de site, réalisez un test de restauration après :

• un changement d’hébergeur
• un changement de plugin ou de service de sauvegarde
• une mise à jour majeure de WordPress, du thème ou d’un plugin
• un incident de sécurité
• l’ajout d’une grande quantité de nouveaux contenus ou médias

Ce sont les moments où les réglages de sauvegarde ont le plus de chances de changer sans que personne ne s’en aperçoive.

Que vérifier après la restauration ?

Un site restauré dont la page d’accueil se charge, c’est un bon début, mais cela ne suffit pas. Vérifiez les éléments qui comptent pour votre activité.

Fichiers et code

• le thème actif se charge avec le bon design
• les plugins sont présents et actifs
• les fonctionnalités sur mesure fonctionnent toujours
• il n’y a pas d’erreurs de fichiers manquants

La base de données

• les pages, les articles et les menus sont présents
• les réglages semblent corrects, comme le nom du site et la langue
• les comptes utilisateurs existent et vous pouvez vous connecter avec un compte de test
• les contenus récents apparaissent, pas seulement les plus anciens

Les médias

• les images s’affichent sur les pages et dans la médiathèque
• les fichiers téléchargeables, comme les PDF, sont présents
• les images ajoutées récemment sont incluses

Des images manquantes sont l’un des signes les plus courants que le dossier wp-content/uploads n’a pas été inclus dans la sauvegarde.

Commandes récentes et entrées de formulaires

Si le site prend des commandes ou recueille des envois de formulaires :

• vérifiez la commande la plus récente dans la copie restaurée
• comparez sa date avec le moment où la sauvegarde a été réalisée
• vérifiez que les comptes clients et les abonnements sont présents
• vérifiez que les entrées de formulaires enregistrées sont incluses, si votre plugin de formulaires les stocke

Vous saurez ainsi précisément combien de données auraient été perdues si cette sauvegarde avait été restaurée sur le site en ligne.

Où stocker les copies de sauvegarde ?

Une sauvegarde stockée sur le même serveur que le site protège contre certains problèmes, comme une mauvaise mise à jour. Elle ne protège pas contre d’autres, par exemple :

• la suspension ou la compromission du compte d’hébergement
• une panne du serveur
• une perte de données chez l’hébergeur
• un attaquant qui supprime à la fois le site et ses sauvegardes

Pour cette raison, au moins une copie doit être conservée hors site, c’est-à-dire dans un emplacement distinct, géré indépendamment du compte d’hébergement. Il peut s’agir d’un service de sauvegarde dédié ou d’un stockage cloud que le site lui-même ne peut pas supprimer.

Lors des tests, il est utile de restaurer au moins de temps en temps depuis la copie hors site. C’est celle dont vous aurez besoin dans le pire des scénarios.

Combien de temps conserver les sauvegardes ?

La rétention désigne jusqu’où remontent vos sauvegardes dans le temps.

Ne conserver que les derniers jours peut poser problème. Certains incidents sont remarqués tardivement :

• un malware présent depuis des semaines
• un contenu supprimé par erreur et dont l’absence n’est remarquée que plus tard
• un plugin qui a lentement corrompu des données

Une approche courante consiste à conserver des sauvegardes récentes fréquentes, par exemple des copies quotidiennes pendant quelques semaines, et moins de copies anciennes, par exemple des copies hebdomadaires ou mensuelles sur une période plus longue. La bonne durée de rétention dépend de votre activité, de votre espace de stockage et de vos éventuelles obligations légales concernant les données clients.

N’oubliez pas que les sauvegardes contiennent des données personnelles si le site stocke des informations sur vos clients. Les anciennes sauvegardes doivent être protégées et supprimées lorsqu’elles ne sont plus nécessaires, conformément à vos obligations en matière de protection des données.

Qui est responsable des tests de sauvegarde ?

C’est souvent là que se situe la vraie faille. L’hébergeur suppose que le développeur teste les sauvegardes. Le développeur suppose que c’est l’hébergeur. Le dirigeant suppose que quelqu’un s’en occupe.

Il est utile de noter clairement :

• quels systèmes créent des sauvegardes, et à quelle fréquence
• où chaque copie est stockée
• qui vérifie que les sauvegardes sont bien créées
• qui réalise les tests de restauration, et à quelle fréquence
• qui dispose des accès nécessaires pour restaurer en urgence
• où sont conservées les instructions de restauration

Les sauvegardes de l’hébergeur sont utiles, mais beaucoup d’hébergeurs les présentent comme un service pratique plutôt que comme une garantie. Lisez les conditions de votre hébergeur pour comprendre ce qu’elles couvrent réellement.

Si personne n’en est clairement responsable, les tests de restauration ont tendance à ne jamais avoir lieu.

Quelles sont les erreurs les plus courantes ?

• Faire confiance au tableau de bord. Une notification de sauvegarde réussie ne signifie pas que la sauvegarde peut être restaurée.
• Tester sur le site en ligne. Restaurer par-dessus la production « pour voir si ça marche » peut écraser de vraies commandes et de vrais contenus.
• Ne garder qu’une seule copie. Une seule copie à un seul endroit est un point de défaillance unique.
• Oublier la base de données ou les médias. Une sauvegarde des seuls fichiers, ou de la seule base de données, n’est pas un site complet.
• Ne jamais vérifier la date de la sauvegarde. Si les sauvegardes se sont arrêtées sans bruit, la dernière copie peut dater de plusieurs semaines.
• Aucune procédure écrite. Sous pression, personne n’a envie de reconstituer la procédure de restauration à partir de zéro.

À quoi ressemble une bonne configuration ?

Un dispositif de sauvegarde sain comprend généralement :

• des sauvegardes automatiques à une fréquence adaptée au rythme de changement du site
• au moins une copie hors site
• une rétention suffisamment longue pour se remettre de problèmes remarqués tardivement
• des tests de restauration réguliers sur une copie de staging ou locale
• une courte note écrite pour chaque test : date, sauvegarde utilisée, éléments vérifiés, éléments manquants
• une personne ou un prestataire nommément responsable de tout cela

Il n’est pas nécessaire que ce soit compliqué. Il faut que ce soit fait avec régularité.

Comment D4Hub peut vous aider

D4Hub peut vous aider à faire de vos sauvegardes non plus une supposition, mais quelque chose que vous avez réellement vérifié.

Selon votre site, D4Hub peut vous aider à :

• passer en revue les sauvegardes existantes et leurs emplacements de stockage
• vérifier si les fichiers, la base de données et les médias sont inclus
• mettre en place une copie de sauvegarde hors site
• réaliser un test de restauration sur une copie de staging ou locale
• documenter une procédure de restauration que votre équipe peut suivre
• proposer une fréquence de sauvegarde et une durée de rétention adaptées à votre site
• intégrer les contrôles de sauvegarde à la maintenance continue grâce aux plans de support D4Hub

Vous pouvez demander de l’aide à tout moment, que vous souhaitiez un contrôle ponctuel ou des tests réguliers dans le cadre de la maintenance.

unzip -l backup.zip | grep "wp-content/uploads" | head
unzip -l backup.zip | grep "\.sql"

tar -tzf backup.tar.gz | grep "wp-content/uploads" | head
tar -tzf backup.tar.gz | grep "\.sql"

grep -c "CREATE TABLE" database.sql

wp db export test-site-before-import.sql
wp db import database.sql

wp search-replace "https://www.example.com" "https://staging.example.com" --dry-run

wp option update blog_public 0

Questions fréquentes

La sauvegarde de mon hébergeur suffit-elle ?

Elle peut constituer une bonne première couche, mais il est utile de vérifier ce qu’elle contient, combien de temps elle est conservée, si vous pouvez la restaurer vous-même et si elle est stockée séparément de votre compte d’hébergement. Beaucoup d’entreprises conservent aussi une copie indépendante hors site.

Puis-je tester une sauvegarde sans site de staging ?

Oui. Une copie locale sur un ordinateur, ou un sous-domaine temporaire, peut convenir. L’important est que le test ait lieu à l’écart du site en ligne et qu’il n’envoie pas d’e-mails ni ne traite de paiements.

Combien de temps dure un test de restauration ?

Cela dépend de la taille du site, de l’outil de sauvegarde et de l’environnement d’hébergement. Un petit site peut se restaurer rapidement, alors qu’une grande boutique avec beaucoup d’images prendra plus de temps. Le premier test est généralement le plus long, car vous mettez aussi la procédure au point.

Et si le test de restauration échoue ?

C’est une information utile, et il vaut bien mieux la découvrir maintenant que pendant une urgence. Notez ce qui a échoué, corrigez la configuration de sauvegarde et testez à nouveau. Un test raté révèle généralement un dossier manquant, une base de données exclue ou un problème de stockage.

Faut-il tester chaque sauvegarde ?

En général, non. Des contrôles automatiques confirmant que les sauvegardes sont créées, associés à des tests de restauration complets réguliers sur un échantillon, offrent un bon équilibre. Testez plus souvent après des changements d’hébergement, de plugins ou du système de sauvegarde lui-même.

Les sauvegardes doivent-elles respecter les règles de protection des données ?

Si votre site stocke des données personnelles, comme des informations clients ou des envois de formulaires, vos sauvegardes contiennent aussi ces données. Elles doivent être protégées, leur accès doit être limité et les anciennes copies doivent être supprimées conformément à vos politiques de rétention et de confidentialité.