Sauvegardes Drupal : le guide complet

La sauvegarde est l'assurance que personne ne regarde jusqu'au jour où tout brûle. Un site Drupal en production accumule de la valeur en continu : contenu éditorial, comptes utilisateurs, commandes, configuration affinée au fil des mois. Le jour où une mise à jour tourne mal, où un serveur lâche ou où une erreur humaine efface une section entière du site, la seule question qui compte est : est-ce qu'on peut restaurer, et en combien de temps ? Une stratégie de sauvegarde sérieuse répond à cette question avant qu'elle ne se pose.

La bonne nouvelle, c'est qu'une stratégie de sauvegarde robuste pour Drupal repose sur des principes simples et des outils éprouvés. Pas besoin d'une infrastructure complexe ni d'un budget démesuré. Ce qui fait la différence, ce n'est pas la sophistication du dispositif, c'est sa régularité, sa couverture complète et surtout le fait de l'avoir testé. Ce guide explique quoi sauvegarder exactement sur un site Drupal, à quelle fréquence, avec quels outils, où stocker les copies et comment vérifier qu'elles fonctionnent vraiment.

Quoi sauvegarder sur un site Drupal

Une erreur fréquente consiste à sauvegarder uniquement la base de données et à croire le site protégé. Un site Drupal est composé de plusieurs couches distinctes, et une sauvegarde incomplète donne une fausse impression de sécurité. Voici les quatre éléments à couvrir.

La base de données. C'est le cœur du site : contenu, utilisateurs, taxonomie, états des modules et dans certains cas une partie de la configuration. C'est l'élément le plus volatil et le plus critique. Une base perdue, c'est tout le contenu éditorial et toutes les données métier qui disparaissent. C'est la priorité absolue de toute stratégie de sauvegarde.

Les fichiers publics. Le répertoire sites/default/files contient les images, les documents PDF, les pièces jointes et tous les médias téléversés par les éditeurs. Ces fichiers ne sont pas dans la base de données : la base ne stocke que des références vers eux. Sauvegarder la base sans les fichiers, c'est restaurer un site dont toutes les images sont cassées.

Les fichiers privés. Si votre site utilise un répertoire de fichiers privés (factures, documents réservés aux membres, exports), il se trouve généralement hors de la racine web, à un emplacement défini dans settings.php. Il est facile à oublier précisément parce qu'il est séparé. Il mérite pourtant la même attention que les fichiers publics, souvent davantage vu la sensibilité des données qu'il contient.

La configuration. Depuis Drupal 8, la configuration (types de contenu, vues, champs, réglages) s'exporte dans des fichiers YAML versionnables. Si votre configuration est gérée en code et suivie dans Git, elle est déjà sauvegardée par votre dépôt. Sinon, elle vit uniquement en base de données et doit être traitée comme telle. La configuration sync est l'un des grands acquis de Drupal moderne et il serait dommage de ne pas en profiter.

À cela s'ajoute le code : core, modules contrib, modules custom et thèmes. Idéalement, ce code est géré par Composer et versionné dans Git, ce qui constitue déjà une forme de sauvegarde. Le composer.lock permet de reconstruire à l'identique les dépendances. Un site dont le code n'est pas dans Git présente un risque qu'un audit Drupal met en lumière dès les premières heures d'analyse.

La fréquence recommandée

La fréquence de sauvegarde dépend d'une question simple : combien de données pouvez-vous vous permettre de perdre ? Ce seuil porte un nom, l'objectif de point de récupération (RPO). Si votre site publie du contenu plusieurs fois par jour ou enregistre des transactions, une sauvegarde quotidienne laisse une fenêtre de perte trop large.

Pour la base de données, le rythme dépend de l'activité. Un site éditorial actif ou une boutique justifie une sauvegarde quotidienne au minimum, voire toutes les quelques heures pour les sites à fort volume de transactions. Un site institutionnel qui change peu peut se contenter d'un rythme quotidien sans difficulté. La base étant l'élément le plus volatil, c'est sur elle que la fréquence doit être la plus soutenue.

Pour les fichiers, le rythme peut être plus espacé puisqu'ils changent moins souvent que la base. Une sauvegarde quotidienne incrémentale est un bon compromis : seuls les fichiers nouveaux ou modifiés sont copiés, ce qui réduit considérablement le volume transféré et la durée de l'opération.

La rétention compte autant que la fréquence. Garder uniquement la dernière sauvegarde est risqué : si une corruption passe inaperçue pendant quelques jours, votre seule copie est déjà corrompue. Une politique de rétention raisonnable conserve par exemple les sauvegardes quotidiennes des sept derniers jours, hebdomadaires du dernier mois et mensuelles sur près d'un an. Cette dégressivité protège contre les incidents découverts tardivement sans faire exploser le coût de stockage.

Les outils pour sauvegarder Drupal

L'écosystème Drupal et les outils système offrent plusieurs approches, du module installable au script automatisé. Le bon choix dépend de votre niveau d'accès au serveur et de votre degré d'automatisation souhaité.

Backup and Migrate. Ce module historique de la communauté permet de sauvegarder base de données et fichiers depuis l'interface d'administration, avec planification et envoi vers des destinations externes. Il convient bien aux équipes qui n'ont pas d'accès serveur ou qui veulent une solution autonome dans Drupal. Sa limite : il s'exécute dans le contexte PHP du site, ce qui le rend moins adapté aux très grosses bases.

Drush. Pour les équipes ayant un accès en ligne de commande, Drush est l'outil de référence. Un export de base de données est aussi simple que cela :

# Exporter la base de données, compressée et horodatée
drush sql-dump --gzip --result-file=/backups/db/site-$(date +%Y%m%d-%H%M).sql

# Exporter la configuration vers le répertoire sync
drush config:export --yes

Drush s'intègre naturellement à un script et à une tâche cron, ce qui en fait la base de la plupart des dispositifs automatisés.

Scripts custom. Un script shell orchestré par cron reste la solution la plus flexible. Il enchaîne le dump de la base, la copie incrémentale des fichiers et l'envoi vers un stockage distant. Pour les fichiers, rsync est l'outil naturel :

# Synchronisation incrémentale des fichiers publics vers un stockage distant
rsync -az --delete /var/www/site/web/sites/default/files/ \
  backup@offsite-host:/backups/site/files/

Snapshots d'infrastructure. La plupart des hébergeurs proposent des snapshots de serveur ou de volume. Pratiques pour une restauration complète rapide, ils ne remplacent pas une sauvegarde applicative : un snapshot ne permet pas de restaurer un seul type de contenu ou de récupérer une base saine antérieure à une corruption. Les deux approches sont complémentaires, pas concurrentes.

Le stockage offsite et la règle 3-2-1

Une sauvegarde stockée sur le même serveur que le site ne protège que d'un cas : l'erreur applicative. Elle ne protège ni de la panne matérielle, ni de la compromission du serveur, ni du sinistre physique du datacenter. C'est pourquoi le stockage hors site (offsite) n'est pas une option mais une exigence de base.

La référence du domaine est la règle 3-2-1, simple à retenir et redoutablement efficace :

• 3 copies de vos données (l'originale et deux sauvegardes).
• 2 supports de stockage différents (par exemple un disque local et un stockage objet).
• 1 copie hors site, physiquement éloignée de la production.

Concrètement, cela peut prendre la forme d'une copie sur le serveur pour la restauration rapide, d'une copie sur un stockage objet (S3, Backblaze B2, OVH Object Storage ou équivalent) et d'une copie dans une région géographique distincte. Chiffrer les sauvegardes au repos est fortement recommandé, surtout dès qu'elles contiennent des données personnelles, ce qui place aussi la question dans le périmètre du RGPD. Le stockage objet rend cette approche accessible : l'archivage longue durée y est économique et l'envoi s'automatise facilement depuis un script ou depuis Backup and Migrate.

Tester ses restaurations : l'étape que tout le monde saute

Voici le principe le plus important de ce guide : une sauvegarde qui n'a jamais été testée ne fonctionne probablement pas. C'est une affirmation volontairement provocante, mais elle reflète une réalité observée sur le terrain. Les dumps incomplets, les archives corrompues, les fichiers manquants et les procédures qui se révèlent inapplicables le jour J sont d'une fréquence déconcertante. La sauvegarde n'est pas le but, la restauration l'est.

Tester, c'est restaurer pour de vrai. Le test consiste à prendre une sauvegarde et à la restaurer sur un environnement isolé (un environnement de staging ou un conteneur jetable), puis à vérifier que le site fonctionne : pages qui chargent, images présentes, connexion utilisateur opérationnelle, données métier intactes. Tant que cette opération n'a pas été faite, vous ne savez pas si votre sauvegarde vaut quelque chose.

Une restauration de base de données ressemble à ceci :

# Restaurer une base depuis un dump compressé vers un environnement de test
gunzip < /backups/db/site-20260818-0300.sql.gz | drush sql-cli

# Vider les caches après restauration
drush cache:rebuild

Mesurez votre temps de restauration. L'objectif de temps de récupération (RTO) est aussi important que le RPO. Savoir qu'on peut restaurer est une chose, savoir qu'on peut le faire en trente minutes plutôt qu'en huit heures en est une autre. Le test de restauration est le seul moyen de connaître ce chiffre avant l'incident.

Automatisez et planifiez le test. Le test de restauration gagne à devenir un rituel, mensuel ou trimestriel selon la criticité du site, plutôt qu'un exercice fait une fois puis oublié. Certaines équipes vont jusqu'à automatiser une restauration sur un environnement éphémère après chaque sauvegarde, ce qui valide la chaîne complète en continu. C'est l'équivalent, pour les sauvegardes, de ce qu'un pipeline de tests apporte au code.

Intégrer les sauvegardes à votre cycle de maintenance

Une stratégie de sauvegarde n'est pas un projet ponctuel qu'on installe et qu'on oublie. Elle vit avec le site : un nouveau répertoire de fichiers privés, une migration vers un nouvel hébergeur, l'ajout d'une fonctionnalité transactionnelle, chacun de ces changements peut rendre obsolète une procédure conçue six mois plus tôt. C'est précisément le rôle d'une maintenance suivie que de garder ce dispositif aligné avec la réalité du site.

C'est pourquoi la sauvegarde et la maintenance vont de pair. Avant chaque mise à jour majeure du core ou des modules, une sauvegarde fraîche et vérifiée transforme une opération stressante en manœuvre réversible : si quelque chose tourne mal, on restaure et on recommence. Nos forfaits de maintenance Drupal intègrent cette logique en plaçant une sauvegarde testée juste avant chaque cycle de mise à jour, ce qui sécurise l'ensemble du processus.

Si vous n'êtes pas certain de l'état de votre dispositif actuel, le point de départ logique est un diagnostic. Notre audit Drupal vérifie la couverture de vos sauvegardes, leur fréquence, leur stockage et surtout leur restaurabilité, puis propose un plan concret pour combler les écarts. Mieux vaut découvrir une faille pendant un audit que pendant un incident.

Vous voulez sécuriser durablement votre site Drupal avec une stratégie de sauvegarde testée et un cycle de maintenance fiable ? Parlons de votre projet.