OTOBO Backup & Restore – Guide complet

OTOBO Backup & Restore – Guide complet

Dans ce guide, nous plongeons en profondeur dans les stratégies de sauvegarde pour OTOBO et examinons :

1. Dump de base de données via mysqldump
2. Sauvegarde et restauration des volumes Docker
3. Scripts natifs d’OTOBO backup.pl et restore.pl
4. Automatisation avec des 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 presque tous les tickets, utilisateurs et paramètres.

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. horaire, 72 derniers dumps (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 de plus de 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"

# Supprimer les anciens dumps (plus de 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 des volumes Docker.

2.1 Sauvegarde complète des volumes

#!/bin/bash
DATE=$(date +'%d%m%Y_%H%M%S')
# Arrêter le conteneur 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é en GZ dans le répertoire temp de l’hôte.

2.2 Restauration : Volumes & Conteneurs

#!/bin/bash
# Usage: restore_volumes.sh backup_file.tar.gz
tar -xzf "$1" -C /
# Supprimer les anciens volumes
docker compose -f /opt/otobo-docker/compose.yml down
rm -rf /var/lib/docker/volumes
# Restaurer et redémarrer
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 cible pour les sauvegardes
-c, --compress	gzip	Méthode de compression (gzip | bzip2)
-r, --remove-old-backups DAYS	aucun	Supprime les anciennes sauvegardes (en jours)
-t, --backup-type	fullbackup	fullbackup (tout) | nofullbackup | dbonly

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

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"
# Lancer 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/backups"
echo "Suppression des sauvegardes de plus de 30 jours dans $BACKUP_DIR"
find "$BACKUP_DIR" -mindepth 1 -mtime +30 -exec rm -rf {} \\
  \;
echo "Terminé."

5. Archivage à long terme & Cloud

• AWS S3 : Téléchargement des .tar.gz et .sql.gz via aws cli ou script Python.
• rclone : Support pour diverses cibles (S3, Azure Blob, FTP).
• Avantage : Stockage hors site, mise à l’échelle illimitée.

Différences avec d’autres systèmes (contexte de sauvegarde)

Dans le domaine du Backup & Restore, 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 et des variables d’environnement préparés.
  • 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 supportent des options de nettoyage automatique (--remove-old-backups), le choix de la compression et le flag Single-Transaction.
  • Znuny : Scripts similaires disponibles, souvent sans --remove-old-backups ou options avancées de dump DB ; nécessite une adaptation manuelle.

• Optimisations du dump DB

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

• Stratégie de snapshot de volume

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

• Automatisation & Plugins Cloud

  • OTOBO : Exemples d’uploader S3 intégrés (script Python) et modules de configuration pour Azure, Google Cloud Storage.
  • Znuny : Pas de plugins Core pour le stockage Cloud ; solutions généralement externes via rclone ou scripts d’upload séparés.

6. Conclusion

Avec ces scripts détaillés et ces stratégies, vos données OTOBO sont sauvegardées en toute sécurité, automatisables et rapidement restaurables. Qu’il s’agisse de dump DB, de volumes Docker ou d’outils standards OTOBO, vous maîtrisez toutes les options.