Dolibarr et sauvegarde : erreurs fréquentes et solutions avec intégrations modernes

Dolibarr et sauvegarde : les erreurs les plus fréquentes et leurs solutions grâce aux intégrations modernes
Version 2025 – Guide pratique pour les administrateurs et les développeurs

1. Introduction

Dolibarr est une solution ERP/CRM open‑source très populaire grâce à sa simplicité d’utilisation et à son architecture modulaire. Dans un contexte professionnel, la sauvegarde du serveur Dolibarr devient un impératif : une perte de données peut entraîner l’arrêt de la comptabilité, de la gestion des contacts ou de la facturation.

Malheureusement, de nombreux administrateurs comet­ront des erreurs classiques qui compromettent la fiabilité des sauvegardes. Heureusement, les intégrations modernes (API cloud, conteneurs, sauvegardes incrémentales, outils de monitoring…) permettent aujourd’hui de corriger ces lacunes rapidement et de façon automatisée.

Cet article détaille :

  • les erreurs les plus courantes,

  • leurs causes sous‑jacentes,

  • les solutions concrètes que les intégrations modernes offrent,

  • un petit « cookbook » d’exemples de configuration.

2. Les erreurs fréquentes de sauvegarde Dolibarr

N° Erreur Conséquence typique
1 Sauvegarde ponctuelle manuelle sans automatisation Risque d’oubli, sauvegarde incohérente (base de données en cours d’écriture).
2 Sauvegarde uniquement du répertoire files/ ou uniquement de la base de données Perte de données si l’autre composant n’est pas restauré.
3 Pas de versionnage / de rétention Les fichiers de sauvegarde s’accumulent indéfiniment → saturation disque ou perte de versions anciennes.
4 Utilisation de sauvegardes non chiffrées Violation des exigences RGPD / conformité.
5 Sauvegarde directe du fichier db sans mysqldump ou pg_dump Risque d’inconsistance, corruption du fichier de base.
6 Sauvegarde sans test de restauration Ne découvre pas les problèmes de compatibilité ou de restauration uniquement à l’urgence.
7 Pas de notification en cas d’échec L’admin ignore que la sauvegarde n’a pas eu lieu.
8 Sauvegarde sans vérifier l’espace disque disponible Échec silencieux (code de sortie 0 mais aucun fichier créé).
9 Conflits d’horodatage lors de sauvegarde multi‑site / multi‑container Restore incohérent entre les différentes instances.
10 Intégration d’API tierces sans authentification sécurisée Risque d’exposition de clés d’API ou de blocage par les services externes (ex. : backup CDN non autorisé).

3. Pourquoi ces erreurs surviennent‑elles ?

  1. Manque de connaissances techniques – Beaucoup de petites structures utilisent le démarrage « tout‑en‑un » sans comprendre la séparation des composants (PHP, MySQL, fichiers uploadés).

  2. Conception initiale simplifiée – Un script Bash « one‑liner » est suffisant au départ, mais devient rapidement obsolète. 3. Contraintes de temps – Les administrateurs ont souvent plusieurs dossiers à gérer ; la sauvegarde devient alors une tâche « à faire plus tard ».

  3. Absence d’environnement de test – Sans instance de staging, il n’y a pas de validation avant la mise en production. 5. Complexité des environnements modernes – Microservices Docker, hébergement en cloud sans accès SSH direct, réseau restrictionnel.

4. Solutions de sauvegarde modernes (intégrations)

4.1. Orchestration via Docker / Docker‑Compose

Avantage : tout le système (PHP‑FPM, Apache, MySQL, Dolibarr) est encapsulé.
Correction : on peut déclencher des jobs de sauvegarde unitaires depuis le conteneur principal via Cron interne ou Swararm.

# docker-compose.yml – extrait

services:

  db:

    image: mariadb:11

    environment:

      MYSQL_ROOT_PASSWORD: secret

      MYSQL_DATABASE: dolibarr

    volumes:

      - db-data:/var/lib/mysql

    restart: unless-stopped
php:

    image: dolibarr/dolibarr:latest

    depends_on:

      - db

    environment:

      - APP_ENV=prod

    volumes:

      - dolibarr-files:/var/www/dolibarr/files

    restart: unless-stopped
backup:

    image: alpine:latest

    depends_on:

      - db

      - php

    volumes:

      - db-data:/var/lib/mysql:ro      - dolibarr-files:/var/www/dolibarr/files:ro

      - ./backups:/backups

    entrypoint: ["/bin/sh","-c"]

    command: |

      while true; do

        DATE=$(date +%Y-%m-%d_%H-%M);

        mysqldump -h db -u root -p"$MYSQL_ROOT_PASSWORD" dolibarr > /backups/db_$DATE.sql;

        tar -czf /backups/files_$DATE.tar.gz -C /var/www/dolibarr/files .;

        find /backups -type f -mtime +14 -delete;   # retention 14 jours

        sleep 86400;                               # 24h

      done

    restart: unless-stopped

volumes:

  db-data:

  dolibarr-files:

  • Automatisation : le conteneur backup lance chaque jour le dump SQL et le tar des fichiers, puis nettoie les sauvegardes de plus de 14 jours.

  • Versionnage externe : les fichiers de sauvegarde sont montés sur un volume ./backups qui peut être partagé avec un service de stockage externe (S3, Azure Blob, Google Drive).

  • Sécurité : les variables d’environnement sont chiffrées via Docker Secrets ou HashiCorp Vault.

4.2. Sauvegarde incrémentale avec Restic ou BorgBackup Ces outils offrent :

  • le chiffrement natif (AES‑256),

  • le déduplication côté client,

  • la compression transparente,

  • la vérification d’intégrité régulière (check‑sum).

Workflow typique :

  1. Installez Restic sur le serveur d’application.

  2. Créez un script restic-backup.sh :

    #!/bin/sh
    
export RESTIC_PASSWORD="motdepassefort"
    
export AWS_ACCESS_KEY_ID="AKIA..."
    
export AWS_SECRET_ACCESS_KEY="xxxx..."
    
RESTIC_REPOSITORY=s3:s3.amazonaws.com/mon-bucket/dolibarr-backups
    # 1️⃣ Dump SQL (format .sql.gz)
    
mysqldump -h db -u dolibarr_user -p$MYSQL_PASSWORD dolibarr | gzip > /tmp/db.sql.gz
    # 2️⃣ Archivage des fichiers uploadés
    
tar -czf /tmp/files.tar.gz -C /var/www/dolibarr/files .
    # 3️⃣ Restic push
    
restic -r $RESTIC_REPOSITORY backup /tmp/db.sql.gz /tmp/files.tar.gz \
    
      --tag dolibarr-backup-$(date +%Y-%m-%d)
    # 4️⃣ Prune (garder 30 jours)
    
restic -r $RESTIC_REPOSITORY forget --keep-daily 30 --prune
    # 5️⃣ Nettoyage local
    
rm -f /tmp/db.sql.gz /tmp/files.tar.gz

  3. Cron (exemple 매일 à 02 h) :

    0 2 * * * /usr/local/bin/restic-backup.sh >> /var/log/restic-dolibarr.log 2>&1

  • Intégration moderne : utilisation d’un bucket S3 ou compatibly S3 (MinIO, Wasabi) pour le repos. La même commande peut envoyer les sauvegardes vers Google Cloud Storage ou Azure Blob Storage en changeant simplement l’URL du repository.

  • Before‑backup hook : il est possible d’appeler un webhooks (ex. : Slack, Teams) afin d’envoyer une alerte « Backup OK » ou « FAIL ».

4.3. Sauvegarde « as‑a‑service » via API cloud

Plateforme Méthode d’intégration Points forts
Amazon S3 + Glacier Utilisez l’API PutObject depuis un conteneur ou script. Stockage durable, versioning natif, politique de transition vers Glacier à moindre coût.
Google Drive API Ouvrez un service de sync (rclone) qui synchronise le répertoire /backups avec un dossier Drive, en gardant la structure des snapshots. Accès facile via l’interface web, partage facile entre équipes.
Microsoft OneDrive/SharePoint Utilisez rclone ou le SDK PowerShell pour pousser les dump. Intégration native dans l’écosystème Microsoft, gestion des permissions granulaires.
Backblaze B2 b2 CLI + script de rotation des sauvegardes. Coût très bas, API compatible S3, idéal pour PME.

Exemple avec rclone (Sauvegarde quotidienne à 03 h) :

# ~/.config/rclone/rclone.conf   <-- configurez un remote "dolibarrb2" pointant sur Backblaze B2

0 3 * * * rclone copy /backups/dolibarr-$(date +%Y-%m-%d) dolibarrb2:dolibarr/$(date +%Y-%m-%d) --progress >> /var/log/rclone-dolibarr.log 2>&1

4.4. Monitoring & alerting (Prometheus + Alertmanager)

Pour éviter les “silenceurs” :

  • Exporter les métriques de Docker (container_last_status, container_cpu_usage, disk_usage) via cAdvisor.

  • Créer un alert qui se déclenche si aucun fichier n’est créé dans le bucket de sauvegarde pendant N minutes.

  • Alertmanager envoie un message Slack/Email/Telegram → on sait immédiatement si la sauvegarde s’est arrêtée.

# Exemple de règle Prometheus

groups:

- name: dolibarr_backup

  rules:

  - alert: BackupMissing

    expr: count(testbackup_success_total) == 0

    for: 5m

    labels:

      severity: critical

    annotations:

      summary: "Aucune sauvegarde Dolibarr créée depuis 5min"

      description: "Vérifier le job cron ou le conteneur backup."

5. Bonnes pratiques de sauvegarde moderne – Checklist rapide

✅ Action Pourquoi
1 Dockeriser l’ensemble (PHP, Apache, MySQL) pour assurer la réplication identique des environnements. Évite les divergences de configuration entre prod et dev.
2 Limiter les accès en clair : secrets stockés dans Docker Secrets, Kubernetes Secrets ou HashiCorp Vault. Conformité RGPD et prévention de fuites.
3 Utiliser un outil de sauvegarde incrémentale (Restic/Borg) avec chiffrement et déduplication. Réduit le volume stocké et le temps de transfert.
4 Versionner les sauvegardes (date‑heure) et appliquer une politique de rétention (ex. : 30 jours, 6 mois, 1 an selon besoin). Gestion de l’espace disque, possibilité de restaurer à différents points.
5 Planifier des tests de restauration au moins mensuel. Vérifie la faisabilité et la rapidité du retour à la production.
6 Configurer un monitoring (Prometheus check, santé du conteneur backup) + alerting. Détection précoce d’un problème de sauvegarde.
7 Ne jamais oublier le mysqldump avec --single-transaction pour la cohérence. Évite les sauvegardes qui correspondent à une base partiellement écrite.
8 Sauvegarder les fichiers upload/ séparément du répertoire database. En cas de corruption d’un seul composant, l’autre reste exploitable.
9 Chiffrer les sauvegardes avant de les envoyer hors‑site. Protection contre le vol de données sensibles.
10 Documenter chaque script, chaque paramètre et chaque procédure de restore. Réduction du MTTR (Mean Time To Recovery).

6. Exemple complet : flux de sauvegarde Docker + Restic + S3 en production

6.1. Architecture

+-------------------+       +------------------+

|  dolibarr-app     | <---- |  db (mariadb)    |

+-------------------+       +------------------+

        |                              |

        v                              v

+-------------------+   +----------------------+

|  backup-cron      |   |  restic-snapshot     |

| (Docker container)|   | (exécuté depuis backup)|

+-------------------+   +----------------------+

        |  (dump.sql.gz & files.tar.gz) |

        v                               v

   →  /tmp/data pour Restic  →  Restic push →  S3 bucket (chiffré)

6.2. Script backup.sh (exécuté dans le conteneur backup)

#!/bin/sh

set -euo pipefail
# -------------------------------------------------

# 1️⃣ Variables d’environnement (Docker Secrets)

# -------------------------------------------------

export MYSQL_HOST=db

export MYSQL_USER=dolibarr_user

export MYSQL_PASSWORD=$(cat /run/secrets/mysql_user_pwd)

export RESTIC_PASSWORD=$(cat /run/secrets/restic_pass)

export RESTIC_REPOSITORY=s3:s3.amazonaws.com/mon-bucket/dolibarr-backups?region=eu-west-1
# -------------------------------------------------

# 2️⃣ Dump SQL (consistent avec --single-transaction)

# -------------------------------------------------

DATE=$(date +%Y-%m-%d_%H-%M)

mysqldump -h "$MYSQL_HOST" -u "$MYSQL_USER" -p"$MYSQL_PASSWORD" \

          --single-transaction --quick dolibarr \

          | gzip > /tmp/db_$DATE.sql.gz
# -------------------------------------------------

# 3️⃣ Tar des fichiers uploadés

# -------------------------------------------------

tar -czf /tmp/files_$DATE.tar.gz -C /var/www/dolibarr/files .
# -------------------------------------------------

# 4️⃣ Restic backup (avec prune)

# -------------------------------------------------

restic backup /tmp/db_$DATE.sql.gz /tmp/files_$DATE.tar.gz \

       --tag dolibarr-backup-$DATE \

       --quiet# 5️⃣ Prune & Forget (garder 30 jours)

restic forget --keep-daily 30 --prune --quiet
# -------------------------------------------------

# 6️⃣ Nettoyage

# -------------------------------------------------rm -f /tmp/db_$DATE.sql.gz /tmp/files_$DATE.tar.gz```
### 6.3. Cron dans le conteneur `backup`  
```yaml# docker-compose.yml

    backup:

      image: alpine:latest

      depends_on: [db, php]

      volumes:

        - ./backup:/backups

        - ./certs:/certs:ro      # si vous utilisez TLS S3

        - ./ssh:/root/.ssh:ro    # si vous avez besoin d’un accès SSH au repo

      entrypoint: ["/bin/sh","-c"]

      command: |

        while true; do          /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1          sleep 86400

        done

Note : le conteneur backup peut aussi être remplacé par un Kubernetes CronJob afin de profiter d’une planification native et d’un monitoring intégré.

7. Cas d’usage : migration vers un environnement hybride 1. Scénario : vous avez un Dolibarr on‑premise et vous décidez de migrer partiellement (ex. : les factures) vers un serveur cloud.

  1. Intégration :

    • Sauvegarde du répertoire files vers Azure Blob Storage via rclone sync (crédit de versioning).

    • Export MySQL en CSV uniquement des tables "facture" et "partner" vers Google BigQuery via la API Cloud Pub/Sub (pour analyses). 3. Avantages : * Vous pouvez restaurer rapidement les fichiers sans toucher à la base.

    • Les exports BigQuery sont accessibles via des requêtes SQL rapides, permit : des tableaux de bord BI directement sur les données facturation.

  2. Erreur à éviter : ne pas mettre à jour la clé d’API du service cloud dans le script de sauvegarde après la migration → la sauvegarde échoue silencieusement.

  3. Solution : automatiser la rotation des clés via AWS Secrets Manager ou Azure Key Vault et notifier le changement via un webhook Slack.

8. Conclusion

La sauvegarde de Dolibarr, bien que conceptuellement simple, requiert une approche systématique lorsqu’on passe d’un environnement de test à un environnement de production.

Les erreurs récurrentes – sauvegarde ponctuelle, absence de versionnage, manque de chiffrement, ou test de restauration inexistant – sont toutes remédiables grâce aux technologies modernes :

  • Orchestration via conteneurs Docker / Kubernetes (jobs de backup intégrés, secrets gérés, portabilité).

  • Outils de sauvegarde incrémentale (Restic, Borg) qui apportent le chiffrement, la déduplication et la vérification d’intégrité.

  • Hooks d’intégration cloud (S3, Azure Blob, Google Drive) permettant de stocker les sauvegardes hors‑site, tout en profitant de la scalabilité et de la rétention native de ces services.

  • Monitoring + Alerting (Prometheus, Grafana, Alertmanager) qui garantit que tout problème est immédiatement communiqué.

En suivant la checklist décrite plus haut et en implémentant le cookbook (scripts Docker‑Compose, Cron Restic, monitoring Prometheus), vous obtiendrez :

  • Des sauvegardes automatisées à chaque jour, sans intervention manuelle.

  • Une restauration fiable grâce à des snapshots testés régulièrement.

  • Une conformité aux exigences de sécurité (RGPD, chiffrement en‑repos).

  • Un coût maîtrisé grâce à la déduplication et au stockage en « cold tier » (Glacier, Azure Archive, etc.).

En bref : modernisez votre pipeline de sauvegarde Dolibarr en adoptant les pratiques CI/CD d’aujourd’hui — automation, versioning, monitoring et sauvegarde multi‑cloud. Vous bénéficierez ainsi d’une résilience optimale, d’une réduction des risques opérationnels et d’une meilleure agilité pour faire évoluer votre ERP/CRM.

— Sources : Dolibarr Documentation (2024‑2025), Restic Documentation, AWS S3 Best Practices, Guide Docker‑Compose pour les bases de données, Articles de la communauté « Backup & Restore best‑practices » (Linux‑FR, DevOps.com).

Publications similaires