Le pire moment pour découvrir que votre sauvegarde ne marche pas, c'est quand vous en avez besoin.
Trois cas reviennent. Le fichier de sauvegarde existe mais il ne contient que la base de données. La sauvegarde est complète mais elle dort sur le serveur qui vient de tomber. Ou elle est là, elle est complète, elle est ailleurs, et personne n'a jamais essayé de la restaurer.
Voilà comment faire les choses correctement.
Une sauvegarde WordPress contient deux choses, pas une
Votre site vit à deux endroits.
Les fichiers sur le disque du serveur : le cœur de WordPress, votre thème, vos extensions, et surtout wp-content/uploads où sont toutes vos images.
La base de données : vos articles, vos pages, vos réglages, vos comptes utilisateurs, vos commandes WooCommerce si vous en avez. Si cette répartition ne vous parle pas, commencez par comment est fait un site WordPress.
Une sauvegarde de base de données seule restitue tous vos textes avec des images cassées partout. Une sauvegarde de fichiers seule restitue vos images sans aucune page pour les afficher.
Les deux. Toujours. Et prises au même moment, sinon vous restaurez un contenu qui référence des fichiers qui n'existent pas encore.
L'erreur qui rend une sauvegarde inutile
La sauvegarde stockée sur le serveur qu'elle est censée protéger.
C'est le réglage par défaut de plusieurs extensions gratuites : elles écrivent leurs archives dans wp-content/backups ou wp-content/uploads. Tant que le problème vient d'une mise à jour ratée, ça marche. Le jour où le serveur tombe, où le compte d'hébergement est suspendu, ou où un ransomware chiffre le disque, la sauvegarde part avec le site.
La règle utilisée en archivage depuis longtemps s'appelle 3-2-1 : trois copies de la donnée, sur deux supports différents, dont une hors site. Appliquée à WordPress, ça donne le site en production, une archive chez l'hébergeur, et une archive dans un stockage externe (Google Drive, Dropbox, un espace S3, ou votre disque local).
Le point qui compte, c'est le troisième. Le reste est du confort.
La sauvegarde de votre hébergeur ne suffit pas
Les hébergeurs mutualisés proposent presque tous des sauvegardes automatiques. C'est utile, et ce n'est pas une stratégie complète.
Trois questions à poser à votre hébergeur, par écrit :
- Quelle est la durée de rétention ? Sept jours de rétention ne servent à rien contre un piratage découvert trois semaines plus tard.
- Les archives sont-elles stockées sur une infrastructure séparée de celle du site ?
- La restauration est-elle incluse, ou facturée à l'acte ?
Certains hébergeurs répondent correctement aux trois. D'autres non. Je ne peux pas vous dire lequel fait quoi sans vérifier votre contrat, et les offres changent. Vérifiez plutôt que de supposer.
Le vrai risque n'est pas technique. Une sauvegarde d'hébergeur restaure l'état du serveur. Elle ne restaure pas un site WordPress dans un environnement différent le jour où vous changez de prestataire.
Les quatre façons de sauvegarder
Une extension dédiée. UpdraftPlus, BackWPup et Duplicator font le travail. Vous programmez la fréquence, vous branchez un stockage distant, vous oubliez. Point de vigilance : vérifiez que la destination distante est bien configurée et que les archives y arrivent réellement. Une extension qui échoue silencieusement est pire que pas d'extension du tout, parce qu'elle vous donne l'illusion d'être couvert.
L'hébergeur. À utiliser en complément, jamais seul, pour les raisons ci-dessus.
En ligne de commande. Si vous avez un accès SSH, WP-CLI fait l'export de base en une commande :
wp db export sauvegarde-$(date +%F).sqlEt pour les fichiers :
tar -czf uploads-$(date +%F).tar.gz wp-content/uploadsC'est la méthode la plus fiable et la plus rapide sur les gros sites, parce qu'elle ne dépend pas de PHP et de ses limites de temps d'exécution. Le poids du fichier exporté dépend directement de l'état de votre base de données WordPress.
Manuellement. Export SQL depuis phpMyAdmin, téléchargement des fichiers en FTP. Ça fonctionne, c'est lent, et personne ne le fait deux semaines de suite. À réserver aux sauvegardes ponctuelles avant une intervention lourde.
À quelle fréquence sauvegarder
La bonne question n'est pas « à quelle fréquence » mais « combien de données puis-je me permettre de perdre ».
Un site vitrine que vous mettez à jour une fois par trimestre : une sauvegarde hebdomadaire suffit. Perdre trois jours ne change rien.
Un blog avec deux publications par semaine : sauvegarde quotidienne de la base, hebdomadaire des fichiers. Les fichiers bougent peu, la base bouge tout le temps.
Une boutique WooCommerce : sauvegarde quotidienne au minimum, et idéalement en continu sur la base. Une commande perdue, c'est un client perdu et un litige.
Dans tous les cas, une sauvegarde manuelle complète avant chaque mise à jour majeure de WordPress, de thème ou d'extension. C'est celle qui sert le plus souvent.
Tester une restauration, l'étape que personne ne fait
Une sauvegarde n'existe pas tant qu'elle n'a pas été restaurée au moins une fois.
Le test tient en quatre étapes :
- Créez un environnement de test, un sous-domaine ou un espace de préproduction chez votre hébergeur.
- Restaurez la dernière archive dessus.
- Ouvrez le site. Vérifiez l'accueil, une page intérieure, une image, le formulaire de contact, et la connexion à l'administration.
- Notez le temps que ça vous a pris.
Ce dernier point est celui que les gens négligent. Savoir que vous pouvez restaurer en quarante minutes change la façon dont vous réagissez à un incident.
Faites ce test une fois par an. Deux fois si vous vendez en ligne.
Ce qu'une sauvegarde ne fait pas
Elle ne remplace pas les mises à jour. Restaurer un site piraté sur une version vulnérable, c'est se faire pirater à nouveau dans la semaine. C'est précisément ce que couvre un contrat de maintenance WordPress.
Elle ne détecte pas les problèmes. Un site infecté depuis un mois produit des sauvegardes infectées. C'est le monitoring qui repère l'anomalie, pas la sauvegarde. Un audit UX et SEO permet de faire le point sur l'état réel d'une installation.
Elle ne protège pas des erreurs humaines découvertes tard. Une page supprimée par erreur et repérée quarante jours plus tard n'est plus dans aucune archive si votre rétention est de trente jours.
La sauvegarde est le dernier filet. Elle ne remplace pas le reste du dispositif.
FAQ
Une sauvegarde de base de données suffit-elle ?
Non. Les images, le thème et les extensions sont sur le disque, pas dans la base. Une restauration de base seule donne un site avec des images cassées.
Où stocker mes sauvegardes WordPress ?
Sur un support indépendant de l'hébergement du site : Google Drive, Dropbox, un espace de stockage objet, ou un disque local. Le point important, c'est que la panne du serveur n'emporte pas l'archive.
Combien de temps garder une sauvegarde ?
Trente jours minimum. Un piratage ou une suppression accidentelle se découvre rarement le jour même.
UpdraftPlus, BackWPup ou Duplicator : lequel choisir ?
Les trois font le travail sur un site standard. La différence se joue sur l'ergonomie de la restauration et la gestion des gros sites. Testez la restauration avant de trancher, c'est le seul critère qui compte le jour J.
Faut-il sauvegarder avant chaque mise à jour ?
Avant chaque mise à jour majeure de WordPress, du thème ou d'une extension critique, oui. Pour les mises à jour mineures de sécurité, une sauvegarde quotidienne automatique couvre le risque.
Mon hébergeur sauvegarde déjà, pourquoi en faire plus ?
Parce que vous ne contrôlez ni la rétention, ni le lieu de stockage, ni le délai de restauration. Et parce qu'une sauvegarde d'hébergeur ne vous suit pas si vous changez d'hébergeur.
Ce qu'il faut retenir
- Fichiers et base de données, pris au même moment. Jamais l'un sans l'autre.
- Au moins une copie hors du serveur qui héberge le site.
- Trente jours de rétention minimum.
- Une restauration testée une fois par an, sinon vous ne savez pas si ça marche.
Pour un commerce de proximité dont le site porte les horaires, le menu ou le formulaire de contact, une journée hors ligne se compte en clients perdus.
Ouvrez votre extension de sauvegarde maintenant et regardez la date de la dernière archive envoyée vers le stockage distant. Si la date vous surprend, vous avez votre réponse.
