OTOBO Backup & Restore – Datenbank, Docker-Volumes & Automatisierung

In diesem Guide: OTOBO-Daten mit bewährten Backup- und Restore-Strategien schützen.

Verwandte Themen: Staging-System · Hosting · Performance · Support

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"
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.

OTOBO zuverlässig betreiben

Unterstützung bei Updates, Staging, Wartung, Backup-Konzept und einem dokumentierten, sicheren Betrieb.

Betrieb besprechen

Häufig gestellte Fragen

Was gehört zu einem OTOBO-Backup?

Mindestens Datenbank und Anwendungsdaten (Artikel/Anhänge und Konfiguration). Bei Docker zusätzlich Volume-Backups.

Welche Werkzeuge werden für OTOBO-Backups genutzt?

mysqldump für die Datenbank, backup.pl/restore.pl für Anwendungsdaten sowie Volume-Archive bei Docker-Installationen.

Sollten Backups automatisiert werden?

Ja. Planen Sie regelmäßige Backups per Cron (oder Orchestrator) und prüfen Sie Restore-Läufe regelmäßig.

Was sollte ich über Beispiel Befehl wissen?

`--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) `otobo_db_backup.sh` erstellt Dump und löscht Dateien älter als 3 Tage.

Was sollte ich über 2.1 Vollbackup der Volumes wissen?

Down/Up: Garantiert saubere Kopie. Archive: GZ‑komprimiertes TAR im Host‑Temp.