Dolibarr et sauvegarde : erreurs fréquentes et solutions avec des exemples concrets

La sauvegarde de Dolibarr est un pilier incontournable de la sécurité et de la pérennité de votre système d’information. Pourtant, de nombreuses entreprises et associations négligent ce point critique ou le mettent en œuvre de façon imparfaite, exposant leurs données financières, clients et projets à un risque majeur. Cet article identifie les erreurs les plus courantes et vous propose des solutions éprouvées, illustrées par des exemples pratiques.

1. Erreur fondamentale : Ne sauvegarder QUE la base de données

Le problème : Beaucoup d’administrateurs pensent qu’exporter la base de données MySQL/PostgreSQL (via mysqldump ou pg_dump) suffit. Or, Dolibarr stocke aussi des fichiers critiques en dehors de la base : les documents téléchargés (factures PDF, contrats, devis, images produits), les logos, les fichiers de configuration et les modules personnalisés.

Exemple concret :
Vous avez sauvegardé votre base à 2h du matin. À 10h, un utilisateur upload une facture client signée (fichier PDF) via le module Compta/factures. Cette facture n’existe que dans le répertoire documents/facture/ sur le serveur. Si votre disque dur tombe en panne à midi, la facture est définitivement perdue, bien que l’enregistrement en base (ligne SQL) existe. La restauration vous donnera une facture sans son fichier PDF.

Solution :
Mettre en place une sauvegarde complète en deux parties :

  1. Base de données : mysqldump -u [user] -p[password] [nom_db] > /backup/dolibarr_db_$(date +%Y%m%d).sql

  2. Dossier documents/ (et éventuellement custom/ si vous l’utilisez) : 
    tar -czf /backup/dolibarr_docs_$(date +%Y%m%d).tar.gz /var/www/dolibarr/documents/

    Bon pratique : Synchronisez ces deux sauvegardes sur un serveur distant (via rsync ou scp) ou un service cloud style Backblaze B2, Wasabi.

2. Erreur stratégique : Sauvegarder sur le même serveur que Dolibarr

Le problème : Déposer vos fichiers de sauvegarde (*.sql, *.tar.gz) dans un répertoire du même serveur que votre installation Dolibarr. En cas de défaillance matérielle majeure (disque dur corrompu, serveur hacké, incendie), la sauvegarde est perdue en même temps que les données sources.

Exemple concret :
Votre hébergement mutualisé OVH subit une panne RAID. Le disque contenant /var/www/dolibarr/ et le répertoire /backup/ est touché. Vous perdez tout.

Solution : La règle du 3-2-1.

  • 3 copies de vos données.

  • 2 supports de stockage différents (ex : disque dur interne + stockage objet cloud).

  • 1 copie externalisée (hors site géographique, ex : chez vous, dans un autre datacenter).

Mise en œuvre concrète :
Utilisez un script Cron qui envoie automatiquement les sauvegardes via rclone (pour Google Drive, S3, etc.) ou scp vers un VPS distinct.

# Exemple avec rclone vers un bucket S3 compatible

rclone copy /backup/ mon-bucket-sauvegardes:dolibarr/

3. Erreur de méthode : Pas de rotation ni de vérification des sauvegardes

Le problème :

  • Pas de rotation : Les sauvegardes s’accumulent jusqu’à remplir le disque, causant l’échec des nouvelles sauvegardes et parfois du fonctionnement du serveur.

  • Pas de vérification : Vous faites confiance à un script sans jamais tester son intégrité. Une corruption silencieuse (bit rot) ou une erreur de script peut rendre vos sauvegardes illisibles le jour J.

Exemple concret :
Votre script de sauvegarde génère un fichier SQL de 1 Go. Après 6 mois, vous avez 180 fichiers (environ 180 Go). Le disque de backup (200 Go) est plein. La sauvegarde du lendemain échoue. Vous ne vous en apercevez que 3 semaines plus tard. Pire, le fichier de sauvegarde le plus récent est tronqué à 200 Mo à cause d’une coupure pendant l’écriture.

Solution :

  1. Rotation automatique : Gardez seulement les 7 derniers jours + 4 dernieres semaines + 12 derniers mois. 
    # Exemple de nettoyage pour les bases
    
find /backup/ -name "dolibarr_db_*.sql" -type f -mtime +30 -delete
    
find /backup/ -name "dolibarr_db_*.sql" -type f -mtime +7 -exec basename {} \; | sort -u | head -n -4 | xargs -I {} find /backup/ -name {} -delete

  2. Vérification rigoureuse :

    • Test d’intégrité : Vérifiez la taille des fichiers et, si possible, leur checksum (MD5/SHA256) à la création et à la réception.

    • Test de restauration régulier : C’est l’étape la plus importante. Une fois par mois, restaurez la sauvegarde la plus récente sur un environnement de test (un serveur staging ou une machine virtuelle locale) et vérifiez que :

      • L’import SQL se fait sans erreur.

      • Les documents sont présents et lisibles.

      • Vous pouvez vous connecter à Dolibarr et naviguer normalement.

4. Erreur de configuration : Oublier les permissions et les chemins

Le problème : Le script de sauvegarde utilise un utilisateur système (ex: www-data ou dolibarr) qui n’a pas les droits d’écriture sur le répertoire de destination, ou qui ne peut pas lire tous les fichiers du dossier documents/ (problème de permissions détenues par d’autres utilisateurs).

Exemple concret :
Votre script fonctionne en cron sous l’utilisateur root, mais vous avez configuré la tâche via l’interface Plesk/cPanel sous l’utilisateur dolibarr_user. Ce dernier n’a pas accès en lecture à certains sous-dossiers de documents/ créés par un autre processus (ex: module de signature électronique). Le tar échoue silencieusement ou crée une archive incomplète.

Solution :

  1. Standardiser les permissions : 
    # Assurez-vous que l'utilisateur qui exécute le script de backup
    
# est propriétaire ou a les droits de lecture sur le dossier documents
    
chown -R dolibarr_backup_user:dolibarr /var/www/dolibarr/documents/
    
chmod -R 750 /var/www/dolibarr/documents/ # Lecture pour le groupe

  2. Tester manuellement : Exécutez la commande de sauvegarde manuellement en ligne de commande avec l’utilisateur qui sera utilisé par le cron (via sudo -u [user] commande). Analysez les messages d’erreur.

5. Erreur spécifique aux hébergements mutualisés/cloud (OVH, 1&1, AWS Lightsail…)

Le problème : Croire que l’ hébergement fait une sauvegarde automatique suffisante et accessible. Les sauvegardes automatiques des hébergeurs sont souvent :

  • Opaques : Vous ne contrôlez pas la fréquence, la rétention, le contenu exact.

  • Non-restaurables facilement : La restauration se fait souvent via un ticket support long et coûteux, ou via un panel qui ne restaure que des fichiers, pas la base de données de façon intégrée.

  • Non-testées : Vous n’avez aucune certitude sur leur bon fonctionnement.

Exemple concret (OVH) :
L’option "Sauvegarde" d’OVH pour un hébergement web fait un snapshot complet du disque. Pour restaurer un seul fichier de configuration conf/conf.php ou une base SQL, vous devez : 1) commander une restauration complète du snapshot sur un serveur temporaire, 2) extraire le fichier voulu, 3) le récupérer. C’est lourd et lent pour une restauration urgente.

Solution : Ne jamais dépendre uniquement des sauvegardes de l’hébergeur. Elles sont un filet de sécurité de dernier recours. Votre propre stratégie de sauvegarde (3-2-1) doit être prioritaire et opérationnelle.

Checklist de la sauvegarde Dolibarr réussie

  1. [ ] Double backup : Base SQL ET dossier documents/ (et custom/ si besoin).

  2. [ ] Externalisation : Au moins une copie hors du serveur principal (cloud, autre serveur).

  3. [ ] Rotation : Script qui nettoie les anciennes sauvegardes.

  4. [ ] Logging : Le script envoie un email ou écrit un log consultable en cas de succès/échec.

  5. [ ] Test de restauration : Procédure documentée et testée au moins trimestriellement sur un environnement isolé.

  6. [ ] Permissions : Vérification des droits en lecture/écriture pour le script.

  7. [ ] Documentation : Un document simple ("En cas de crash, voici les 5 étapes pour restaurer") à portée de main.

Conclusion

La sauvegarde de Dolibarr n’est pas une tâche technique qu’on configure une fois pour oublier. C’est un processus opérationnel continu qui doit être vérifié, testé et adapté. Investir du temps dans la mise en place d’une stratégie robuste (3-2-1 + tests) vous évitera un désastre coûteux en cas de sinistre. Votre données sont l’actif le plus précieux de votre organisation dans Dolibarr : traitez-les comme telles.

La question à vous poser chaque mois : "Si mon serveur tombait en panne dans 1 heure, est-ce que je pourrais restaurer intégralement Dolibarr, y compris les derniers documents, avec mes propres sauvegardes, en moins de 2 heures ?" Si la réponse est non, corrigez vos procédures dès aujourd’hui.

Publications similaires