Sauvegarder un site : fréquence, emplacement et test de restauration

Un site e-commerce qui perd sa base de données un vendredi soir, sans sauvegarde récente : 48 heures de commandes volatilisées, des fiches produits à recréer à la main et un chiffre d’affaires amputé le temps de tout reconstruire. Ce scénario, je l’ai vu arriver à trois reprises chez des clients qui pensaient que leur hébergeur s’occupait de tout. La réalité est plus nuancée : une sauvegarde fiable repose sur une fréquence adaptée, un emplacement hors du serveur principal et, surtout, un test de restauration régulier qui prouve que le fichier n’est pas corrompu.

Pourquoi « sauvegarder » ne suffit pas sans stratégie

Beaucoup de propriétaires de sites cochent la case « sauvegarde automatique » dans leur panneau d’hébergement et passent à autre chose. Le problème, c’est qu’une sauvegarde sans plan de restauration, sans vérification de l’intégrité et sans copie distante est une illusion de sécurité. J’ai récupéré des archives .tar.gz corrompues, des dumps SQL tronqués à 80 % et des sauvegardes qui dataient de six mois alors que le client les croyait hebdomadaires.

La sauvegarde d’un site web ne se résume pas à copier des fichiers. Elle doit couvrir trois couches distinctes : les fichiers du site (code source, thème, plugins, uploads), la base de données (articles, commandes, utilisateurs) et la configuration serveur (fichiers .htaccess, crons, certificats SSL, réglages PHP). Oublier l’une de ces couches, c’est se retrouver avec un puzzle incomplet le jour où l’on en a besoin.

Un site vitrine statique mis à jour une fois par mois et un site WooCommerce avec 200 commandes par jour n’ont évidemment pas les mêmes besoins. C’est pourquoi la fréquence, le type de sauvegarde et l’emplacement de stockage doivent être ajustés au profil du site. Si votre site a déjà été compromis, consultez d’abord le guide que faire quand un site WordPress est piraté avant de restaurer quoi que ce soit.

Quelle fréquence de sauvegarde adopter selon le type de site

La fréquence idéale dépend d’une question simple : combien de données pouvez-vous accepter de perdre ? Ce concept s’appelle le RPO (Recovery Point Objective). Si vous publiez un article par semaine sur un blog, perdre 24 heures de données est acceptable. Si vous gérez un site de réservation avec des transactions en temps réel, même une heure de perte peut être critique.

Pour un site WordPress classique, une sauvegarde quotidienne de la base de données combinée à une sauvegarde hebdomadaire des fichiers couvre la plupart des scénarios. Les fichiers du thème et des plugins changent rarement d’un jour à l’autre ; c’est la base de données qui contient les données vivantes (articles, commentaires, options). D’ailleurs, si vous versionnez déjà votre code avec Git, comme expliqué dans l’article sur Git pour versionner un site web, vos fichiers source sont déjà protégés côté développement.

Un point souvent négligé : la fréquence ne sert à rien sans rétention. Sauvegarder tous les jours mais ne conserver qu’une seule copie signifie que si le problème est détecté 48 heures après, la sauvegarde restante est déjà contaminée. Je recommande de garder au minimum 7 sauvegardes quotidiennes, 4 hebdomadaires et 2 mensuelles.

La règle du 3-2-1 : le socle de toute stratégie fiable

La règle du 3-2-1 est un standard reconnu par les professionnels de la sécurité informatique, recommandé notamment par l’CNIL dans ses recommandations de sécurité informatique. Elle se décompose ainsi :

• 3 copies de vos données (l’original + 2 sauvegardes)
• 2 supports différents (serveur + disque externe, ou serveur + stockage cloud)
• 1 copie hors site (dans un datacenter différent, un autre pays ou un service cloud distant)

Cette règle existe parce que les pannes ne viennent jamais seules. Un disque dur qui lâche peut entraîner la perte du serveur et de la sauvegarde locale si les deux sont sur la même machine physique. Un incendie dans un datacenter détruit tout ce qui s’y trouve. L’incendie du datacenter OVHcloud à Strasbourg en 2021 a rappelé brutalement cette réalité à des milliers de propriétaires de sites qui stockaient original et copie au même endroit.

Concrètement, pour un site hébergé chez un prestataire classique, la mise en œuvre ressemble à ceci : la copie n°1 reste sur le serveur (pratique pour les restaurations rapides), la copie n°2 part sur un stockage objet distant (type S3, Backblaze B2 ou un espace de stockage chez un autre hébergeur), et la copie n°3 peut être un export mensuel sur un disque local ou un NAS au bureau. Si vous vous interrogez sur les ressources nécessaires, l’article sur l’espace disque et la bande passante vous aidera à dimensionner.

Les trois types de sauvegarde : complète, incrémentielle, différentielle

Tous les backups ne se valent pas en termes de temps d’exécution, de poids de stockage et de rapidité de restauration. Comprendre les trois types permet de choisir la bonne combinaison.

La sauvegarde complète copie l’intégralité des fichiers et de la base à chaque exécution. C’est la plus simple et la plus fiable à restaurer : un seul fichier contient tout. En revanche, elle est gourmande en espace et en temps. Pour un site WordPress de 2 Go avec une base de 500 Mo, chaque sauvegarde complète pèse environ 2,5 Go. À raison d’une par jour sur 30 jours, cela représente 75 Go de stockage.

La sauvegarde incrémentielle ne copie que les fichiers modifiés depuis la dernière sauvegarde (qu’elle soit complète ou incrémentielle). Elle est très légère en stockage et rapide à exécuter. Le revers : pour restaurer, il faut la dernière sauvegarde complète plus toutes les incrémentielles successives. Si l’une d’elles est corrompue, la chaîne est brisée.

La sauvegarde différentielle copie les fichiers modifiés depuis la dernière sauvegarde complète. Elle est plus lourde qu’une incrémentielle (la taille grossit chaque jour) mais plus simple à restaurer : il suffit de la dernière complète + la dernière différentielle. C’est un bon compromis pour la plupart des sites.

La stratégie que j’applique sur la majorité des projets clients : une sauvegarde complète chaque dimanche et des différentielles du lundi au samedi. Cela donne un bon équilibre entre espace consommé et facilité de restauration. Pour les sites e-commerce actifs, j’ajoute des dumps SQL incrémentiels toutes les heures en complément.

Où stocker ses sauvegardes : emplacement et redondance

L’emplacement de stockage est aussi important que la sauvegarde elle-même. Stocker ses backups uniquement sur le même serveur que le site, c’est ranger la photocopie de ses papiers dans le même sac que les originaux. En cas de panne matérielle, de piratage ou de suppression accidentelle, tout disparaît en même temps.

Voici les emplacements possibles, classés du plus accessible au plus résilient :

• Même serveur, dossier séparé : pratique pour une restauration rapide, mais vulnérable aux pannes disque et aux attaques (ransomware inclus). Ne doit jamais être l’unique copie.
• Serveur FTP/SFTP distant : un espace chez un autre hébergeur. Simple à mettre en place avec un script cron ou un plugin. Bonne isolation géographique.
• Stockage objet cloud (Amazon S3, Backblaze B2, Google Cloud Storage, Scaleway Object Storage) : haute durabilité (99,999999999 % chez AWS), versioning intégré, coût faible (environ 5 à 7 euros par mois pour 100 Go).
• NAS local ou disque externe : copie physique hors réseau. Immune aux attaques en ligne, mais vulnérable aux sinistres locaux (incendie, vol).
• Service de sauvegarde managé (JetBackup, CodeGuard, BlogVault) : solution clé en main avec interface de restauration. Pratique mais ajoute une dépendance à un tiers.

Pour un site hébergé en mutualisé, la combinaison la plus réaliste est : sauvegarde locale automatique (proposée par l’hébergeur) + envoi vers un stockage cloud distant via plugin ou cron. Si vous envisagez de changer d’hébergeur, vérifiez que le nouvel hébergeur propose au minimum des sauvegardes quotidiennes avec rétention de 14 jours. C’est l’un des critères techniques qui comptent vraiment lors du choix.

Outils et méthodes concrètes pour automatiser les backups

L’automatisation est non négociable. Une sauvegarde manuelle, c’est une sauvegarde qu’on oublie. Selon votre environnement technique, plusieurs approches existent.

Pour les sites WordPress

UpdraftPlus est l’extension la plus utilisée, avec plus de 3 millions d’installations actives. La version gratuite permet de planifier des sauvegardes complètes et de les envoyer vers Dropbox, Google Drive, Amazon S3 ou un serveur FTP. La version premium ajoute la sauvegarde incrémentielle et le clonage de site. Configuration recommandée : fichiers en hebdomadaire, base de données en quotidien, rétention de 4 copies minimum.

Duplicator Pro est davantage orienté migration et clonage, mais il gère aussi les sauvegardes planifiées vers le cloud. Il excelle pour créer des packages de site complets facilement restaurables, même sur un serveur vierge.

WP-CLI combiné à un script bash et un cron serveur reste, à mon sens, la méthode la plus fiable pour les sites WordPress en production. Un simple wp db export suivi d’un tar des fichiers et d’un rclone sync vers un bucket S3 couvre tout le périmètre en quelques lignes. Après des années en agence, c’est l’approche que je privilégie sur les hébergements VPS ou dédiés.

Pour les sites non-WordPress

rsync avec SSH est le standard pour synchroniser des fichiers vers un serveur distant. Combiné à mysqldump ou pg_dump pour la base de données, cela forme un pipeline de sauvegarde complet, scriptable et testable. La commande rsync -avz --delete ne transfère que les différences, ce qui revient à une sauvegarde incrémentielle au niveau fichier.

Les hébergeurs comme o2switch, OVHcloud ou Infomaniak proposent des outils intégrés (JetBackup, Acronis) accessibles depuis le panel d’administration. Ces outils sont un bon filet de sécurité, mais ne doivent pas être votre unique ligne de défense. Vérifiez la rétention et l’emplacement réel des copies : certaines sauvegardes « automatiques » restent sur la même baie de stockage que votre site.

Si votre site utilise une version ancienne de PHP, pensez d’abord à mettre à jour la version de PHP : certains outils de sauvegarde récents nécessitent PHP 7.4 au minimum, et les gains de performance justifient à eux seuls la migration.

Le test de restauration : l’étape que tout le monde oublie

Voici la vérité que peu de guides mentionnent : un backup non testé n’est pas un backup. C’est un fichier dont on espère qu’il fonctionnera le jour J. J’ai vu des archives de sauvegarde s’accumuler pendant deux ans sans qu’aucune n’ait été testée. Le jour où le site a planté, la restauration a échoué : les dumps SQL étaient tronqués à cause d’un timeout PHP que personne n’avait remarqué.

Le test de restauration consiste à prendre une sauvegarde récente et à la déployer sur un environnement de test pour vérifier que le site fonctionne. Voici la procédure que je recommande :

1. Créer un sous-domaine de test (par exemple test.votredomaine.fr) ou utiliser un environnement local avec LocalWP ou DDEV.
2. Télécharger la dernière sauvegarde depuis l’emplacement distant (pas depuis le serveur de production).
3. Restaurer les fichiers dans le répertoire du sous-domaine de test.
4. Importer la base de données dans une base dédiée au test.
5. Modifier la configuration (wp-config.php ou .env) pour pointer vers la base de test et le bon domaine.
6. Vérifier le fonctionnement : page d’accueil, formulaire de contact, tunnel de commande, espace membre. Vérifier aussi que les médias (images, PDF) sont bien présents.
7. Documenter le résultat : date du test, durée de restauration, problèmes rencontrés.

La fréquence idéale du test de restauration dépend du profil du site. Pour un site vitrine, un test trimestriel suffit. Pour un e-commerce, un test mensuel est un minimum. Pour les plateformes critiques, il faut automatiser le test avec un script qui restaure et lance une suite de vérifications, chaque semaine.

Le test révèle aussi des problèmes structurels : une base de données WordPress gonflée par des révisions et des transients ralentit la sauvegarde et la restauration. Nettoyer la base de données régulièrement accélère les deux opérations et réduit la taille des archives.

Les erreurs fréquentes qui rendent un backup inutile

Au fil des années, j’ai identifié les mêmes erreurs récurrentes chez les propriétaires de sites qui pensaient être protégés :

• Sauvegarder les fichiers sans la base de données : les fichiers seuls sont une coquille vide. Sur WordPress, tout le contenu réside dans MySQL.
• Ne garder qu’une seule copie : si cette copie est corrompue ou si l’infection date de plusieurs jours, il n’y a aucun point de restauration sain vers lequel revenir.
• Stocker les backups dans le répertoire public (wp-content/backups/) : les archives deviennent téléchargeables par n’importe qui. C’est une faille de sécurité critique, car elles contiennent souvent les identifiants de la base de données en clair. La recommandation n°34 du guide d’hygiène informatique de l’ANSSI rappelle explicitement l’importance de protéger les sauvegardes.
• Compter uniquement sur l’hébergeur : les conditions générales de la plupart des hébergeurs précisent que les sauvegardes sont fournies « à titre gracieux, sans garantie ». Vous restez responsable de vos données.
• Ne jamais vérifier les emails de notification : les outils de sauvegarde envoient des rapports. Si les emails d’erreur passent en spam pendant des semaines, les sauvegardes peuvent échouer silencieusement.
• Oublier le dossier uploads : certaines configurations excluent le dossier wp-content/uploads pour gagner de la place. Le jour de la restauration, toutes les images sont manquantes.
• Ignorer les fichiers de configuration : wp-config.php, .htaccess, fichiers de configuration Nginx. Sans eux, la restauration demande de tout reconfigurer manuellement, ce qui allonge considérablement le temps d’indisponibilité.

Pour réduire la surface d’attaque en amont, un certificat SSL correctement configuré protège les échanges de données, y compris les transferts de fichiers de sauvegarde si vous utilisez un protocole sécurisé.