OTOBO Backup & Restore – Umfangreiche Anleitung

OTOBO Backup & Restore – Umfangreiche Anleitung

In dieser Anleitung tauchen wir tief in die Backup‑Strategien für OTOBO ein und betrachten:

1. Datenbank‑Dump per mysqldump
2. Docker‑Volumes sichern und wiederherstellen
3. OTOBO‑eigene Skripte backup.pl und restore.pl
4. Automatisierung mit Cronjobs und Error‑Handling
5. Langzeitarchivierung (z. B. AWS S3)

1. Datenbank‑Dump mit mysqldump

Vorteil: Schnell, plattformunabhängig, enthält nahezu alle Tickets, Nutzer und Einstellungen.

Beispiel Befehl

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: Minimiert Table‑Locks, OTOBO bleibt verfügbar.
• Aufbewahrung: z. B. stündlich, letzte 72 Dumps (3 Tage) via Cron.

Cron‑Job (stündlich, 3‑Tage‑Retention)

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

otobo_db_backup.sh erstellt Dump und löscht Dateien älter als 3 Tage.

Beispiel Skript: 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 "Erstelle DB-Dump nach $FILE"
mysqldump --host=localhost --user=otobo \
  --password=SecretPass --column-statistics=0 \
  --single-transaction otobo | gzip > "$FILE"

# Alte Dumps löschen (älter als 3 Tage)
find "$BACKUP_DIR" -type f -name '*.sql.gz' -mtime +3 -delete

2. Docker‑Volume‑Backup

Alle persistent gespeicherten Dateien (Attachments, Konfiguration, Logs) liegen in Docker‑Volumes.

2.1 Vollbackup der Volumes

#!/bin/bash
date=
DATE=$(date +'%d%m%Y_%H%M%S')
# Container herunterfahren für konsistentes Dateisystem
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: Garantiert saubere Kopie.
• Archive: GZ‑komprimiertes TAR im Host‑Temp.

2.2 Wiederherstellung: Volumes & Container

#!/bin/bash
# Usage: restore_volumes.sh backup_file.tar.gz
tar -xzf "$1" -C /
# Alte Volumes entfernen
docker compose -f /opt/otobo-docker/compose.yml down
rm -rf /var/lib/docker/volumes
# Wiederherstellen und neu starten
tar -xzf "$1" -C /
docker compose -f /opt/otobo-docker/compose.yml up -d

3. OTOBO‑Skripte: backup.pl & restore.pl

OTOBO liefert eigene CLI‑Skripte im Container:

# Hilfe anzeigen
/opt/otobo/scripts/backup.pl -h

Optionen

Option	Default	Beschreibung
-d, --backup-dir	erforderlich	Zielverzeichnis für Backups
-c, --compress	gzip	Kompressionsmethode (gzip | bzip2)
-r, --remove-old-backups DAYS	keine	Löscht ältere Backups (in Tagen)
-t, --backup-type	fullbackup	fullbackup (alles) | nofullbackup | dbonly

fullbackup: Datenbank + Home‑Verzeichnis (ohne Cache).
dbonly: Nur Datenbank.

Beispiel: Vollbackup im Docker‑Container

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

Wiederherstellen im Container

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. Automatisierung & Error‑Handling

Wrapper Skript mit Fehler­überprüfung

#!/bin/bash
COMPOSE_FILE="/opt/otobo-docker/compose.yml"
# Backup starten
docker compose -f "$COMPOSE_FILE" run --rm backup
if [ $? -ne 0 ]; then
  echo "Backup fehlgeschlagen" >&2
  exit 1
fi
echo "Backup erfolgreich abgeschlossen"

Alt: Cron für Volume‑Backup

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

Aufräumen alter Backups

#!/bin/bash
BACKUP_DIR="/pfad/zu/backups"
echo "Entferne Backups älter als 30 Tage in $BACKUP_DIR"
find "$BACKUP_DIR" -mindepth 1 -mtime +30 -exec rm -rf {} \\
  \;
echo "Fertig."

5. Langzeitarchiv & Cloud

• AWS S3: Upload der .tar.gz und .sql.gz per aws cli oder Python‑Script.
• rclone: Unterstützung für diverse Targets (S3, Azure Blob, FTP).
• Vorteil: Offsite‑Storage, unbegrenzte Skalierung.

Unterschiede zu anderen Systemen (Backup-Kontext)

Im Bereich Backup & Restore weichen OTOBO und Znuny in folgenden Aspekten ab:

• Container‑Backups

  • OTOBO: Offizielles Docker‑Image liefert vorinstallierten Backup‑Service mit CLI‑Hooks (docker compose run backup), inklusive vorbereiteter Volume‑Mounts und Umgebungsvariablen.
  • Znuny: Community‑Docker‑Setups erfordern manuelles Hinzufügen eines Backup‑Containers oder Anpassung eigener Skripte.

• OTOBO CLI‑Scripts

  • OTOBO: backup.pl und restore.pl im Image unterstützen automatische Aufräum‑Optionen (--remove-old-backups), Kompressionsauswahl und Single‑Transaction‑Flag.
  • Znuny: Ähnliche Skripte vorhanden, oft ohne --remove-old-backups oder erweiterten DB‑Dump‑Optionen; Nachrüsten per Anpassung nötig.

• DB‑Dump‑Optimierungen

  • OTOBO: Standardflag --single-transaction empfohlen und dokumentiert, um Locks zu vermeiden; CLI sorgt für konsistente Nutzung.
  • Znuny: Community-Dokus verweisen meist auf einfachen Dump ohne Transaktionsschutz, Risiko von Locks bei hoher Last.

• Volume‑Snapshot‑Strategie

  • OTOBO: Beispielskripte (z. B. Vollbackup & Restore) sind offizielle Referenz und in Multi‑Container‑Umgebungen getestet.
  • Znuny: Snapshot‑Scripts variieren stark, offizielle Best Practices fehlen; Anwender müssen oft eigene Down/Up‑Sequenzen definieren.

• Automation & Cloud‑Plugins

  • OTOBO: Integrierte S3‑Uploader Beispiele (Python‑Skript) und Konfigurationsmodule für Azure, Google Cloud Storage.
  • Znuny: Keine Core‑Plugins für Cloud‑Storage; Lösungen meist extern über rclone oder separate Upload‑Skripte.

6. Fazit

Mit diesem Fokus auf backup‑spezifische Unterschiede können Sie gezielt entscheiden, ob Sie die vorgefertigten OTOBO‑Mechanismen nutzen oder Znuny‑Setups individuell erweitern.## 6. Fazit

Mit diesen detaillierten Skripten und Strategien sind Ihre OTOBO‑Daten sicher gesichert, automationsfähig und schnell wiederherstellbar. Egal ob DB‑Dump, Docker‑Volumes oder OTOBO‑Standard‑Tools – Sie haben alle Optionen im Griff.