OTOBO / Znuny Sauvegarde & Restauration – Guide Complet

Dans ce guide, nous allons plonger en profondeur dans les stratégies de sauvegarde pour OTOBO et examiner :

1. Dump de base de données via mysqldump
2. Sauvegarde et restauration des volumes Docker
3. Scripts OTOBO natifs backup.pl et restore.pl
4. Automatisation avec Cronjobs et gestion des erreurs
5. Archivage à long terme (par ex. AWS S3)

1. Dump de base de données avec mysqldump

Avantage : Rapide, indépendant de la plateforme, contient la quasi-totalité des tickets, utilisateurs et configurations.

Exemple de commande

mysqldump \
  --host=${DB_HOST} \
  --user=${DB_USER} \
  --password=${DB_PASS} \
  --column-statistics=0 \
  --single-transaction \
  --databases otobo \
  > /backup/otobo_db_$(date +'%Y%m%d_%H%M').sql

• --single-transaction : Minimise les verrous de table (Table Locks), OTOBO reste disponible.
• Conservation : Par ex. toutes les heures, dernières 72 sauvegardes (3 jours) via Cron.

Cron‑Job (horaire, rétention de 3 jours)

0 * * * * /usr/local/bin/otobo_db_backup.sh

otobo_db_backup.sh crée le dump et supprime les fichiers plus anciens que 3 jours.

Exemple de script : otobo_db_backup.sh

#!/bin/bash
BACKUP_DIR="/backup/db"
mkdir -p "$BACKUP_DIR"
DATE=$(date +'%Y%m%d_%H%M')
FILE="$BACKUP_DIR/otobo_db_${DATE}.sql.gz"

echo "Création du dump DB vers $FILE"
mysqldump --host=localhost --user=otobo \
  --password=SecretPass --column-statistics=0 \
  --single-transaction otobo | gzip > "$FILE"

# Suppression des anciens dumps (plus vieux que 3 jours)
find "$BACKUP_DIR" -type f -name '*.sql.gz' -mtime +3 -delete

2. Sauvegarde des volumes Docker

Tous les fichiers stockés de manière persistante (pièces jointes, configuration, logs) se trouvent dans les volumes Docker.

2.1 Sauvegarde complète des volumes

#!/bin/bash
date=
DATE=$(date +'%d%m%Y_%H%M%S')
# Arrêt des conteneurs pour un système de fichiers cohérent
docker compose -f /opt/otobo-docker/compose.yml down

tar -czf "/tmp/docker_volumes_$DATE.tar.gz" /var/lib/docker/volumes

docker compose -f /opt/otobo-docker/compose.yml up -d --build

• Down/Up : Garantit une copie propre.
• Archive : TAR compressé GZ dans le répertoire temporaire de l'hôte.

2.2 Restauration : Volumes & Conteneurs

#!/bin/bash
# Utilisation : restore_volumes.sh backup_file.tar.gz
tar -xzf "$1" -C /
# Suppression des anciens volumes
docker compose -f /opt/otobo-docker/compose.yml down
rm -rf /var/lib/docker/volumes
# Restauration et redémarrage
tar -xzf "$1" -C /
docker compose -f /opt/otobo-docker/compose.yml up -d

3. Scripts OTOBO : backup.pl & restore.pl

OTOBO fournit ses propres scripts CLI dans le conteneur :

# Afficher l'aide
/opt/otobo/scripts/backup.pl -h

Options

Option	Défaut	Description
-d, --backup-dir	requis	Répertoire de destination pour les sauvegardes
-c, --compress	gzip	Méthode de compression (gzip | bzip2)
-r, --remove-old-backups DAYS	aucun	Supprime les sauvegardes plus anciennes (en jours)
-t, --backup-type	fullbackup	fullbackup (tout) | nofullbackup | dbonly

fullbackup : Base de données + répertoire Home (sans cache).
dbonly : Seulement la base de données.

Exemple : Sauvegarde complète dans le conteneur Docker

docker run --rm \
  --volume otobo_opt_otobo:/opt/otobo \
  --volume otobo_backup:/otobo_backup \
  rotheross/otobo:latest-10_0 scripts/backup.pl \
    --backup-dir /otobo_backup --compress gzip --remove-old-backups 7

Restauration dans le conteneur

docker run --rm \
  --volume otobo_opt_otobo:/opt/otobo \
  --volume otobo_backup:/otobo_backup \
  rotheross/otobo:latest-10_0 scripts/restore.pl \
    --backup-dir /otobo_backup/20231015_123045 --backup-dir /opt/otobo

4. Automatisation & Gestion des erreurs

Script Wrapper avec vérification des erreurs

#!/bin/bash
COMPOSE_FILE="/opt/otobo-docker/compose.yml"
# Démarrer la sauvegarde
docker compose -f "$COMPOSE_FILE" run --rm backup
if [ $? -ne 0 ]; then
  echo "Échec de la sauvegarde" >&2
  exit 1
fi
echo "Sauvegarde terminée avec succès"

Ancien : Cron pour la sauvegarde des volumes

0 */6 * * * /usr/local/bin/volume_backup.sh

Nettoyage des anciennes sauvegardes

#!/bin/bash
BACKUP_DIR="/chemin/vers/sauvegardes"
echo "Suppression des sauvegardes plus anciennes que 30 jours dans $BACKUP_DIR"
find "$BACKUP_DIR" -mindepth 1 -mtime +30 -exec rm -rf {} \\
  \;
echo "Terminé."

5. Archivage à long terme & Cloud

• AWS S3 : Upload des fichiers .tar.gz et .sql.gz via aws cli ou script Python.
• rclone : Support pour diverses cibles (S3, Azure Blob, FTP).
• Avantage : Stockage hors site, évolutivité illimitée.

Différences entre OTOBO et Znuny (contexte de sauvegarde)

Dans le domaine de la sauvegarde et de la restauration, OTOBO et Znuny diffèrent sur les points suivants :

• Sauvegardes de conteneurs

  • OTOBO : L'image Docker officielle fournit un service de sauvegarde préinstallé avec des hooks CLI (docker compose run backup), incluant des montages de volumes préparés et des variables d'environnement.
  • Znuny : Les configurations Docker communautaires nécessitent l'ajout manuel d'un conteneur de sauvegarde ou l'adaptation de scripts personnalisés.

• Scripts CLI OTOBO

  • OTOBO : backup.pl et restore.pl dans l'image prennent en charge les options de nettoyage automatiques (--remove-old-backups), la sélection de la compression et le flag single-transaction.
  • Znuny : Des scripts similaires existent, souvent sans --remove-old-backups ou avec des options de dump de base de données étendues ; une adaptation est nécessaire pour les compléter.

• Optimisations des dumps de base de données

  • OTOBO : Le flag standard --single-transaction est recommandé et documenté pour éviter les verrous ; la CLI assure une utilisation cohérente.
  • Znuny : La documentation communautaire renvoie généralement à un dump simple sans protection de transaction, risquant des verrous en cas de forte charge.

• Stratégie de snapshot des volumes

  • OTOBO : Les scripts d'exemple (par ex. sauvegarde complète et restauration) servent de référence officielle et sont testés dans des environnements multi-conteneurs.
  • Znuny : Les scripts de snapshot varient considérablement, les meilleures pratiques officielles manquent ; les utilisateurs doivent souvent définir leurs propres séquences de down/up.

• Automatisation & Plugins Cloud

  • OTOBO : Exemples d'uploaders S3 intégrés (script Python) et modules de configuration pour Azure, Google Cloud Storage.
  • Znuny : Pas de plugins natifs pour le stockage cloud ; les solutions passent généralement par des outils externes comme rclone ou des scripts d'upload séparés.

6. Conclusion

Avec ces scripts détaillés et stratégies, vos données OTOBO seront sauvegardées en toute sécurité, automatisables et rapidement restaurables. Que ce soit via les dumps de base de données, les volumes Docker ou les outils standard OTOBO, vous maîtrisez toutes les options.