Written for developers, consultants et responsables IT qui souhaitent garantir la continuité et la sécurité de leurs instances Dolibarr dans un contexte hybride (cloud / on‑premise, télétravail, points de vente multiples).
1. Introduction
Dolibarr est un ERP/CRM léger, très apprécié pour sa modularité et son code source ouvert. Dans les environnements hybrides, où les données sont réparties entre serveurs locaux, instances cloud et terminaux mobiles, la sauvegarde devient le pilier central de la résilience opérationnelle.
Cet article propose :
- Une méthode de diagnostic – comprendre où résident les risques de perte ou de corruption des données.
- Une checklist exhaustive de sauvegarde – pas à pas, adaptée aux équipes hybrides.
- Des bonnes pratiques pour automatiser, tester et sécuriser le processus.
2. Diagnostic de l’infrastructure Dolibarr hybride
| Étape | Questions clés | Points de contrôle |
|---|---|---|
| 2.1 Cartographie des déploiements | Où sont hébergées les instances (serveur dédié, VM, conteneur, PaaS) ? Quel niveau d’accès (API, UI) est exposé ? |
Diagramme d’architecture, accès SSH/HTTPS, usage de Docker/Kubernetes |
| 2.2 Classification des données | Quels modules utilisent des données sensibles (comptes clients, stocks, comptabilité) ? Quel volume est généré quotidiennement ? |
Table de mapping par module (inventory, invoicing, crm) |
| 2.3 Analyse des flux de synchronisation | Y a‑t‑il des réplications (CRM ↔ ERP, API tierces) ? Quel mécanisme de verrouillage ou de conflit résout-on ? |
Logs de synchronisation, webhooks, scripts ETL |
| 2.4 Évaluation de la redondance | Les services (DB, web server) sont‑ils redondants (load‑balancing, réplication) ? Quel SLA est attendu pour la disponibilité ? |
Configuration de RAID, clustering, services de secours |
| 2.5 Vérification des processus de backup existants | Quelle fréquence ? Quel type de sauvegarde (full, incrémentale, diff) ? Où sont stockés les fichiers (NAS, S3, Glacier) ? |
Scripts cron, jobs Airflow, services CI/CD |
Livrable du diagnostic : Rapport de cartographie avec un tableau récapitulatif des zones critiques (ex. “Base de données MySQL – 50 Mo/jour – stocké sur S3”).
3. Pourquoi une checklist de sauvegarde hybride ?
- Protection des données sensibles (RGPD, exigences comptables).
- Résilience face aux défaillances multi‑site (pannes de réseau, crash de serveur AWS, sinistre local).
- Coût maîtrisé : éviter les restaurations coûteuses après perte de transactions.
- Conformité : cadre de sauvegarde exigé par les audits internes et externes.
La checklist ci‑dessous est découpage en 3 phases : Pré‑ sauvegarde, Sauvegarde, Post‑ sauvegarde.
4. Checklist détaillée – Sauvegarde pour équipes hybrides
4.1 Phase 1 – Pré‑ sauvegarde
| # | Action | Description | Outils/Commandes |
|---|---|---|---|
| 1 | Inventaire des artefacts | Exporter la liste des fichiers (DB, fichiers uploadés, certificats) à sauvegarder. | find /var/www/dolibarr -type f -mtime -1 | sort > /tmp/dolibarr-files.txt |
| 2 | Snapshot de la base de données | Assurer une exportation cohérente (sans interruption du service). | mysqldump -u root -p dolibarr > /backup/mysql/dolibarr_$(date +%F).sql |
| 3 | Gestion des sessions | Bloquer les nouvelles transactions pendant le backup (ou activer le mode “read‑only”). | SET GLOBAL read_only = ON; (MySQL) |
| 4 | Vérifier les prérequis d’espace | S’assurer que le volume de destination possède la capacité requise + marge (≈ 20 %). | df -h /backup |
| 5 | Planifier les fenêtres d’activité | Définir les créneaux où l’impact sur les utilisateurs est acceptable (nuit, week‑end). | Calendrier partagé, déclencheur Cron (0 2 * * *) |
Output attendu : fichier
dolibarr_2025-11-03.tar.gzplacé dans le répertoire de sauvegarde temporaire.
4.2 Phase 2 – Sauvegarde
| # | Action | Détail | Méthode recommandée |
|---|---|---|---|
| 1 | Sauvegarde de base de données | Export complet (mysqldump/pg_dump) ou snapshot (Xtrabackup pour MySQL). |
xtrabackup --backup --target-dir=/backup/mysql/ |
| 2 | Sauvegarde des fichiers uploadés | Reculer le répertoire files/ (images, factures). |
tar -czf /backup/files/dolibarr_files_$(date +%F).tar.gz /var/www/dolibarr/files |
| 3 | Sauvegarde des configurations | Inclure conf/, .env, certificats TLS. |
cp -r /var/www/dolibarr/conf /backup/conf_$(date +%F) |
| 4 | Réplication vers stockage objet | Copie vers S3/MinIO/Backblaze B2 avec chiffrement en‑transit. | aws s3 sync /backup s3://my-dolibarr-backups/ --sse AES256 |
| 5 | Versionnage | Ajouter un checksum (SHA‑256) et un numéro de version. | sha256sum file.tar.gz >> /backup/manifest.txt |
| 6 | Rotation automatique | Configurer la suppression des sauvegardes < 30 jours ou limiter le nombre de versions. | find /backup -type f -mtime +30 -delete |
| 7 | Notation des logs | Enregistrer temps de traitement, taille, statut dans un tableau de suivi. | echo "$(date) - backup done - size=$(du -sh /backup) >> /var/log/dolibarr-backup.log" |
4.3 Phase 3 – Post‑ sauvegarde
| # | Action | Objectif | Outils/Commandes |
|---|---|---|---|
| 1 | Test de restauration (DR test) | Vérifier la validité de la sauvegarde (intégrité du fichier, restauration DB). | mysql dolibarr_test < /backup/mysql/dolibarr_2025-11-03.sql |
| 2 | Indexation & archivage | Mettre les sauvegardes anciennes dans un glacier (coût minimal). | aws s3 copy --storage-class GLACIER |
| 3 | Alerting | Notifier les équipes (Slack, Email, PagerDuty) si le backup échoue ou dépasse les seuils (taille > plafond). | monit alert filevarname=/backup/logs/*.log |
| 4 | Documentation | Mettre à jour le Playbook/Runbook avec le nouveau cycle de sauvegarde. | git add backup_2025-11-03.yml && git commit -m "Backup run 2025‑11‑03" |
| 5 | Cleanup | Supprimer les sauvegardes temporaires pour libérer l’espace disque. | rm -rf /tmp/dolibarr-files.txt |
| 6 | Audit de sécurité | Vérifier que les accès aux fichiers backup sont limités (principes du moindre privilège). | chmod 600 /backup/*.sql && chown root:backupgroup |
5. Automatisation & Orchestration (exemple de pipeline)
# Exemple de GitLab CI / GitHub Actions pour un backup quotidien
stages:
- pre_backup
- backup - post_backup
- purgebackup-db:
stage: backup
image: mariadb:10.11 script:
- mysqldump -h $DB_HOST -u $DB_USER -p$DB_PASS dolibarr > backup/dump_$CI_COMMIT_SHORT_SHA.sql
- aws s3 cp backup/dump_$CI_COMMIT_SHORT_SHA.sql s3://my-dolibarr-backups/${CI_COMMIT_SHORT_SHA}.sql.gz --sse AES256
only:
- schedules # déclenché quotidiennement via cron dans GitLab UI
backup-files:
stage: backup
image: alpine:latest script:
- apk add --no-cache tar
- tar -czvf backup/files_$CI_COMMIT_SHORT_SHA.tar.gz /var/www/dolibarr/files - aws s3 sync backup/ s3://my-dolibarr-backups/ --sse AES256
only:
- schedulesTip : Enchaînez les jobs avec des politiques de rétention (
--retention-period 30) directement dans les services S3/ Glacier pour éviter les scripts de nettoyage manuel.
6. Validation et chiffrement
| Action | Pourquoi | Implémentation |
|---|---|---|
| Chiffrement en‑repos | Empêcher la fuite de données via accès non autorisé au stockage. | openssl enc -aes-256-cbc -salt -in file.tar.gz -out file.tar.gz.enc |
| Signature numérique | Garantir l’intégrité d’un fichier (détection de corruption). | gpg --verify file.tar.gz.asc file.tar.gz |
| Contrôle d’accès | Limiter les droits aux seules équipes IT/Sécurité. | IAMolicies S3, ACL POSIX chmod 750 et groupes Linux backup. |
| Audit of logs | Retracer qui a déclenché le backup et quand. | auditd (Linux) ou CloudTrail (AWS) avec retenue de 90 jours. |
7. Scénarios de reprise après sinistre (DR)
| Scénario | Étapes de restauration | Temps moyen (RTO) | Point de restauration (RPO) |
|---|---|---|---|
| Coupure réseau locale | 1️⃣ Recharger la dernière sauvegarde S3. 2️⃣ Restaurer DB et files/.3️⃣ Redémarrer services. |
15 min | < 4 h |
| Panne complète datacenter on‑premise | 1️⃣ Provisionner une nouvelle VM dans le Cloud. 2️⃣ Importer le dernier dump MySQL. 3️⃣ Synchroniser les fichiers depuis le bucket S3. 4️⃣ Configurer le reverse‑proxy. |
1 h | < 6 h |
| Corruption de la base de données | 1️⃣ Choisir un point‑in‑time (ex. 2 jours avant). 2️⃣ Appliquer les incrémentaux. 3️⃣ Valider les contraintes FK et les contrats. |
30 min | ≤ 24 h |
| Ransomware détecté | 1️⃣ Isoler les systèmes. 2️⃣ Restaurer à partir du dernier snapshot “clean”. 3️⃣ Re‑ouvrir les contrôles d’accès (MFA, double‑auth). |
2 h | < 12 h |
Conseil : Mettre en place un plan de test DR annuel (ou semestriel) pour valider les RTO/RPO réellement atteignables.
8. Bonnes pratiques résumées
| ✅ | Pratique | Impact |
|---|---|---|
| 1 | Sauvegardes complètes + incrémentales | Réduit le coût de stockage tout en conservant la récupération point‑in‑time. |
| 2 | Chiffrement & signature | Sécurité des données en transit et à repos. |
| 3 | Versionning et checksum | Détection immédiate des copies corrompues. |
| 4 | Tests de restauration réguliers | Évite les mauvaises surprises en production. |
| 5 | Automatisation via CI/CD ou Cron | Supprime le facteur humain d’erreur. |
| 6 | Documentation vivante | Facilite la transmission de connaissances entre équipes hybrides. |
| 7 | Monitoring & alerting | Réaction pro‑active aux échecs de backup. |
| 8 | Gestion des quotas | Empêche les surprises de facturation S3/GLACIER. |
| 9 | Rotation des clés de chiffrement | Renouvelle la sécurité sans perdre la rétro‑compatibilité. |
| 10 | Documentation de la DR | Réduit le temps de récupération lors d’un incident majeur. |
9. Conclusion Dans un environnement hybride, la sauvegarde de Dolibarr ne peut plus être un simple fichier copié sur un disque externe. Elle doit être planifiée, automatisée, sécurisée et validée comme un service à part entière. La checklist présentée couvre l’ensemble du cycle – de l’inventaire initial à la restauration après sinistre – en intégrant les exigences de sécurité, de conformité et de coût.
En suivant ce processus, les équipes hybrides :
- Garantissent la continuité d’activité même en cas de perte d’un site.
- Respectent les normes de protection des données (RGPD, ISO 27001). – Optimisent leurs dépenses de stockage tout en conservant un niveau de récupération élevé.
Adoptez la checklist dès aujourd’hui, testez‑la régulièrement, puis intégrez‑la dans votre framework de gestion de la continuité d’activité (BCP). Vous disposerez ainsi d’une base solide pour protéger efficacement vos données Dolibarr, où que vos serveurs soient hébergés.
À votre disposition pour enrichir ce cadre avec des scripts spécifiques à votre stack (Docker‑Compose, Kubernetes, Azure DevOps, etc.). —
Sources :
- Documentation officielle Dolibarr – Backup & Restore (https://dolibarr.org).
- AWS Well‑Architected Framework – Data Protection (2023).
- ISO/IEC 27001 – Annex A.12.3 Backup.
- Meilleures pratiques : The 3‑2‑1 backup rule (Vitalik, 2022).