Comment choisir, configurer et automatiser une sauvegarde hors‑site de votre instance Dolibarr afin d’optimiser votre productivité et votre sécurité.
1. Pourquoi le backup off‑site est-il indispensable pour Dolibarr ?
| Enjeu | Conséquence d’un défaut | Solution clé |
|---|---|---|
| Continuité d’activité | Une panne serveur ou un sinistre (incendie, inondation) peut rendre votre base de données et vos fichiers inaccessibles. | Sauvegarde hors du site : données répliquées sur un serveur distant ou un service cloud. |
| Protection contre la perte de données | Suppression accidentelle d’un module, d’un client ou d’une configuration. | Versionning + rétention multi‑point (hebdomadaire, quotidienne). |
| Conformité RGPD | Conservation des données personnelles pendant la durée légale requise. | Chiffrement en transit & au repos, région de stockage définie. |
| Temps de récupération (TR) | Redémarrage long, perte de transactions en cours. | RPO (Recovery Point Objective) très court → sauvegarde incrémentale fréquente. |
| Sécurité | Ransonware qui chiffre les fichiers locaux. | Copie indépendante, non accessible depuis le serveur Dolibarr. |
En résumé : un backup off‑site bien pensé réduit le RTO (Recovery Time Objective) et le RPO, tout en vous libérant d’une procédure de sauvegarde manuelle chronophage.
2. Les principales catégories de solutions off‑site
| Catégorie | Exemples | Points forts | Points faibles | Coût approximatif* |
|---|---|---|---|---|
| Stockage Cloud natif (S3‑compatible) | Amazon S3, Google Cloud Storage, Microsoft Azure Blob, Backblaze B2 | • Faible coût à la charge • Redondance géographique • Transfert incrémental natif |
• Latence réseau (sauvegarde initiale lente) • Nécessite configuration IAM/sécurité |
Gratuit jusqu’à 5 Go (AWS S3) → ~0,023 €/Go/mois après |
| Serveur de sauvegarde dédié (NAS/SAN partagé) | Synology Cloud Sync, QNAP Hybrid Backup, TrueNAS SCALE | • Contrôle total du hardware • Possibilité d’ajouter des disques SSD pour la rétention rapide |
• Investissement initial • Gestion d’un serveur supplémentaire |
300–800 € (unité NAS 2‑bay) + disques de capacité |
| Service Backup‑as‑a‑Service (BaaS) | CrashPlan, Backblaze Personal/B2, Duplicati Cloud, Rclone + VPS | • Installation minimale • Gestion automatisée des versions |
• Dépendance à un tiers • Certains fournisseurs limitent le nombre de versions |
CrashPlan : 6 €/mois par ordinateur ; Backblaze : 7 €/mois illimité |
| Script maison + Rclone/Syncthing | Rclone, Syncthing, BorgBackup, Restic | • 100 % open‑source, adaptable • Full control sur chiffrement/compression |
• Temps de développement • Pas de GUI « plug‑and‑play » |
Gratuit (hors temps d’administration) |
| Solutions intégrées à Dolibarr | Modules « Backup » du marketplace, extensions tierces | • Sauvegarde directement depuis l’interface • Fonctionnalités de journalisation des logs |
• Fonctionnalités limitées (pas de versionning avancé) • Dépend du module choisi |
Variable, souvent < 50 €/an |
*Coût donné à titre indicatif (au 1ᵉʳ trimestre 2025) ; les prix évoluent selon le volume et la localisation.
3. Analyse détaillée des options les plus pertinentes pour Dolibarr
3.1. Sauvegarde directe vers un bucket S3 (ou compatible) via S3‑CLI / rclone
| Atout | Détails |
|---|---|
| Compatibilité native | Dolibarr stocke tout dans le répertoire files/ (paiements, fichiers PDF, images, etc.) ainsi que la base MySQL/MariaDB. On peut scripté la synchronisation de ces dossiers + export SQL vers S3. |
| Sauvegarde incrémentale | rclone sync avec l’option --checksum ne copie que les blocs modifiés → très rapide après la première séance de backup. |
| Versionning intégré | Les services S3 ne versionnent pas les objets (hors config) ; on ajoute S3 Object Versioning dans le console AWS pour garder chaque version de chaque fichier. |
| Chiffrement | On peut utiliser le chiffrement côté client (rclone --crypt). |
| RPO ultra court | Planifier un cron toutes les 15 minutes (*/15 * * * * /usr/local/bin/backup-dolibarr.sh). |
| Coût | ~0,023 €/Go/mois + frais de transfert réseau (souvent négligeable pour les petites structures). |
Exemple de script (déployable sur un serveur Linux)
#!/usr/bin/env bash
# backup-dolibarr.sh
# 1. Export MySQL (Dolibarr utilise uniquement MySQL/MariaDB)
MYSQL_USER="doli"
MYSQL_PASS="******"
DB_NAME="dolibarr"
DATE=$(date +%Y%m%d-%H%M)
DUMP="/tmp/dolibarr-$DATE.sql.gz"
mysqldump -u"$MYSQL_USER" -p"$MYSQL_PASS" "$DB_NAME" | gzip > "$DUMP"
# 2. Compress & upload files & DB
BUCKET="s3://mon-bucket-backup/dolibarr"
FILE_DB="${BUCKET}/db/${DATE}.sql.gz"
FILE_FILES="${BUCKET}/files/${DATE}"
rclone copy /var/www/dolibarr/files "$BUCKET/files/$DATE" --progress
rclone copyto "$DUMP" "$FILE_DB" --progress
rclone copyto "/var/www/dolibarr/files" "$FILE_FILES" --progress # Si vous avez separate les fichiers
# 3. Purger les anciennes versions (ex: garder 30 jours)
rclone --max-age 30d delete "$BUCKET"- Planification :
crontab -e→*/15 * * * * /path/to/backup-dolibarr.sh >> /var/log/backup-dolibarr.log 2>&1 - Restauration : Copie du dump + réimport MySQL +
rclone syncdu répertoirefiles.
3.2. Backup via Synology Cloud Sync (ou QNAP Hybrid Backup)
| Pourquoi c’est pratique pour Dolibarr ? |
|---|
– Dolibarr commonement installé sur un serveur Apache/NGINX qui possède un répertoire files/. Synology peut monter ce dossier via CIFS/SMB et le sauvegarder automatiquement. |
| – L’interface graphique offre planification de tâches (quotidienne, incrémentale) sans script. |
| – Les snapshots Point‑in‑Time sont automatiques, vous pouvez monter un volume « read‑only » pour vérifier l’intégrité avant restauration. |
| – La restauration se fait en 1‑clic depuis le Cloud Sync Center. |
Points à vérifier : désactiver le mode « Sync » lorsqu’un fichier est créé dans le répertoire distant afin d’éviter une cascade de modifications infinie (Synology propose l’option « Ignore changes made on remote »).
3.3. Service BaaS – Backblaze Personal (ou B2) + rclone + compression BorgRep
| Pro | Contre |
|---|---|
| • Rétention illimitée (Backblaze) ou tarif très bas (B2 : 0,005 €/GB/mois). • Transfert de données complet via rclone mount ou restic backup. • Chiffrement hands‑on ( --crypt). |
• Gestion de la politique de tarification : si vous dépassez 10 TB, les coûts augmentent. • Pas d’interface graphique ‘Clé en main’ ; nécessite un peu de parcourt de ligne. |
Estimation d’un workflow typique :
# 1. Initialise le repo borg
borg init --encryption='repokey-blake2' /var/backups/dolibarr-repo
# 2. Crée une sauvegarde incrémentale
DATE=$(date +%Y-%m-%dT%H%M%S)
borg create \
::'{hostname}-{date}-{time}' \
/var/backups/dolibarr-repo \
/var/www/dolibarr \
/var/lib/mysql/dolibarr \
--exclude '/var/www/dolibarr/files/tmp*' \
--exclude '/proc*' \
--stats \
--compression lz4
# 3. Exportation vers Backblaze B2
borg export-tar /var/backups/dolibarr-repo::'{hostname}-{date}-{time}' - | \
rclone rcat my-b2:dolibarr-backup/${DATE}.tar.lz4- RPO : vous pouvez configurer
--keep-last 14pour ne garder que 14 sauvegardes récentes, tout en ayant un historique complet pour les plus anciennes. - Restauration :
borg extractourclone copydepuis B2 vers le serveur.
4. Comparatif synthétique : quel scénario choisir ?
| Critère | Cloud S3 (rclone) | NAS Synology | BaaS Backblaze | Scripts maison (Borg/Restic) |
|---|---|---|---|---|
| Facilité d’installation | ⚙️ (Nécessite AWS CLI & IAM) | 📦 (GUI Synology) | 📁 (Client Backblaze) | 🧑💻 (Script & dépendances) |
| Automatisation possible | ✔️ (cron → incrémental) | ✔️ (planif. intégré) | ✔️ (rclone daemon) | ✔️ (systemd timers) |
| Coût mensuel | 0,02 €/Go (≈ 1 €/mois pour 50 Go) | 0 € (hors matériel) | 5‑7 €/mois (illimité) | Variable (stockage + services) |
| RPO moyen | 15 min – 1 h | 1 h – 6 h | 1 h – 3 h | 30 min – 2 h (selon fréquence) |
| Sécurité | Chiffrement client possible | Chiffrement au repos (NAS) | Chiffrement côté client (rclone) | Chiffrement intégré (Borg) |
| Scalabilité | Illimitée (auto‑scaling S3) | Dépend du disque du NAS | Illimitée (backblaze) | Dépend du disque du repo |
| Gestion des versions | Versionning S3 (activer) | Snapshots point‑in‑time | Versioning (optionnel) | Historique git‑like de Borg |
Conclusion rapide :
- Petites structures (≤ 30 Go) : un bucket S3 (ou B2) + script rclone/cron → le rapport qualité‑prix le plus favorable.
- Organisations qui possèdent déjà du matériel NAS : Synology Cloud Sync ou QNAP Hybrid Backup offre une interface riche et des snapshots instantanés.
- Entreprises avec besoin de rétention illimitée et de conformité stricte : Backblaze B2 + Borg** donne le contrôle complet, tout en gardant un tarif très bas.
5. Guide de mise en œuvre pas à pas (exemple Cloud S3 + rclone)
Objectif : créer une sauvegarde quotidienne (ou incrémentale toutes les 15 min) des fichiers Dolibarr + base de données vers Amazon S3, avec chiffrement côté client.
5.1. Pré‑requis
| Étape | Action |
|---|---|
| 1. Créez un bucket S3 | aws s3 mb s3://dolibarr-backup-XXX (remplacez XXX). |
| 2. Activez le versionning | Dans la console, sélectionnez le bucket → Properties → Versioning → Enable. |
| 3. Politique IAM minimale | Créez un rôle DolibarrBackup avec les permissions s3:PutObject, s3:PutObjectAcl, s3:ListBucket, s3:DeleteObject (pour purge). |
| 4. Installez rclone | curl https://rclone.org/install.sh | bash ou via le gestionnaire de paquets. |
| 5. Configurez un remote S3 | rclone config → n → name: dolibarr-s3 → s → provider: AWS → provider: AWS S3 → region: eu-west-1 → account: <clé‑accès> → secret: <secret> → endpoint: s3.amazonaws.com → quit. |
| 6. Chiffrement supplémentaire (facultatif) | rclone config → c → name: dolibarr-crypt → remote: dolibarr-s3 → filename encryption: standard → password: <votre‑mot‑de‑passe> → quit. Utilisez dolibarr-crypt: comme remote final. |
5.2. Script de sauvegarde (bash)
#!/usr/bin/env bash
set -euo pipefail
#--- CONFIG ---
BUCKET="s3://dolibarr-backup-XXX"
REMOTE="dolibarr-crypt" # ou "dolibarr-s3" si pas de chiffrement
WEB_ROOT="/var/www/dolibarr"
DB_HOST="localhost"
DB_USER="doli"
DB_PASS="*****"
DB_NAME="dolibarr"
RETENTION_DAYS=30
#--- 1. Export DB ---
DATE=$(date +%Y%m%d-%H%M)
DUMP="/tmp/dolibarr-$DATE.sql.gz"
mysqldump -h"$DB_HOST" -u"$DB_USER" -p"$DB_PASS" "$DB_NAME" | gzip > "$DUMP"
#--- 2. Upload des fichiers + DB ---
# Crée un répertoire temporaire versionné
TMPDIR="/tmp/dolibarr-backup-$DATE"
mkdir -p "$TMPDIR/files" "$TMPDIR/db"
# Copie les fichiers (respecte les permissions)
cp -a "$WEB_ROOT/files"/* "$TMPDIR/files/"
# Upload
rclone copy "$WEB_ROOT/files" "${REMOTE}/files/$DATE" --progress
rclone copyto "$DUMP" "${REMOTE}/db/${DATE}.sql.gz" --progress
#--- 3. Purge des anciens sauvegardes ---
# Garder les N derniers jours
rclone purge --min-age ${RETENTION_DAYS}d "${REMOTE}/files"
rclone purge --min-age ${RETENTION_DAYS}d "${REMOTE}/db"
# Nettoyage local
rm -rf "$TMPDIR" "$DUMP"Points importants :
set -euo pipefailgarantit que le script s’arrête en cas d’erreur, évitant les sauvegardes partielles.--min-agepurge les sauvegardes plus vieilles que le nombre de jours spécifié (ici 30 jours). Vous pouvez changer la politique (--keep-daily,--keep-weekly, etc.) avecrclone delete.- La sauvegarde incrémentale se produit naturellement : seules les portions de fichiers réellement modifiées sont re‑uploades.
5.3. Planifier la tâche
# Ajoutez au crontab (exécution chaque 15 minutes)
*/15 * * * * /usr/local/bin/backup-dolibarr.sh >> /var/log/backup-dolibarr.log 2>&15.4. Tests & validation
| Test | Méthode |
|---|---|
| Vérifier que le remote accepte les uploads | rclone ls $REMOTE |
| Exécuter le script manuellement | bash /usr/local/bin/backup-dolibarr.sh (pas de crontab). |
| Simuler une restauration | rclone copy $REMOTE/db/$(date -d "-1 day" +%Y%m%d-%H%M).sql.gz /tmp/ → gunzip /tmp/*.sql.gz | mysql -h"$DB_HOST" -u"$DB_USER" -p"$DB_PASS" "$DB_NAME" |
| Vérifier la versionning | Accédez à la console S3 → vous devez voir plusieurs versions du même objet (si vous avez modifié un fichier déjà existant). |
6. Bonnes pratiques à retenir
-
Séparez les sauvegardes :
- Base de données → dump SQL, versionning ou compression.
- Fichiers → copie des répertoires
files/etcustom/. - Config de Dolibarr (
conf/,custom/) → souvent oublié, incluez‑les.
-
Chiffrez toujours :
- Même si S3 offre le chiffrement côté serveur, ajoutez le chiffrement côté client (
rclone crypt) pour que l’opérateur du cloud ne puisse pas lire vos données.
- Même si S3 offre le chiffrement côté serveur, ajoutez le chiffrement côté client (
-
Ne sauvegardez jamais depuis le serveur de production pendant les heures de créneau :
- Programme la première sauvegarde complète la nuit, puis incrémentale toutes les heures ou 15 min selon votre RPO souhaité.
-
Testez régulièrement la restauration :
- Un test mensuel vous assure que vos sauvegardes sont réellement restaurables. Vous éviterez les mauvaises surprises le jour du sinistre.
-
Surveillez les coûts :
- Utilisez les Analytics de S3 pour identifier les objets « inactifs » et envisagez de les migrer vers la classe de stockage Glacier Deep Archive après 90 jours.
- Documentez les procédures :
- Un petit run‑book (SOP) contenant les commandes de restauration, les informations de contact du prestataire cloud, et les contacts d’escalade. Un bon SOP accélère le Recovery Time Objective.
7. Alternatives & cas d’usage avancés
| Situation | Solution préconisée |
|---|---|
| Environnement multi‑sites (siège + succursales) | Utilisez Rclone + Gmail comme hub centralisé, chaque site pousse ses sauvegardes vers un même bucket via VPN. |
| Haute disponibilité (HA) avec plusieurs serveurs Dolibarr | Sauvegardez le partage de fichiers NFS (ex. /var/www/dolibarr/files) une fois sur le NAS central, puis replicatez-le. |
| Conformité PCI‑DSS | Activez le chiffrement TLS 1.2+ sur les transferts, stockez les clés de chiffrement dans un HSM, et configurez AWS KMS pour la gestion des clés. |
| Sauvegarde à long terme (archivage) | Copiez les données vers Azure Blob Archive ou Google Cloud Archive après 30 jours d’inactivité; ils sont très économiques (< 0,001 €/GB/mois). |
| Sauvegarde « Zero‑trust » | Utilisez rclone + s3w-sync avec --tls-cipher et --ignore-existing pour que seules les modifications cryptées soient transmises, même si le réseau est compromis. |
8. Checklist de déploiement « Sauvegarde off‑site Dolibarr »
| ✅ | Action |
|---|---|
| 1 | Identifier le volume total des données (du -sh /var/www/dolibarr). |
| 2 | Choisir la cible off‑site (S3, B2, NAS, BaaS). |
| 3 | Créer un compte d’accès dédié avec droits limités. |
| 4 | Mettre en place le chiffrement (rclone crypt ou GPG). |
| 5 | Écrire le script de sauvegarde (dump MySQL + sync des fichiers). |
| 6 | Tester le script en mode dry‑run. |
| 7 | Planifier la tâche via cron ou systemd timer. |
| 8 | Configurer la rétention (ex : 30 jours, garder 5 versions). |
| 9 | Effectuer un test de restauration complet. |
| 10 | Mettre à jour la documentation interne et le SOP. |
9. Conclusion
Déployer Dolibarr avec une stratégie de backup off‑site n’est plus une tâche complexe lorsqu’on s’appuie sur des solutions modernes d’API S3 compatible, NAS hybride ou BaaS. La clé du gain de temps réside dans :
- Automatisation via
cron/systemd+ rclone ou les modules natifs du NAS. - Versionning qui vous évite de devoir reconstruire manuellement les fichiers modifiés.
- Chiffrement client pour garder la confidentialité, même chez le fournisseur cloud.
- Rétention fine (quotidienne, hebdomadaire, mensuelle) afin de respecter vos exigences de conformité sans surcharge de stockage.
En suivant la feuille de route décrite ci‑dessus, vous disposerez d’un dispositif de sauvegarde rapide, fiable et peu coûteux, capable de restaurer votre environnement Dolibarr en quelques minutes, tout en vous libérant des tâches manuelles chronophages.
À retenir : « Une bonne sauvegarde est une sauvegarde que l’on ne teste jamais ». Faites‑la fonctionner, testez la restauration régulièrement, et votre environnement Dolibarr restera résilient, même face aux pannes les plus inattendues.
Si vous avez besoin d’un exemple de configuration spécifique (ex. : AWS IAM + CloudWatch Alarms, ou intégration dans un serveur Docker), n’hésitez pas à le préciser !