Mettre à niveau Dolibarr : backup offsite pour équipes hybrides

Guide complet pour garantir la continuité de vos données lorsqu’on travaille à la fois en présentiel et à distance.

1. Pourquoi un backup off‑site est‑il indispensable avec Dolibarr ?

Situation Risque sans backup off‑site Bénéfice d’un backup hors‑site
Panne matérielle (serveur local, NAS) Perte immédiate d’accès aux factures, clients, stocks. Restauration à partir d’un serveur distant en quelques minutes.
Sinfection ransomware Les fichiers chiffrés sont souvent également synchronisés, rendant la récupération difficile. Les versions « shadow‑copy » ou les snapshots stockés ailleurs restent indemnes.
Migration ou mise à niveau Un plantage pendant la mise à jour peut corrompre la base de données. Possibilité de revenir à une version antérieure sans perdre les données récentes.
Travail hybride (bureau, télétravail, coworking) Les fichiers locaux sont dispersés, difficile à versionner. Un point centralisé accessible depuis n’importe quel emplacement.

En bref : la redondance géographique protège non seulement vos données contre les sinistres locaux, mais assure aussi la continuité du service pour les équipes qui ne partagent pas le même espace physique.

2. Les principes clés d’un backup off‑site réussi

  1. 3‑2‑1 Rule (adaptée au cloud)

    • 3 copies des données (production + 2 sauvegardes).

    • 2 supports différents (ex. serveur interne + stockage cloud).

    • 1 copie hors‑site (datacenter cloud ou serveur dédié en autre région).

  2. RPO (Recovery Point Objective) réaliste

    • Définissez la fréquence de sauvegarde (quotidienne, incrémentielle, horaire).

    • Exemple : sauvegarde toutes les 6 h → RPO ≈ 6 h.

  3. RTO (Recovery Time Objective) maîtrisé

    • Le temps nécessaire pour restaurer les services doit être compatible avec les exigences métier.

    • Utilisez des scripts d’automatisation (ex. Ansible, Bash + rclone) pour réduire le RTO à quelques minutes.

  4. Sécurité des données

    • Chiffrement en‑transit (TLS/SSL) et au repos (AES‑256).

    • Gestion stricte des accès (IAM, clés API limitées).

  5. Tests périodiques

    • Effectuez au moins un test de restauration complète chaque trimestre.

    • Documentez le processus et ajustez les scripts en fonction des retours.

3. Architecture type pour une équipe hybride

┌───────────────────────┐

│   Workstations / PC    │  (Linux, Windows, macOS)

└─────────┬─────────────┘

          │

          ▼

┌───────────────────────┐          ┌───────────────────────┐

│   Serveur Dolibarr     │◄──────► │   Base de données      │

│   (local ou Docker)    │  RPC/DB  │   MySQL / PostgreSQL   │

└─────────┬─────────────┘          └─────────┬─────────────┘

          │                                 │

          ▼                                 ▼

    └─► 1️⃣ Sauvegarde locale (scripts rsync,       │

         ZFS snapshot, Duplicity, Restic…)     │

                │                                 │

                ▼                                 ▼

          ┌─────────────────────┐   ┌─────────────────────┐

          │   Repository local  │   │   Cloud storage     │

          │   (NAS / Disk)      │◄──►│   (S3, Backblaze,   │

          │   (gardé 7‑14 jours)│   │    Azure Blob)      │

          └─────────────────────┘   └─────────────────────┘

                                          │

                                          ▼

                                   2️⃣ Backup off‑site (rclone sync)

Étapes concrètes

Étape Action Outils recommandés
1. Exporter la base mysqldump ou pg_dump avec --single-transaction mysqldump, pg_dump, pg_basebackup
2. Archiver tar.gz ou zip avec compression et chiffrement GPG tar, gpg
3. Copier vers le repo local rsync --delete ou rclone copy rsync, rclone
4. Sync vers le Cloud rclone sync --progress --checksum rclone (S3, Backblaze B2, Wasabi)
5. Rotation & Rétention Supprimer les older snapshots > N jours find, logrotate, restic
6. Notification Email / Slack / Teams quand une sauvegarde échoue mailx, curl webhook

4. Exemple de script Bash (rclone + restic)

NB : Adaptez les chemins et les mots de passe à votre environnement.
Le script peut être déclenché via cron toutes les 6 h.

#!/usr/bin/env bash

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

# Variables à personnaliser

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

APP_NAME="dolibarr"

BACKUP_ROOT="/opt/backups/${APP_NAME}"

LOCAL_REPO="${BACKUP_ROOT}/local"

OFFSITE_REPO="mycloud:bucket/dolibarr"

RESTIC_PASSWORD="S3cUr3P@ss"

RETENTION_DAYS=30

MAIL_TO="admin@votre-entreprise.com"
# -----------------------------------------------------------------------

# 1️⃣ Sauvegarde de la base de données

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

DB_NAME="dolibarr"

TIMESTAMP=$(date +%Y%m%d-%H%M%S)

DB_DUMP="/tmp/${DB_NAME}_${TIMESTAMP}.sql.gz"
echo "🔧 Export de la base ${DB_NAME} → ${DB_DUMP}"

mysqldump -u dolibarr_user -p${DB_PASSWORD} --single-transaction "${DB_NAME}" \

    | gzip > "${DB_DUMP}"
# -----------------------------------------------------------------------

# 2️⃣ Archivage & chiffrement avec restic

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

export RESTIC_PASSWORD="${RESTIC_PASSWORD}"

RESTIC_REPO="${OFFSITE_REPO}"
echo "🔐 Initialisation du repo restic si besoin"

restic snapshots -r "${RESTIC_REPO}" >/dev/null 2>&1 || \

    restic init -r "${RESTIC_REPO}"
echo "💾 Ajout du dump à restic"

restic -r "${RESTIC_REPO}" backup "${DB_DUMP}" \

    --tag "${APP_NAME}" --quiet
# -----------------------------------------------------------------------

# 3️⃣ Rotation des snapshots (conservation de N jours)

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

echo "🧹 Suppression des snapshots vieux de > ${RETENTION_DAYS} jours"

restic -r "${RESTIC_REPO}" forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune --quiet
# -----------------------------------------------------------------------

# 4️⃣ Nettoyage locale

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

rm -f "${DB_DUMP}"

echo "✅ Backup terminé et nettoyé."
# -----------------------------------------------------------------------

# 5️⃣ Notification en cas d’erreur (cron s’en charge)

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

if mail -s "⚠️ Backup ${APP_NAME} terminé avec succès" "${MAIL_TO}"; then

    echo "Notification envoyée."

fi

Points à retenir

  • Chiffrement : restic chiffre les données avant de les envoyer. Vous pouvez aussi activer le chiffrement côté S3 (SSE‑S3 ou SSE‑KMS).

  • Intégrité : chaque snapshot possède un hash interne; restic check permet de le valider périodiquement.

  • Idempotence : le script peut être relancé sans risque de duplication massive.

5. Gestion des accès et des droits

Niveau Action Exemple d’implémentation
Utilisateur local Accès limité à lecture des dossiers de backup chmod 750 /opt/backups/dolibarr && chgrp backup /opt/backups/dolibarr
Service de sauvegarde Compte dédié avec droits write uniquement sur le bucket IAM policy S3 : s3:PutObject, s3:ListBucket, s3:DeleteObjectVersion
Admin Possibilité de restore manuel (ex. restic restore) Utiliser un compte sudo séparé ou un sudoers dédié

Best‑practice : ne jamais stocker les mots de passe en clair dans les scripts. Utilisez HashiCorp Vault, AWS Secrets Manager ou un fichier .env avec des permissions 600 et inclusif dans cron.

6. Tests de restauration : un rituel incontournable

  1. Choisir un point de restauration (ex. snapshot de 7 jours).

  2. Cloner le bucket dans un environnement isolé (VM de test).

  3. Restaurer la base avec restic restore ou mysql depuis le dump.

  4. Vérifier l’intégrité des tables (SELECT COUNT(*) FROM llx...).

  5. Comparer les hashes des fichiers (sha256sum) entre source et restauration.

  6. Documenter le temps pris et les éventuels points d’amélioration.

Effectuer ce test au moins une fois par trimestre garantit que le DRP (Disaster Recovery Plan) reste fonctionnel lorsqu’il sera réellement nécessaire.

7. Bonnes pratiques spécifiques aux équipes hybrides

Situation Astuce
Collaborateurs en télétravail Mappez un partage réseau (SMB/NFS) vers le répertoire de backup local du serveur ; ainsi chaque collaborateur peut déclencher rsync via un script léger attaché à son poste.
Bureau partagé / hot‑desking Utilisez Docker pour containeriser le serveur Dolibarr : le volume contenant la base et les fichiers de config est monté depuis le disque partagé du NAS, donc le même environnement de sauvegarde vaut partout.
Accès depuis l’étranger Créez un VPN site‑to‑site ou utilisez SSH tunnel pour que les sauvegardes hors‑site ne transitent que sur un réseau chiffré ; évitez les API publiques ouvertes.
Mise à jour du serveur Avant chaque mise à jour majeure (ex. Dolibarr 13 → 20), créez un snapshot complet du volume (ex. ZFS snapshot) et conservez-le pendant 48 h avant migration.

8. Checklist « Prêt à déployer »

  • [ ] Inventaire des volumes à sauvegarder (DB, dossiers files/, htdocs/, config).

  • [ ] Choix du coût du stockage off‑site (S3 Standard‑IA vs. Glacier).

  • [ ] Mise en place d’un bucket S3 (ou équivalent) avec chiffrement par défaut.

  • [ ] Script de sauvegarde testé localement (≥ 2 cycles).

  • [ ] Plan de rotation (7 jours, 30 jours, archivage 1 an).

  • [ ] Alertes (mail / Teams) configurées sur les échecs.

  • [ ] Documentation à jour (README, diagramme d’architecture).

  • [ ] Simulation de restauration réalisée et validée par le PO.

9. Conclusion

Mettre à niveau Dolibarr tout en garantissant la continuité d’accès à vos données ne se résume pas à installer la dernière version ; c’est avant tout préparer une stratégie de sauvegarde résiliente qui s’aligne sur les spécificités d’une équipe hybride :

  1. 3‑2‑1 (copies locales + cloud)

  2. Automatisation robuste (rclone/rsync/restic)

  3. Sécurité de bout en bout (chiffrement, IAM)

  4. Tests réguliers pour valider le RTO/RPO.

En suivant les étapes décrites ci‑dessus, vous disposerez d’un plan de backup off‑site fiable, scalable et adapté à des environnements distribués. Vos collaborateurs pourront travailler en toute sérénité, que ce soit depuis le bureau, la maison ou un café du coin, sachant que leurs données critiques sont protégées contre toute perte ou compromise.

Petit conseil de pro : gardez toujours une copie de sauvegarde hors‑ligne (ex. disque externe chiffré) que vous pouvez saisir manuellement en cas d’incident majeur du réseau. C’est la dernière barrière avant la perte totale des données.

📚 Ressources complémentaires

Bonne mise à niveau et bon backup ! 🚀

Publications similaires