Sauvegarde de site
Une sauvegarde de site WordPress est une copie datée de deux choses indissociables, la base de données et les fichiers, à partir de laquelle le site peut être remonté à l'identique.
Définition
Une sauvegarde de site WordPress est une copie datée de deux choses indissociables, la base de données et les fichiers, à partir de laquelle le site peut être remonté à l’identique. L’erreur qui coûte le plus cher tient en une phrase : copier les fichiers ne sauvegarde pas la base, et la base ne contient aucune de vos images.
Pourquoi une sauvegarde a toujours deux moitiés
Parce qu’un site WordPress est rangé à deux endroits qui n’ont rien à voir l’un avec l’autre.
La documentation de WordPress est explicite sur ce point, au point d’y consacrer un paragraphe entier : sauvegarder un site comporte deux parties, la base de données et les fichiers, et il faut les deux pour restaurer un site complet.
Les fichiers sont ce que vous voyez dans le dossier du site sur le serveur : le cœur de WordPress, le thème, les extensions, les images déposées, le fichier de configuration. Ils se copient comme n’importe quel dossier.
La base de données, elle, est ailleurs. C’est un service séparé, MySQL ou MariaDB selon l’hébergement, qui vit à côté du site et pas dedans. Elle contient les textes de vos pages, les réglages, les comptes, les menus, et la liste des médias avec l’endroit où chacun est rangé. La conséquence est directe et c’est celle qu’on oublie : télécharger le dossier du site ne récupère pas la base, puisque la base n’est pas dans le dossier.
Ce que donne une moitié seule. Les fichiers sans la base, ce sont vos images et votre thème, et pas une seule page : le site redémarre vide, comme une installation neuve. La base sans les fichiers, ce sont vos textes qui pointent vers des images absentes, avec un thème manquant. Dans les deux cas, ce qui est perdu n’est pas récupérable depuis l’autre moitié.
L’ordre, à la sauvegarde et à la restauration
Il n’est pas le même dans les deux sens, et ce détail évite des incohérences.
La documentation recommande de traiter les fichiers et la base comme un ensemble unique, pris à peu près au même moment, et donne un ordre pour chaque opération.
| Sauvegarder | Restaurer | |
|---|---|---|
| On commence par | La base de données | Les fichiers |
| On poursuit par | Les fichiers | L’import de la base |
| Point de vigilance | Ranger l’export de la base avec les fichiers, pour qu’ils ne se séparent pas | Reprendre les identifiants de connexion à la base dans le fichier de configuration si le serveur a changé |
Les deux moitiés ont chacune leur outil classique quand on les fait à la main. Les fichiers se récupèrent par un client FTP ou par le gestionnaire de fichiers de l’hébergement, et se rangent volontiers dans une archive zip pour occuper moins d’espace. La base s’exporte depuis phpMyAdmin, l’outil que presque tous les hébergements mutualisés proposent, ou par une commande sur le serveur. La documentation détaille les deux chemins, et recommande de garder les copies sur des supports et à des endroits différents, dont un stockage distant et une copie hors du serveur.
L’export de la base produit un fichier, souvent avec une extension .sql, éventuellement compressé. Ce fichier se range à côté des autres, mais il ne se restaure pas en le recopiant : il doit être réimporté dans le service de base de données. C’est une opération distincte, et c’est elle que les gens découvrent le jour de l’urgence.
À quelle fréquence, et combien en garder
Deux réponses tiennent dans la documentation officielle, la troisième dépend de vous.
Sur la fréquence, WordPress donne un ordre de grandeur plutôt qu’une règle : une sauvegarde par semaine pour un site qui publie peu, une par jour pour un site très actif. Et surtout, une sauvegarde avant chaque mise à jour, ce qui en fait le premier geste de toute mise à jour sérieuse.
Sur le nombre, la recommandation est de conserver au moins trois à cinq sauvegardes récentes, rangées à des endroits différents : une chez l’hébergeur, une sur un stockage distant, une hors ligne. Une seule copie, au même endroit que le site, disparaît avec lui.
La troisième question n’a pas de réponse générale : combien de temps de contenu acceptez-vous de perdre ? Une sauvegarde hebdomadaire signifie que vous acceptez de perdre jusqu’à six jours de publications et de commandes. C’est une décision de dirigeant, pas un réglage technique.
Cette fiche définit ce qu’est une sauvegarde et ce qu’elle doit contenir. Pour la mise en pratique, quoi automatiser, où déposer les copies et comment s’organiser, nous avons détaillé notre méthode dans notre article sur les meilleures pratiques de sauvegarde d’un site WordPress.
La seule preuve qu’une sauvegarde existe
C’est de l’avoir déjà remontée, ailleurs, au moins une fois.
La documentation le dit à sa manière, en recommandant de doubler de temps en temps les sauvegardes automatiques par une sauvegarde manuelle, pour garantir que le mécanisme fonctionne vraiment. Derrière cette précaution, il y a une réalité de terrain : un dispositif de sauvegarde peut tourner pendant des mois en produisant des archives vides, incomplètes, ou illisibles, sans qu’aucune alerte ne se déclenche.
La vérification ne consiste donc pas à regarder si le voyant est vert, mais à prendre la dernière archive et à la remonter sur une préproduction. Cet essai répond aussi à la question qu’on se pose toujours trop tard : combien de temps prend le retour en ligne ? C’est ce qui sépare une sauvegarde d’un vrai retour arrière, et c’est ce qu’un contrat de maintenance doit décrire noir sur blanc.
Un cas mérite d’être signalé à part : après un piratage, la sauvegarde ne suffit plus. Restaurer une archive prise après l’intrusion remet en place ce qui a permis l’intrusion, et l’opération relève alors de la restauration après piratage, pas d’un simple retour en arrière.
Relevé du 18 septembre 2026 sur ilti.fr, en lecture seule. Le site pèse environ 640 Mo de fichiers, dont 166 Mo de médias, et sa base de données 51 255 360 octets, soit environ 49 Mo. Les deux moitiés sont très inégales en poids et parfaitement égales en importance : la base contient 140 contenus rédigés, quand le disque porte 198 fichiers de médias. Copier le dossier du site sauvegarde les 198 images sans une seule page. Exporter la base sauvegarde les 140 pages sans une seule image. Deuxième constat, plus parlant encore : le site porte une extension de sauvegarde bien connue, installée et désactivée, qui occupe 32 Mo sur le disque, et son dossier d’archives, wp-content/updraft, est vide depuis le 24 mai 2021. Pendant plus de quatre ans, un site a donc eu l’apparence d’être sauvegardé par une extension qui n’a jamais produit une seule archive. Les sauvegardes réelles de ce site viennent d’ailleurs, de l’hébergeur et de l’outil de supervision du parc, et c’est précisément le genre de chose qu’il faut vérifier plutôt que supposer.
Questions fréquentes
Mon hébergeur fait des sauvegardes, est-ce suffisant ?
C’est une base utile, mais pas une réponse complète. La documentation de WordPress rappelle que la plupart des hébergeurs sauvegardent le serveur entier, et que récupérer une copie de son site dans ces sauvegardes prend du temps, alors que la rapidité de remise en ligne est justement ce qui compte. Les deux questions à poser à votre hébergeur sont la profondeur de rétention et le délai de restauration.
Une copie du dossier du site, faite par FTP, suffit-elle ?
Non, et c’est le contresens le plus répandu. Elle récupère les fichiers, donc le thème, les extensions et les médias, mais pas la base de données, qui vit en dehors de ce dossier. Vos textes ne sont pas dedans.
Faut-il sauvegarder avant chaque mise à jour ?
Oui, et la documentation officielle le place en première étape de sa procédure de mise à jour, avant même la mise à jour elle-même. C’est ce qui rend l’opération réversible, donc ce qui la rend acceptable sur un site en production.
Combien de temps faut-il conserver une sauvegarde ?
Assez longtemps pour couvrir le délai entre un incident et le moment où l’on s’en aperçoit. Une injection discrète peut passer inaperçue plusieurs semaines : si toutes les copies conservées sont postérieures, elles contiennent toutes le problème. C’est l’argument en faveur d’une rétention plus longue que celle que l’on pense nécessaire.
Sources
Et sur votre site ?
Une définition ne dit pas si vous êtes concerné.
L'audit gratuit répond dans votre cas : état technique, temps de chargement, et ce que Google voit réellement de vos pages. Un constat écrit, sans engagement et sans jargon.