Backups Drupal : stratégie, automatisation et restauration testée (guide 2026)
Un site Drupal, ce n’est pas « juste des fichiers ». C’est un ensemble cohérent : base de données, fichiers uploadés, configuration et code. Une bonne stratégie de sauvegardes sert à une seule chose : remettre en ligne vite et sans surprise quand ça casse (mauvaise mise à jour, suppression, incident serveur, ransomware, erreur humaine).
Dans ce guide, on voit quoi sauvegarder, comment automatiser, et surtout comment tester la restauration (le seul vrai indicateur de fiabilité).
Déployer Drupal sur adgents.cloud
1) Ce qu’il faut sauvegarder pour restaurer Drupal
Pour pouvoir reconstruire un Drupal proprement, il faut séparer ce qui est reproductible de ce qui est irremplaçable.
Base de données (irremplaçable)
La base contient l’essentiel : contenus, utilisateurs, menus, formulaires, logs applicatifs, etc. Sans elle, même avec le code, votre site n’a plus de “mémoire”.
Conseil : gardez des dumps compressés (gzip) et versionnés dans le temps (rétention), et planifiez au moins un test de restauration régulier.
Pour aller plus loin côté maintenance Drupal : Drupal en production : sécurité (updates, modules, WAF).
Fichiers (irremplaçables)
Dans Drupal, les médias et documents sont généralement dans :
public://(images, PDF, uploads)private://(si vous l’utilisez pour des documents non publics)
Si vous restaurez la base sans les fichiers, vous aurez des pages « OK » mais des médias manquants.
Configuration (reproductible mais indispensable)
La configuration (vues, types de contenu, champs, permissions…) est souvent exportée via un répertoire de synchro (ex : config/sync).
Bon réflexe : mettre l’export de config dans Git (et traiter les secrets séparément via variables d’environnement).
Code (reproductible)
Le code applicatif doit être reproductible : dépôt Git + composer.lock (et idéalement composer.json).
Si votre code est correctement versionné, le backup “code” devient surtout un filet de sécurité, mais pas l’élément principal.
Pour un déploiement Docker propre : Installer Drupal avec Docker Compose (prod).
2) Définir vos objectifs : RPO et RTO
Avant de choisir une fréquence, posez 2 questions simples :
- RPO : quelle perte de données maximale est acceptable ? (ex : 1 heure)
- RTO : en combien de temps le site doit revenir ? (ex : 30 minutes)
Exemples :
- Site vitrine : RPO 24h, RTO 4h
- Site e-commerce / lead-gen : RPO 1h, RTO 1h
- Intranet critique : RPO 15 min, RTO 30 min
Ces objectifs vont piloter la fréquence, la rétention et l’effort de tests.
3) Une stratégie simple et robuste (3-2-1) pour Drupal
Une stratégie classique, efficace et facile à expliquer à toute l’équipe :
- 3 copies de vos données (au moins)
- 2 supports différents (ex : stockage local + object storage)
- 1 copie hors site (off-site)
Pour une version plus “anti-ransomware”, on ajoute une copie immuable ou “offline” selon votre contexte.
Vidéo (FR) sur la règle 3-2-1-1-0 : 
4) Automatiser les sauvegardes (sans bloquer votre prod)
Vous avez 2 approches complémentaires :
Approche A — Backups “plateforme” (recommandé)
Si votre hébergeur propose des sauvegardes automatiques avec restauration simple, c’est souvent le meilleur compromis (moins de scripts, moins de dette, moins d’angles morts).
Sur adgents.cloud, vous pouvez activer des backups automatiques (jusqu’à 1/h), gérer une rétention longue et restaurer rapidement en cas d’incident : Hébergement Drupal sur adgents.cloud.
Approche B — Backups “applicatifs” (utile en complément)
Idéal si vous voulez une sauvegarde portable (migration) ou une granularité plus fine.
Quelques commandes utiles :
- Dump de base de données (exemple Drush) :
drush sql:dump --gzip --result-file=backup.sql
- Archive tout-en-un (code + fichiers + DB) (Drush) :
drush archive:dump --destination=/backups/drupal-archive.tar.gz --overwrite
Pensez à :
- chiffrer si vous exportez hors infrastructure
- surveiller les échecs (alerting)
- éviter que les backups remplissent le disque (rotation)
5) Tester la restauration : le “runbook” minimal
Une sauvegarde non testée n’a pas de valeur opérationnelle.
Le minimum une fois par mois (ou après un changement majeur) : restauration sur un environnement isolé (staging) et validation rapide.
Checklist de validation (rapide)
- Connexion admin OK
- Pages clés OK (homepage, page de contenu)
- Médias OK (images/PDF présents)
- Création d’un contenu test OK
- Tâches planifiées OK (cron)
Mesurez et consignez :
- votre RTO réel (combien de minutes)
- votre RPO réel (date/heure du dernier backup restauré)
Si le RTO/RPO est trop mauvais, ce n’est pas “la faute du hasard” : ajustez la fréquence, la méthode (snapshot vs dump), ou la procédure.
6) Bonnes pratiques qui évitent les mauvaises surprises
- Séparer secrets et sauvegardes : variables d’environnement, coffre-fort, rotation.
- Documenter la procédure : où sont les backups, qui a accès, comment restaurer.
- Avoir un environnement de staging : pour répéter les restaurations sans stress.
- Faire un backup avant chaque mise à jour (core, modules, thème).
Si vous voulez industrialiser votre hébergement Drupal (backups, rétention, restauration) sans complexifier vos scripts, le plus simple est de partir sur une plateforme gérée : Déployer Drupal sur adgents.cloud.
