Sauvegardes immuables WordPress : choisir son hébergeur

Une sauvegarde WordPress n’est réellement utile que si elle reste disponible après un incident grave. Or, lors d’une compromission, un attaquant ne cible pas uniquement les fichiers publics du site : il peut aussi chercher à supprimer les sauvegardes accessibles depuis le même compte d’hébergement, le même panneau d’administration ou les mêmes identifiants cloud.

Les sauvegardes immuables répondent à ce risque. Pendant une période de conservation prédéfinie, elles ne peuvent pas être modifiées ni effacées, y compris en cas de suppression accidentelle ou de compromission d’un compte disposant de droits élevés. Pour un site WordPress professionnel, une boutique WooCommerce ou un média, cette propriété peut faire la différence entre une restauration rapide et une perte durable de données.

Le terme est toutefois parfois employé de manière imprécise dans les offres d’hébergement. Une sauvegarde quotidienne, une conservation de plusieurs jours ou une réplication sur un second serveur ne signifient pas nécessairement que les données sont immuables. Avant de choisir un hébergeur WordPress, il faut donc comprendre ce que recouvre cette protection et savoir quelles questions poser.

Sauvegarde immuable : définition et différence avec une sauvegarde classique

Une sauvegarde immuable est une copie dont les données sont verrouillées pendant une durée déterminée. Durant cette période, la suppression et la modification sont bloquées par le mécanisme de stockage, et pas seulement par une règle affichée dans une interface d’administration.

Le principe est souvent associé au modèle WORM, pour Write Once, Read Many : les données sont écrites une fois, puis peuvent être lues autant de fois que nécessaire sans pouvoir être réécrites. Dans les infrastructures cloud, des mécanismes tels que Amazon S3 Object Lock permettent par exemple de définir une période de rétention sur des objets stockés dans un compartiment compatible.

Une sauvegarde classique suit généralement un cycle plus simple :

• une tâche planifiée crée une archive des fichiers et de la base de données ;
• la nouvelle archive remplace ou complète les précédentes ;
• les anciennes copies sont supprimées lorsqu’elles dépassent la durée de rétention prévue ;
• un administrateur, un script ou un compte disposant des droits nécessaires peut habituellement supprimer les archives avant cette échéance.

Cette approche reste utile et très répandue. Elle protège contre une mise à jour défectueuse, une erreur de manipulation, la suppression d’un article ou un problème de serveur. En revanche, elle n’offre pas nécessairement de défense robuste contre un acteur qui a obtenu l’accès au compte d’hébergement, au tableau de bord de sauvegarde ou à la clé API du stockage distant.

Il est important de distinguer trois notions proches, mais différentes :

• La fréquence : une copie est créée toutes les heures, tous les jours ou toutes les semaines.
• La rétention : les copies sont conservées pendant un nombre de jours, de semaines ou de mois.
• L’immuabilité : les copies sont techniquement verrouillées jusqu’à la fin de la durée fixée.

Un hébergeur peut proposer des sauvegardes quotidiennes conservées pendant plusieurs jours sans fournir d’immuabilité. Inversement, une copie immuable peu fréquente ne remplacera pas une politique de sauvegarde adaptée au rythme de publication et aux transactions du site. Les trois paramètres doivent être examinés ensemble.

Pourquoi les ransomwares ciblent aussi les copies WordPress

Un ransomware cherche à rendre les données indisponibles afin d’exiger un paiement. Sur un site WordPress, l’attaque peut prendre plusieurs formes : chiffrement ou suppression de fichiers, altération de la base MySQL ou MariaDB, création de comptes administrateurs, déploiement d’un logiciel malveillant, ou effacement de contenus.

Les sauvegardes constituent alors la principale porte de sortie. C’est précisément pourquoi elles peuvent être visées. Si un attaquant compromet le compte principal de l’hébergement et que ce compte peut gérer les sauvegardes, il peut tenter de les supprimer avant que le propriétaire ne réagisse.

Le risque ne se limite pas à l’hébergeur. Un plugin de sauvegarde WordPress configuré avec des identifiants trop puissants peut aussi devenir un point de faiblesse. Par exemple, si une extension envoie des archives vers un stockage objet et dispose d’une clé autorisant à lister, écrire et supprimer tous les fichiers du compartiment, une compromission de WordPress peut exposer à la fois le site et ses copies distantes.

Dans une installation WordPress, les éléments à préserver sont notamment :

• la base de données contenant les contenus, comptes, réglages et commandes WooCommerce ;
• le répertoire wp-content/uploads, qui contient généralement les médias ;
• les extensions et thèmes nécessaires à la reconstruction de l’environnement ;
• le fichier wp-config.php, à manipuler avec prudence car il contient des secrets ;
• les configurations externes éventuelles : DNS, règles CDN, paramètres de messagerie ou variables d’environnement.

Une archive contenant uniquement les fichiers du site ne suffit donc pas toujours. Sans base de données récente, un site peut être restauré visuellement tout en perdant des commandes, des commentaires, des utilisateurs ou des contenus publiés depuis la dernière exportation.

Une sauvegarde qui peut être effacée par le même accès que celui utilisé pour administrer le site doit être considérée comme exposée à une compromission de cet accès.

Les sauvegardes immuables ne remplacent pas les mesures préventives : mises à jour, mots de passe uniques, authentification multifacteur, limitation des comptes administrateurs, journalisation et protection contre les extensions vulnérables restent indispensables. Elles constituent une dernière ligne de défense, conçue pour permettre une restauration même lorsque la prévention a échoué.

Ce qu’un hébergeur doit préciser sur l’immuabilité

Le mot « sauvegarde » dans une grille tarifaire ne donne pas assez d’informations. Un hébergeur sérieux doit pouvoir décrire son fonctionnement de manière compréhensible : fréquence, durée de conservation, périmètre sauvegardé, emplacement des copies et procédure de restauration.

Pour l’immuabilité, cherchez une formulation explicite. Les termes suivants peuvent indiquer une protection pertinente, à condition d’être documentés :

• stockage immuable ;
• WORM ;
• verrouillage de rétention ;
• Object Lock ;
• copies non modifiables pendant une période définie ;
• coffre de sauvegarde isolé ou backup vault.

À l’inverse, des expressions comme « sauvegardes automatiques », « snapshots », « restauration en un clic » ou « conservation de 30 jours » ne prouvent pas, à elles seules, l’immuabilité. Elles décrivent des services utiles, mais ne répondent pas directement à la question : qui peut supprimer la copie et dans quelles conditions ?

Demandez aussi si l’hébergeur distingue les sauvegardes opérationnelles, conçues pour les restaurations rapides, et les copies protégées destinées à survivre à un incident majeur. Une politique associant les deux est souvent plus cohérente qu’une unique couche de sauvegarde.

Enfin, vérifiez les conditions du service. Certains hébergeurs précisent que leurs sauvegardes sont une facilité et recommandent au client de conserver ses propres copies. Cette clause ne rend pas leur offre inutile ; elle rappelle simplement qu’un plan de continuité ne devrait pas dépendre d’un seul prestataire.

Les critères à contrôler : rétention, isolation et restauration

Une rétention cohérente avec l’activité du site

La durée de rétention détermine jusqu’à quand vous pourrez revenir en arrière. Pour un site vitrine qui change peu, des sauvegardes quotidiennes peuvent être suffisantes. Pour une boutique WooCommerce, un site de réservation ou une plateforme éditoriale active, il faut réfléchir à la fréquence des données critiques.

Un point de restauration vieux de plusieurs jours peut ne pas contenir les commandes récentes. Dans ce contexte, il peut être nécessaire de compléter les sauvegardes de fichiers par des exports plus fréquents de la base de données ou par des mécanismes adaptés à l’application utilisée.

Contrôlez en particulier :

• la fréquence réelle des sauvegardes incluses ;
• le nombre de points de restauration disponibles ;
• la durée de conservation annoncée ;
• la possibilité de conserver une copie mensuelle ou annuelle plus longtemps ;
• la durée exacte pendant laquelle une copie est verrouillée ;
• les éventuels frais liés à une conservation étendue.

Une isolation qui résiste à la compromission

L’isolation est le second critère essentiel. Une copie stockée sur le même serveur que WordPress peut accélérer une restauration après une erreur mineure, mais elle reste vulnérable à un incident affectant ce serveur, son stockage ou son compte d’administration.

Une architecture plus robuste sépare les environnements. Cela peut vouloir dire :

• un stockage de sauvegarde distinct de l’espace d’hébergement ;
• des identifiants différents de ceux du compte WordPress ou du panneau d’hébergement ;
• des droits limités pour l’outil qui envoie les archives ;
• une région, un fournisseur ou au minimum un domaine de défaillance distinct ;
• une protection d’accès renforcée, notamment avec l’authentification multifacteur lorsqu’elle est disponible.

Si vous utilisez un stockage objet personnel chez AWS, Backblaze B2, Cloudflare R2 ou un autre fournisseur compatible avec votre outil de sauvegarde, examinez précisément les permissions attribuées à la clé d’accès. Le principe du moindre privilège est préférable : l’outil de sauvegarde ne devrait recevoir que les autorisations strictement nécessaires.

Attention : la mise en place d’un verrouillage de rétention demande une préparation rigoureuse. Avec certains modes de conformité, un objet peut rester impossible à supprimer jusqu’à la date fixée, y compris pour des administrateurs. Il faut donc choisir la durée et les règles de cycle de vie avec soin afin d’éviter une hausse imprévue des coûts de stockage ou la conservation excessive de données sensibles.

Une restauration réellement praticable

La meilleure copie de sauvegarde ne sert à rien si personne ne sait l’utiliser sous pression. Avant de souscrire une offre ou de déléguer entièrement cette fonction à un hébergeur, vérifiez le processus de restauration.

Les bonnes questions à poser sont les suivantes :

• Peut-on restaurer les fichiers et la base de données séparément ?
• Peut-on télécharger une copie hors de la plateforme ?
• La restauration écrase-t-elle automatiquement le site existant ?
• Est-il possible de restaurer d’abord sur un environnement de préproduction ?
• Quel est le délai habituel de disponibilité d’une copie ?
• Le support peut-il assister une restauration en cas d’incident ?
• Les journaux permettent-ils d’identifier la date d’une suppression ou d’une modification suspecte ?

La restauration sur un environnement isolé est particulièrement utile après une compromission. Restaurer immédiatement en production une archive infectée, ou remettre en ligne un site avec la même faille et les mêmes identifiants compromis, peut réintroduire le problème.

Le sujet de la restauration s’inscrit aussi dans une démarche plus globale de disponibilité. Retrouvez nos recommandations pour migrer WordPress sans interruption de service et pour vérifier les points essentiels avant de choisir un hébergement WordPress.

Mettre en place une stratégie 3-2-1 adaptée à WordPress

La règle 3-2-1 est un cadre simple pour réduire le risque de perte de données :

• conserver au moins trois copies des données ;
• utiliser au moins deux types de supports ou environnements de stockage ;
• garder au moins une copie hors site.

Dans un contexte WordPress, une adaptation pragmatique peut ressembler à ceci :

• Copie 1 : le site de production, comprenant les fichiers et la base de données.
• Copie 2 : les sauvegardes automatiques de l’hébergeur, utiles pour les restaurations rapides.
• Copie 3 : une sauvegarde externe, placée dans un stockage distinct et protégée par une politique d’immuabilité lorsque cela est possible.

Le second support n’a pas obligatoirement besoin d’être physique. Dans le cloud, l’objectif est surtout d’éviter qu’une erreur, un incident de sécurité ou une suppression réalisée dans un seul environnement fasse disparaître toutes les copies simultanément.

Un exemple concret : un site WordPress peut s’appuyer sur les sauvegardes quotidiennes intégrées à son hébergement, tout en envoyant des archives chiffrées vers un compartiment de stockage objet dédié. L’outil utilisé peut être une extension de sauvegarde reconnue comme UpdraftPlus, BlogVault ou Jetpack Backup, selon les besoins et la compatibilité de l’environnement. La partie stockage doit ensuite être configurée avec une politique de rétention adaptée, et les accès doivent être séparés du compte WordPress.

Cette organisation n’exonère pas d’un suivi. Les tâches planifiées peuvent échouer, le volume de données peut dépasser un quota, une clé API peut expirer ou une mise à jour d’extension peut modifier le comportement d’un export. Consultez régulièrement les rapports de sauvegarde et conservez une alerte en cas d’échec.

Tester les sauvegardes sans mettre le site en danger

Une sauvegarde n’est validée qu’après une restauration réussie. Le test doit idéalement être réalisé dans un environnement distinct : sous-domaine de préproduction, installation locale ou espace de test fourni par l’hébergeur.

Une procédure de test raisonnable consiste à :

• choisir un point de restauration récent, puis un point plus ancien ;
• restaurer les fichiers et la base dans un environnement isolé ;
• vérifier l’accès à l’administration WordPress ;
• contrôler les médias, les formulaires, les pages principales et les extensions critiques ;
• pour WooCommerce, vérifier les commandes, comptes clients, produits et paramètres de paiement sans effectuer de transaction réelle ;
• mesurer le temps nécessaire à la remise en état ;
• documenter les étapes, les accès et les difficultés rencontrées.

Ce test permet aussi de déterminer votre capacité de reprise. Deux indicateurs sont souvent utilisés dans les plans de continuité : le délai maximal acceptable pour remettre le service en route et la quantité maximale de données que l’on peut accepter de perdre. Sans forcément formaliser ces notions pour un petit site, il est utile de répondre à deux questions concrètes : combien de temps le site peut-il rester indisponible, et jusqu’à quelle heure ou quelle date les données doivent-elles être restaurées ?

Après une attaque, ne vous contentez pas de restaurer. Changez les mots de passe, révoquez les clés API suspectes, examinez les comptes administrateurs WordPress, mettez à jour le cœur, les thèmes et les extensions, puis recherchez l’origine de l’intrusion. Notre guide sur les erreurs fréquentes liées à l’hébergement WordPress peut également aider à revoir certains fondamentaux techniques.

Questions à poser avant de choisir son hébergeur WordPress

Avant de vous engager, sollicitez le support commercial ou technique avec des questions précises. Les réponses vagues sont un signal à prendre au sérieux, surtout si votre activité dépend directement du site.

• Les sauvegardes sont-elles immuables ? Si oui, quel mécanisme technique est utilisé ?
• Quelle est la durée de verrouillage des copies ?
• Un administrateur du compte client peut-il supprimer les sauvegardes avant la fin de cette période ?
• Les sauvegardes sont-elles stockées sur une infrastructure séparée du serveur de production ?
• Quels éléments sont sauvegardés : fichiers, base de données, emails, configurations ?
• Quelle est la fréquence des sauvegardes et combien de points de restauration sont disponibles ?
• Comment se déroule une restauration complète et peut-elle être testée en préproduction ?
• Quelles sont les responsabilités respectives de l’hébergeur et du client ?
• Peut-on exporter les sauvegardes vers un stockage externe contrôlé par le client ?

Ces éléments doivent être mis en regard des autres critères de sélection : version de PHP, performances du stockage, qualité du support, localisation des données, sécurité du compte, environnement de staging et politique de mises à jour. Pour une vision plus large, consultez notre dossier hébergement WordPress managé ou mutualisé.

Conclusion : une protection à vérifier, pas une promesse à supposer

Les sauvegardes immuables constituent un atout majeur dans une stratégie de sécurité WordPress, car elles limitent la capacité d’un ransomware ou d’un compte compromis à détruire les copies de secours. Elles n’éliminent pas tous les risques, mais elles renforcent considérablement les chances de restaurer un site dans un état sain.

Ne vous fiez donc pas uniquement à la mention « sauvegardes incluses ». Vérifiez la rétention, l’isolation, les droits de suppression et la procédure de restauration. Associez les sauvegardes de votre hébergeur à une copie externe, testée régulièrement, dans le cadre d’une stratégie 3-2-1 proportionnée à votre activité. Au moment de comparer les offres WordPress, faites de cette exigence un critère concret : votre capacité à repartir après un incident en dépend.