Sauvegarde de site web : la règle 3-2-1 et un test de restauration

La sauvegarde d’un site web semble un sujet ennuyeux, jusqu’au jour où le site disparaît. Il suffit d’un compte d’hébergement suspendu, d’une intrusion, d’une mise à jour défectueuse ou d’une erreur lors de la suppression de fichiers. On découvre alors si une sauvegarde existe, où elle se trouve et si l’on peut en restaurer quoi que ce soit.

Dans ce conseil, je présente la règle 3-2-1, un schéma simple qui protège un site d’entreprise et une boutique. Vous obtenez aussi la liste de ce qu’il faut copier et un test de restauration à faire une fois par trimestre. Cela vous prendra environ une heure et vérifiera que la sauvegarde fonctionne réellement.

Pourquoi une sauvegarde chez le même hébergeur ne suffit pas

La plupart des hébergeurs font des sauvegardes automatiquement, et c’est bien. Le problème est qu’elles se trouvent chez le même fournisseur, souvent sur le même compte ou dans le même centre de données. Une seule panne peut emporter le site et la sauvegarde en même temps.

Situations typiques où une telle sauvegarde n’aidera pas :

• perte d’accès au compte (mot de passe piraté, hébergement impayé, suspension du service),
• rançongiciel ou intrusion qui chiffre ou supprime les fichiers, et parfois aussi les sauvegardes accessibles depuis le compte,
• erreur du fournisseur qui supprime des données ou les restaure avec retard,
• votre propre erreur, remarquée après des semaines, quand les sauvegardes de l’époque ont disparu depuis longtemps.

La sauvegarde de l’hébergeur est donc une bonne protection, mais seulement l’une de plusieurs. Vérifiez dans la description de l’offre de votre fournisseur combien de jours de sauvegardes conserve votre formule (OVHcloud, home.pl, nazwa.pl et d’autres le décrivent chacun à leur manière), car la durée est parfois courte. Exemple : selon la documentation de l’hébergement web d’OVHcloud au 25 octobre 2026, les fichiers ne peuvent être restaurés que depuis une sauvegarde remontant, au plus loin, au dimanche d’il y a deux semaines, et le fournisseur lui-même recommande de faire régulièrement ses propres sauvegardes.

La règle 3-2-1 en termes simples

C’est un vieux schéma éprouvé de l’informatique. Vous le retiendrez en une phrase : 3 copies des données, sur 2 supports différents, dont 1 en dehors du serveur.

L’idée est qu’un seul événement ne puisse pas tout détruire. Un incendie de salle serveur, une intrusion ou un compte bloqué touchent un seul endroit, et la copie hors du serveur reste intacte.

Ce que doit contenir la sauvegarde

Un site n’est pas seulement des fichiers. Une bonne sauvegarde comprend deux parties, et il faut enregistrer les deux ensemble :

1. Les fichiers : thème, extensions, photos et documents importés, fichiers de configuration.
2. La base de données : contenus des pages, paramètres, commandes, comptes clients, messages des formulaires.

Dans une boutique, la base est plus importante que l’apparence. Vous referez les photos et le modèle, mais pas les commandes des dernières semaines. C’est pourquoi, dans une boutique, il vaut mieux sauvegarder la base souvent, au moins une fois par jour, de préférence chaque nuit.

Pensez aussi aux choses que l’on oublie généralement :

• le fichier de configuration avec les paramètres de connexion à la base,
• les clés et mots de passe des services (paiements, messagerie, API), conservés séparément dans un gestionnaire de mots de passe,
• les paramètres du domaine et de la messagerie (enregistrements DNS), qu’il est utile de noter sous forme de capture d’écran ou de liste.

À quoi ressemble un bon schéma en pratique : l’exemple de robimyweb.pl

Sur mon propre site robimyweb.pl, j’applique précisément cette organisation. Les données sont copiées chaque nuit sur le serveur, et le système conserve les 14 dernières sauvegardes. La sauvegarde est aussi téléchargée hors du serveur, sur un ordinateur que j’ai chez moi.

En plus, le panneau d’administration avertit quand la dernière sauvegarde a plus de 36 heures. C’est important, car la pire sauvegarde est celle qui a cessé d’être faite il y a un mois sans que personne ne le remarque. L’avertissement transforme « j’ai une sauvegarde » en « je sais qu’une sauvegarde récente existe ».

Votre version peut être plus simple. Trois choses sont essentielles : un calendrier automatique, une copie ailleurs et un signal quand quelque chose cesse de fonctionner.

Pas à pas : mettez en place votre propre schéma 3-2-1

Vous mettrez en œuvre le plan ci-dessous en un après-midi, si vous avez accès à l’espace d’administration de l’hébergement.

1. Vérifiez ce que fait l’hébergeur. Dans l’espace client, trouvez la section des sauvegardes. Notez à quelle fréquence elles sont créées et combien en sont conservées.
2. Activez la sauvegarde automatique si elle n’existe pas. Pour un site d’entreprise rarement modifié, une fois par semaine suffit ; pour une boutique, au moins une fois par jour, de préférence chaque nuit.
3. Ajoutez une copie hors du serveur. Téléchargez manuellement le fichier de sauvegarde une fois par semaine ou configurez un envoi automatique vers un second emplacement (autre fournisseur, disque réseau, cloud avec un compte distinct).
4. Sécurisez l’accès. Protégez le compte contenant les sauvegardes par un mot de passe robuste et une confirmation supplémentaire à la connexion. Une sauvegarde avec des données de clients contient les mêmes données que le site.
5. Notez qui en est responsable. Une personne et une note : où se trouvent les sauvegardes et comment les restaurer.

Si vous préférez ne pas vous en occuper vous-même, je réalise cette configuration dans le cadre de la maintenance technique : mises à jour, sauvegardes et réaction rapide aux demandes.

Test de restauration : une fois par trimestre

Une sauvegarde que personne n’a jamais restaurée n’est qu’une hypothèse. Il arrive que le fichier soit endommagé, que la base y manque ou qu’un répertoire vide ait été enregistré. Vous ne l’apprendrez que lorsqu’il sera trop tard.

Une fois par trimestre, faites un essai. Le mieux est de le noter dans le calendrier : première semaine de janvier, d’avril, de juillet et d’octobre.

1. Téléchargez la sauvegarde la plus récente depuis l’emplacement hors du serveur, et non depuis l’espace de l’hébergeur.
2. Restaurez-la dans un endroit séparé : sur un sous-domaine de test, sur un second compte d’hébergement ou en local. N’écrasez jamais le site en fonctionnement.
3. Ouvrez le site et naviguez dessus. Vérifiez la page d’accueil, les pages, les photos, le menu et le formulaire de contact.
4. Pour une boutique, en plus : regardez si les produits, les dernières commandes et les comptes clients sont là, et si le panier mène au paiement en mode test.
5. Notez le résultat : la date, la durée de la restauration et ce qui n’a pas fonctionné. Le temps de restauration est une information qui servira lors d’une vraie panne.

Si le test échoue, c’est une bonne nouvelle : vous découvrez le problème maintenant, et non le jour de la panne.

Les erreurs les plus fréquentes avec les sauvegardes

• Une sauvegarde des fichiers seulement, sans la base de données, ou l’inverse.
• Toutes les sauvegardes sur le même compte d’hébergement.
• Aucune notification quand la sauvegarde cesse d’être faite.
• Un historique trop court : une erreur remarquée après deux semaines, alors que les sauvegardes ne remontent qu’à trois jours.
• Une sauvegarde sur une clé USB qui traîne dans un tiroir et qui n’est jamais vérifiée.
• Aucune protection des sauvegardes contenant des données de clients : un accès libre au fichier de la base est une fuite de données.

Pour les données personnelles de vos clients, rappelez-vous que la sauvegarde les contient aussi. L’art. 32 du RGPD cite parmi les mesures de sécurité, entre autres, la capacité de rétablir rapidement la disponibilité des données après un incident ainsi que le test régulier des mesures de sécurité. Ce n’est pas un conseil juridique : fixez les règles de conservation et de protection des données avec un juriste ou un délégué à la protection des données. Je peux conserver les données de vos clients sur un serveur dans l’UE dans le cadre du service Données clients dans l’UE.

Que faire quand la panne a déjà eu lieu

Gardez votre calme et commencez par établir ce qui s’est passé. Restaurer une sauvegarde sur un site infecté sans supprimer la cause se termine souvent par une nouvelle intrusion.

1. Changez les mots de passe de l’espace d’hébergement, de la base, de la messagerie et de l’administration du site.
2. Trouvez la dernière sauvegarde saine, antérieure au moment du problème.
3. Restaurez-la dans un endroit de test et vérifiez que tout fonctionne.
4. Mettez à jour les logiciels (système, extensions, thème) avant la publication.
5. Ce n’est qu’alors que vous basculez le site vers la version restaurée.

En cas de doute sur la propreté du site, vous pouvez commander un audit de sécurité avec un rapport de correctifs. Si vous voulez régler au même endroit les sauvegardes, la surveillance et la protection du serveur, le service Cybersécurité du projet vous y aide.

Résumé

Une sauvegarde de site web a du sens quand il y a trois copies, deux supports et une copie hors du serveur, et que vous vérifiez la restauration une fois par trimestre. Une sauvegarde chez l’hébergeur seul ne suffit pas, car elle peut ne pas vous défendre contre la perte du compte ni contre une attaque qui atteint aussi les copies.

Si vous voulez que je configure les sauvegardes, le test de restauration et les alertes, écrivez-moi. Je chiffre la maintenance technique à partir de 149 PLN/mois HT, et le domaine et l’hébergement avec un serveur en Pologne ou dans l’UE à partir de 390 PLN/an HT. Vous pouvez aussi commencer par vérifier les bases de votre site avec l’outil gratuit Analyser votre site. La situation décrite dans ce conseil est valable au 27 octobre 2026.