La sauvegarde de votre ERP Dolibarr est une pierre angulaire de la sécurité informatique et de la continuité des activités. Une perte de données peut avoir des conséquences dramatiques : indisponibilité Opérationnelle, perte financière, atteinte à la réputation et non-conformité réglementaire (RGPD, etc.). Cet article détaille les méthodes de sauvegarde techniques disponibles et, surtout, vous propose une approche sécurité rigoureuse pour protéger vos sauvegardes.
1. Les Méthodes Techniques de Sauvegarde dans Dolibarr
Dolibarr ne propose pas d’API de sauvegarde dédiée et centralisée, mais plusieurs mécanismes existent :
-
Sauvegarde Manuelle par l’Interface Administrateur :
- Accès via
Accueil > Administration > Outils > Sauvegarde. - Permet de compresser et télécharger un fichier unique (
.sql+ fichiersdolibarr/) contenant la base de données et les documents. - Avantage : Simple, intégré.
- Inconvénient : Manuel, non automatisé, ne protège pas les fichiers en dehors du répertoire
documents/.
- Accès via
-
Sauvegarde Automatisée par Cron (Tâche Planifiée) :
- La méthode recommandée par la communauté et les experts.
- On utilise le script CLI (
dolibarr-cli.phpou scripts maison) pour invoquer les fonctions de sauvegarde via la ligne de commande. - Exemple de commande (à adapter) :
php /chemin/vers/dolibarr/htdocs/command.php --module=backup --action=save - Cette commande est alors planifiée via
crontab(Linux) ou le Planificateur de tâches (Windows) pour s’exécuter quotidiennement.
-
Utilisation de Modules/Plugins :
- Certains modules tiers (comme "Advanced Backup" ou "Backup Manager") offrent plus de flexibilité : sauvegarde distante (FTP/SFTP, cloud), rotation des archives, notifications.
- Prudence : Vérifiez la compatibilité avec votre version de Dolibarr et l’éditeur du module.
- Sauvegarde au Niveau du Serveur / Système de Fichiers :
- Base de données : Utiliser les outils natifs (ex:
mysqldump,pg_dump) pour Un dump de la base Dolibarr. - Fichiers : Sauvegarder l’intégralité du répertoire
dolibarr/htdocs/documents/(où sont stockés les fichiers uploadés, les logos, les contrats signés, etc.). - C’est souvent la méthode la plus fiable car elle capture tout, y compris les configurations serveur.
- Base de données : Utiliser les outils natifs (ex:
2. Approche Sécurité : Protéger la Sauvegarde Contre Toutes les Menaces
Une sauvegarde compromise ou inaccessible est aussi inutile qu’absence de sauvegarde. Voici le cadre de sécurité à appliquer.
A. Chiffrement (Confidentialité)
- Au repos : Le fichier de sauvegarde (
*.zipou*.tar.gz) doit être chiffré.- Utilisez des outils comme
openssl(AES-256),gpg, ou des logiciels spécialisés (VeraCrypt, Duplicati, BorgBackup). - Évitez de stocker des sauvegardes non chiffrées, surtout dans le cloud ou sur des supports externes.
- Utilisez des outils comme
- En transit : Les transferts vers un stockage distant (SSH/SFTP, HTTPS, cloud sécurisé) doivent utiliser des protocoles chiffrés (TLS/SSL). Jamais de FTP non sécurisé.
B. Stockage Hétérogène et Règle 3-2-1 (Intégrité & Disponibilité)
Appliquez la règle d’or : 3 copies de vos données, sur 2 supports différents, dont 1 copie hors-site.
- Copie 1 : Sur le serveur de production (pour une restauration rapide).
- Copie 2 : Sur un support local distinct (ex: NAS, disque dur externe connecté épisodiquement).
- Copie 3 : HORS-SITE (Cloud sécurisé type Wasabi, Backblaze B2, ou centre de données distant). C’est la copie qui survivra à un sinistre majeur ( incendie, ransomware généralisé, vol).
- Supports : Alternez au moins entre disque dur et bande magnétique (pour l’archivage long terme très sécurisé).
C. Contrôle d’Accès Stricte (Authentication & Authorization)
- Répertoire de sauvegarde : Doit être en dehors de la racine web (
htdocs/). Sinon, une faille web pourrait permettre le téléchargement direct.- Bonne pratique : Stocker les sauvegardes dans
/var/backups/dolibarr/(Linux) ou un dossier non accessible via HTTP.
- Bonne pratique : Stocker les sauvegardes dans
- Permissions système : Appliquez le principe du moindre privilège. Seul l’utilisateur système exécutant le cron (ex:
www-data) et les administrateurs sécurité doivent avoir accès en lecture/écriture. - Accès au stockage distant : Utilisez des clés d’accès (API Keys/Secrets) plutôt que des mots de passe simples. Stockez ces credentials dans un gestionnaire sécurisé (comme un vault) ou dans des fichiers avec permissions restreintes (
chmod 600).
D. Politique de Rétention et Rotations
- Ne pas conserver infiniment. Définissez une politique :
- 7 sauvegardes journalières.
- 4 sauvegardes hebdomadaires.
- 12 sauvegardes mensuelles.
- Archivage annuel (sur un support froid, ex: bande).
- Suppression sécurisée : Pour les supports réutilisés, assurez-vous que les anciennes données sont écrasées (outils de secure erase).
E. Surveillance, Alertes et Journalisation (Audit)
- Logs de sauvegarde : Conservez les logs de chaque exécution (succès/échec). Ils doivent être centralisés et protégés contre l’altération.
- Alertes automatisées : En cas d’échec d’une sauvegarde, une alerte (email, Slack, monitoring) doit être envoyée immédiatement aux responsables. Une sauvegarde qui échoue en silence est une menace.
- Journalisation des restaurations : Toute tentative de restauration (même réussie) doit être loguée. Cela permet de détecter des activités malveillantes.
F. Restauration et Test Régulier (Le Point le Plus Critique !)
- Une sauvegarde n’est valide que si on l’a restaurée avec succès.
- Plan de test : Mettez en place une procédure de test de restauration au moins trimestrielle.
- Restaurez sur un environnement de test/recette isolé (jamais sur la production sans validation préalable !).
- Vérifiez l’intégrité des données, le bon fonctionnement des modules, la cohérence des documents.
- Testez la restauration à partir de chaque type de sauvegarde (quotidienne, hebdomadaire, copie hors-site).
- Documentez la procédure de restauration pas-à-pas et gardez-la à jour.
3. Synthèse : Checklist Sécurité pour Votre Sauvegarde Dolibarr
| Action | Outil/Méthode | Importance |
|---|---|---|
| 🔒 Chiffrer l’archive de sauvegarde | OpenSSL, GPG, Duplicati (mode chiffré) | Critique |
| 📍 Stocker hors de la racine web | /var/backups/dolibarr/ |
Critique |
| 🌐 Appliquer la règle 3-2-1 | 1 local, 1 hors-site (cloud/autre site) | Critique |
| 🔑 Restreindre les accès (Permissions fichiers, Clés API) | chmod, groupes système, vaults |
Élevée |
| 🔔 Configurer des alertes sur échec de sauvegarde | Script d’envoi email, monitoring (Zabbix, etc.) | Élevée |
| 📅 Automatiser via Cron CLI | crontab -e avec commande Dolibarr CLI |
Élevée |
| 🧪 Tester la restauration en environnement isolé | Procédure écrite et testée trimestriellement | Critique |
| 📝 Documenter le plan de sauvegarde/restauration | Document interne, partagé avec les responsables | Élevée |
| 🔄 Appliquer une politique de rotation | Script de suppression anciennes sauvegardes | Moyenne |
Conclusion
Sauvegarder Dolibarr ne se résume pas à cliquer sur un bouton. C’est un processus de sécurité continu qui combine automatisation technique, chiffrement, diversification des supports et validation permanente par le test. En adoptant cette approche en couches ("défense en profondeur"), vous vous assurez que, en cas d’attaque par rançongiciel, de défaillance matérielle ou d’erreur humaine, votre entreprise pourra reprendre ses activités avec une confiance mesurée et une perte de données minimale.
Rappel final : Consultez toujours un expert en sécurité informatique pour auditer et adapter ces recommandations à votre infrastructure spécifique et à vos contraintes réglementaires. La sauvegarde est votre ultime file de sécurité, mérite-t-elle qu’on la néglige ?