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.

Zuverlässiger OTOBO Betrieb & Support

Verlässliche Unterstützung bei Updates, Staging-Instanzen, Desaster-Recovery-Konzepten und technischem 2nd-Level-Support.

Support-Plan ansehen

Häufig gestellte Fragen

Was sind die Kernkomponenten eines vollständigen OTOBO-Backups?

Ein vollständiges OTOBO-Backup umfasst mehrere kritische Komponenten, um eine vollständige Wiederherstellung des Systems zu gewährleisten. Dazu gehören in erster Linie die Datenbank, die alle Tickets, Benutzerinformationen und Konfigurationseinstellungen speichert. Des Weiteren sind die Anwendungsdaten von großer Bedeutung, welche Artikel, Anhänge und weitere spezifische Konfigurationsdateien beinhalten. Bei einer Docker-Installation müssen zusätzlich die Docker-Volumes gesichert werden, da diese alle persistenten Dateien wie Attachments, Logs und die OTOBO-Konfiguration enthalten. Ein umfassendes Backup sollte also eine Kombination aus Datenbank-Dumps und Dateisystem- bzw. Volume-Backups sein, um Datenverlust zu vermeiden und die Systemintegrität zu sichern. Regelmäßige Tests der Wiederherstellung sind dabei essenziell, um die Funktionsfähigkeit der Backups zu überprüfen.

Quellen

• OTOBO Backup & Restore – Datenbank, Docker-Volumes & Automatisierung
• OTOBO Hosting – Self-Hosted, Docker & Anbieter-Vergleich

Wie sichere ich die OTOBO-Datenbank effizient mit `mysqldump`?

Die OTOBO-Datenbank kann effizient mit dem mysqldump-Befehl gesichert werden. Ein wichtiger Parameter hierbei ist --single-transaction, der Table-Locks minimiert und OTOBO während des Backups verfügbar hält. Dies ist besonders wichtig in Umgebungen mit hoher Last. Es wird empfohlen, einen Cron-Job einzurichten, der stündlich einen Dump erstellt und ältere Dumps (z.B. nach 3 Tagen) automatisch löscht, um Speicherplatz zu sparen. Ein Beispielskript wie otobo_db_backup.sh kann den Dump komprimieren (z.B. mit gzip) und in einem definierten Backup-Verzeichnis speichern. Dies gewährleistet eine schnelle, plattformunabhängige und konsistente Sicherung Ihrer Datenbank, die nahezu alle relevanten Daten enthält.

Quellen

• OTOBO Backup & Restore – Datenbank, Docker-Volumes & Automatisierung
• Backup and Restore — OTOBO Installation Guide 11.0 documentation

Wie erstelle ich ein konsistentes Backup der OTOBO Docker-Volumes?

Für ein konsistentes Backup der OTOBO Docker-Volumes ist es ratsam, die Docker-Container vor dem Backup herunterzufahren. Dies garantiert eine saubere Kopie des Dateisystems und verhindert Inkonsistenzen durch laufende Schreibvorgänge. Nach dem Herunterfahren mit docker compose down können die Volumes mit tar -czf in eine GZ-komprimierte TAR-Datei archiviert werden. Ein Beispielskript zeigt, wie das Verzeichnis /var/lib/docker/volumes gesichert wird. Nach dem Backup werden die Container mit docker compose up -d --build wieder gestartet. Für die Wiederherstellung werden die alten Volumes entfernt, das Archiv entpackt und die Container neu gestartet. Dies stellt sicher, dass alle persistenten Daten wie Attachments und Konfigurationen korrekt gesichert und wiederhergestellt werden.

Quellen

• OTOBO Backup & Restore – Datenbank, Docker-Volumes & Automatisierung
• Backup and Restore using Docker - OTOBO Documentation

Welche Funktionen bieten die OTOBO-eigenen Skripte `backup.pl` und `restore.pl`?

OTOBO bietet eigene CLI-Skripte, backup.pl und restore.pl, die im Docker-Image vorinstalliert sind und eine komfortable Möglichkeit zur Sicherung und Wiederherstellung des Systems darstellen. Das backup.pl-Skript unterstützt verschiedene Backup-Typen wie fullbackup (Datenbank + Home-Verzeichnis ohne Cache) oder dbonly (nur Datenbank). Es ermöglicht die Auswahl der Kompressionsmethode (z.B. gzip oder bzip2) und bietet eine Option zum automatischen Löschen älterer Backups (--remove-old-backups DAYS). Diese Skripte sind besonders nützlich für automatisierte Backup-Prozesse innerhalb des Docker-Containers, da sie bereits für die OTOBO-Umgebung optimiert sind und die Konsistenz der Daten gewährleisten. Die Wiederherstellung erfolgt analog mit restore.pl unter Angabe des Backup-Verzeichnisses.

Quellen

• OTOBO Backup & Restore – Datenbank, Docker-Volumes & Automatisierung
• Backup und Wiederherstellung — OTOBO Installation Guide 11.0 ...

Wie automatisiere ich OTOBO-Backups und stelle die Fehlerbehandlung sicher?

Die Automatisierung von OTOBO-Backups ist entscheidend für eine zuverlässige Datensicherung. Dies kann durch Cron-Jobs realisiert werden, die regelmäßig Backup-Skripte ausführen. Für Docker-Umgebungen empfiehlt sich ein Wrapper-Skript, das den Backup-Vorgang über docker compose run --rm backup startet. Eine integrierte Fehlerbeüberprüfung ist dabei unerlässlich: Das Skript sollte den Exit-Code des Backup-Befehls prüfen (if [ $? -ne 0 ]; then ...), um bei Fehlern eine Benachrichtigung zu senden oder weitere Aktionen auszulösen. Zusätzlich sollte ein separater Cron-Job für das Aufräumen alter Backups eingerichtet werden, um Speicherplatz zu verwalten und die Retention-Richtlinien einzuhalten. Regelmäßige Restore-Läufe sind ebenfalls wichtig, um die Integrität der Backups zu validieren.

Quellen

• OTOBO Backup & Restore – Datenbank, Docker-Volumes & Automatisierung
• Backup and Restore — OTOBO Installation Guide 10.1 documentation

Welche Optionen gibt es für die Langzeitarchivierung von OTOBO-Backups in der Cloud?

Für die Langzeitarchivierung von OTOBO-Backups in der Cloud bieten sich verschiedene Lösungen an, die Offsite-Storage und unbegrenzte Skalierung ermöglichen. Eine gängige Methode ist der Upload der komprimierten Backup-Dateien (z.B. .tar.gz und .sql.gz) zu AWS S3 mithilfe des aws cli oder eines Python-Skripts. Alternativ kann rclone verwendet werden, ein vielseitiges Befehlszeilenprogramm, das eine breite Palette von Cloud-Speicherdiensten wie Azure Blob Storage, Google Cloud Storage, FTP und viele andere unterstützt. Diese Cloud-Lösungen bieten nicht nur eine hohe Verfügbarkeit und Redundanz, sondern auch oft kostengünstige Speicheroptionen für selten benötigte Archivdaten, was sie ideal für die Langzeitaufbewahrung macht.

Quellen

• OTOBO Backup & Restore – Datenbank, Docker-Volumes & Automatisierung
• OTOBO Hosting – Self-Hosted, Docker & Anbieter-Vergleich

Worin unterscheiden sich OTOBO-Backup-Strategien von denen anderer Systeme wie Znuny?

OTOBO bietet im Vergleich zu anderen Systemen wie Znuny spezifische Vorteile und optimierte Backup-Strategien, insbesondere im Docker-Kontext. OTOBOs offizielles Docker-Image enthält einen vorinstallierten Backup-Service mit CLI-Hooks (docker compose run backup), vorbereiteten Volume-Mounts und Umgebungsvariablen. Die OTOBO CLI-Skripte backup.pl und restore.pl unterstützen automatische Aufräum-Optionen (--remove-old-backups), Kompressionsauswahl und das --single-transaction-Flag für konsistente DB-Dumps. Bei Znuny erfordern Community-Docker-Setups oft manuelle Anpassungen oder das Hinzufügen eigener Backup-Container. Auch bei DB-Dump-Optimierungen und Volume-Snapshot-Strategien bietet OTOBO offizielle Referenzskripte und eine stärkere Integration, während Znuny-Anwender häufig eigene Lösungen entwickeln müssen. Zudem bietet OTOBO integrierte S3-Uploader-Beispiele und Konfigurationsmodule für Cloud-Storage, die bei Znuny oft über externe Tools wie rclone realisiert werden.

Quellen

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