Une sauvegarde WordPress ne se résume pas à télécharger quelques fichiers du site. Pour pouvoir remettre un site en ligne après une erreur, une mise à jour défaillante, une suppression accidentelle ou une attaque, il faut conserver plusieurs éléments qui fonctionnent ensemble.
Un site WordPress repose notamment sur :
Une copie des fichiers sans la base de données peut laisser un site sans ses articles ni ses réglages. À l’inverse, une base de données restaurée sans les médias ni les extensions compatibles peut provoquer des erreurs ou un affichage incomplet. La première décision consiste donc à définir ce que la sauvegarde doit rendre possible : récupérer quelques fichiers, revenir à une version antérieure ou reconstruire entièrement le site sur un autre environnement.
La base de données contient les contenus éditoriaux, les utilisateurs, les réglages généraux et de nombreuses données créées par les extensions. Elle évolue chaque fois qu’un article est publié, qu’un commentaire est enregistré, qu’une commande est passée ou qu’un réglage est modifié. Pour un site actif, sa sauvegarde mérite une fréquence élevée.
Une exportation de la base doit être réalisée dans un format exploitable, généralement un fichier SQL ou une archive contenant ce fichier. Le nom de la base, son utilisateur, son mot de passe et son préfixe de tables ne doivent pas être confondus avec le contenu sauvegardé. Ces informations peuvent être nécessaires lors d’une restauration, mais elles doivent être stockées avec une protection adaptée.
Le dossier wp-content/uploads est particulièrement important pour les images, les documents et les autres médias téléversés depuis l’administration. Les thèmes et extensions personnalisés doivent également être conservés. Les fichiers du cœur de WordPress peuvent être récupérés depuis une source officielle, mais conserver une copie complète aide à reproduire l’état exact du site au moment de la sauvegarde.
Le fichier wp-config.php contient des informations sensibles. Il ne doit pas être envoyé dans un espace public, ajouté à un dépôt accessible sans contrôle ou joint à un message non protégé. Une sauvegarde exploitable doit donc être complète, mais son stockage doit respecter le principe de moindre exposition.
Une stratégie utile associe plusieurs mécanismes plutôt qu’une seule copie automatique. Le rythme dépend de la fréquence de publication et de la valeur des données. Un site vitrine mis à jour rarement n’a pas les mêmes besoins qu’un site éditorial quotidien, une boutique ou un espace qui reçoit régulièrement des inscriptions.
Deux notions permettent de choisir ce rythme :
Pour organiser les copies, la règle 3-2-1 est une référence couramment utilisée dans les politiques de sauvegarde et reprise d’activité, notamment dans les recommandations de sécurité diffusées par la Cybersecurity and Infrastructure Security Agency. Elle consiste à conserver plusieurs copies, sur des supports distincts, avec au moins une copie séparée du site d’origine. L’intérêt ne réside pas dans la formule elle-même, mais dans la réduction des risques liés à une panne d’hébergement, une erreur humaine, un logiciel malveillant ou une suppression propagée à toutes les copies connectées.
Une organisation cohérente peut comprendre :
Les copies doivent avoir des dates lisibles et une politique de conservation. Garder uniquement la dernière sauvegarde réduit fortement les possibilités de retour en arrière si le problème est découvert plusieurs jours après son apparition.
Une sauvegarde complète recopie l’ensemble des fichiers sélectionnés et la base de données. Elle est généralement la plus directe à comprendre et à restaurer, mais elle peut occuper davantage d’espace et solliciter davantage le serveur.
Une sauvegarde incrémentale conserve les changements intervenus depuis la sauvegarde précédente. Elle réduit le volume transféré, mais une restauration peut dépendre de plusieurs jeux de sauvegarde successifs. Si l’un d’eux est endommagé ou manquant, la chaîne peut devenir inexploitable.
Une sauvegarde différentielle conserve les changements depuis la dernière sauvegarde complète. Elle demande davantage d’espace qu’une sauvegarde incrémentale au fil du temps, tout en limitant le nombre de fichiers nécessaires à la restauration.
Le meilleur choix dépend des ressources de l’hébergement, de la taille du site et de la capacité à administrer le système. Une solution très sophistiquée n’apporte pas de sécurité réelle si personne ne sait vérifier ses journaux, retrouver les fichiers ou lancer une restauration. La lisibilité de la procédure compte autant que l’automatisation.
Plusieurs chemins sont possibles. Depuis l’administration WordPress, une extension de sauvegarde peut programmer l’export de la base, la copie des fichiers et l’envoi vers un stockage distinct. Avant de l’activer, il faut vérifier les points suivants :
Le stockage de la sauvegarde dans le même compte d’hébergement que le site protège contre certaines erreurs, mais pas contre tous les incidents. Une compromission du compte ou une suppression globale peut toucher le site et ses copies. Une destination distincte est donc préférable pour les sauvegardes qui doivent servir de dernier recours.
L’espace client de l’hébergeur propose parfois des instantanés ou des sauvegardes automatiques. Ces fonctions peuvent être utiles pour revenir rapidement à un état antérieur, mais elles ne remplacent pas nécessairement une copie indépendante. Il faut connaître leur périmètre : fichiers seulement, base de données, messagerie, réglages du serveur, certificats et tâches planifiées. Il faut aussi vérifier la durée pendant laquelle les points de restauration restent disponibles.
Lorsqu’une sauvegarde est exportée manuellement, conserver un inventaire évite les ambiguïtés. Pour chaque archive, noter la date, le type de sauvegarde, la version de PHP, la version de WordPress et les versions importantes des extensions permet de mieux diagnostiquer une incompatibilité ultérieure.
Une sauvegarde contient souvent des données personnelles, des contenus privés, des identifiants techniques ou des informations de configuration. Elle doit être traitée comme une donnée sensible, et non comme un fichier ordinaire.
Les mesures utiles comprennent :
Une sauvegarde accessible par le même compte administrateur que le site peut être supprimée par un attaquant qui aurait obtenu cet accès. La séparation des comptes et des permissions limite ce risque. Les fichiers de sauvegarde ne doivent pas non plus être placés dans un dossier publiquement accessible depuis le navigateur. Une URL difficile à deviner n’est pas une mesure de protection suffisante.
Une sauvegarde non testée reste une hypothèse. L’archive peut être incomplète, corrompue, impossible à déchiffrer ou incompatible avec l’environnement de restauration. Un test périodique permet de détecter ces problèmes lorsque le site fonctionne encore.
La vérification peut suivre ce déroulement :
Un environnement de test peut être installé sur un espace distinct, un sous-domaine non indexé ou une machine locale, à condition de ne pas exposer des données personnelles. Les moteurs de recherche doivent être empêchés d’indexer ce doublon, et l’accès doit être protégé par une authentification.
Le test doit aussi confirmer que la procédure est compréhensible par une autre personne habilitée. Une documentation qui décrit les étapes, les accès nécessaires et les points de contrôle réduit la dépendance à une seule personne.
Une extension, un thème ou une version de PHP peut provoquer une page blanche, une erreur fatale ou un affichage dégradé. Avant de restaurer une ancienne version, identifier l’élément déclencheur évite d’effacer des modifications récentes qui ne sont pas responsables de la panne.
La procédure peut être organisée ainsi :
Restaurer uniquement la base peut réintroduire des réglages incompatibles avec les fichiers actuels. Restaurer uniquement les fichiers peut supprimer des modifications récentes du thème ou des médias. Le choix doit correspondre à l’étendue de l’incident. Lorsque seules quelques données ont été supprimées, une restauration ciblée ou un import sélectif peut éviter un retour en arrière global.
Un site piraté ne doit pas être restauré immédiatement sans analyse. Une sauvegarde créée après l’intrusion peut contenir une porte dérobée, un compte ajouté ou un fichier modifié. La priorité consiste à contenir l’incident et à préserver les éléments utiles au diagnostic.
Les premières mesures sont les suivantes :
La restauration ne corrige pas la cause de la compromission si un mot de passe reste connu, si une extension vulnérable est réinstallée ou si un accès technique oublié demeure actif. Après la reprise, vérifier les utilisateurs, les tâches planifiées, les fichiers récemment modifiés et les règles de redirection. Les données personnelles éventuellement exposées doivent être évaluées selon les obligations applicables au responsable du traitement et au contexte concerné.
Une sauvegarde peut servir à déplacer un site vers un nouvel hébergement, mais une migration n’est pas une restauration à l’identique dans tous les cas. Le nom de domaine, les chemins de fichiers, les paramètres du serveur et les versions logicielles peuvent changer.
Sur le nouvel environnement, vérifier avant l’import :
Après l’import de la base, les anciennes adresses peuvent encore être présentes dans les réglages et le contenu. Une recherche et un remplacement mal exécutés peuvent casser des données sérialisées utilisées par WordPress et certaines extensions. Il faut employer une méthode compatible avec ces structures, puis tester les liens, les images et les formulaires.
Le basculement du nom de domaine doit intervenir après les vérifications. Une page de maintenance, une réduction du délai de mise en cache et une sauvegarde finale avant changement limitent le risque de perte de données pendant la transition.
| Élément à vérifier | Question pratique | Réponse attendue |
|---|---|---|
| Périmètre | La sauvegarde contient-elle les fichiers et la base de données ? | Le contenu, les médias, les extensions et les réglages nécessaires sont couverts. |
| Fréquence | Combien de données peuvent être perdues ? | Le rythme est aligné sur les publications et les transactions du site. |
| Indépendance | Que se passe-t-il si l’hébergement disparaît ou est compromis ? | Une copie distincte reste disponible avec des identifiants séparés. |
| Conservation | Peut-on revenir à une date antérieure à la découverte du problème ? | Plusieurs générations sont conservées selon une règle documentée. |
| Restauration | La copie a-t-elle déjà été restaurée ? | Un test dans un environnement séparé confirme son exploitabilité. |
| Sécurité | Qui peut lire, modifier ou supprimer les archives ? | Les permissions sont limitées et l’accès multifacteur est activé lorsque possible. |
| Documentation | Une autre personne peut-elle suivre la procédure ? | Les accès, étapes, contrôles et actions de retour sont consignés. |
Ce tableau peut être transformé en liste de contrôle interne. Il doit être révisé après un changement d’hébergement, de thème, d’extension ou de méthode de stockage. Une stratégie fiable évolue avec le site.
Elle peut constituer une protection importante, mais il faut connaître son périmètre, sa durée de conservation et la méthode de récupération. Une copie indépendante reste préférable pour éviter qu’un incident touchant le compte d’hébergement atteigne aussi les sauvegardes.
Oui, une sauvegarde récente est pertinente avant une mise à jour du cœur, d’un thème ou d’une extension. Elle doit être contrôlée et correspondre à un état que l’on sait restaurer. Pour les mises à jour importantes, un test préalable dans un environnement séparé réduit encore le risque.
Il n’existe pas un ordre universel. La décision dépend de l’incident. Une suppression d’image peut concerner les fichiers, tandis qu’une erreur de réglage peut concerner la base. Pour une restauration complète, les deux ensembles doivent provenir d’une période cohérente.
Il faut la restaurer dans un environnement de test et contrôler le fonctionnement du site. La présence d’un fichier d’archive et sa taille ne prouvent pas que la base est complète ou que les fichiers sont compatibles avec l’environnement.
Elle aide à revenir à un état antérieur, mais ne bloque pas l’intrusion. Les mises à jour, l’authentification multifacteur, la limitation des accès et la surveillance des journaux restent nécessaires. Après une attaque, choisir une copie antérieure à l’intrusion et corriger la cause de la compromission sont indispensables.
