description: Comprehensive guide to backing up and restoring the OTOBO system, as well as Znuny, with various backup options and technical details.

OTOBO / Znuny Backup & Restore – Comprehensive Guide

In this guide, we will dive deep into backup strategies for OTOBO, covering:

1. Database Dump via mysqldump
2. Backing up and restoring Docker Volumes
3. OTOBO's own scripts backup.pl and restore.pl
4. Automation with cron jobs and error handling
5. Long-term archiving (e.g., AWS S3)

1. Database Dump with mysqldump

Advantage: Fast, platform-independent, contains almost all tickets, users, and settings.

Example Command

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: Minimizes table locks, OTOBO remains available.
• Retention: e.g., hourly, last 72 dumps (3 days) via cron.

Cron Job (hourly, 3-day retention)

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

otobo_db_backup.sh creates the dump and deletes files older than 3 days.

Example 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 "Creating DB dump to $FILE"
mysqldump --host=localhost --user=otobo \
  --password=SecretPass --column-statistics=0 \
  --single-transaction otobo | gzip > "$FILE"

# Delete old dumps (older than 3 days)
find "$BACKUP_DIR" -type f -name '*.sql.gz' -mtime +3 -delete

2. Docker Volume Backup

All persistently stored files (attachments, configuration, logs) are located in Docker volumes.

2.1 Full Volume Backup

#!/bin/bash
date=
DATE=$(date +'%d%m%Y_%H%M%S')
# Shut down container for consistent filesystem
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: Guarantees a clean copy.
• Archive: GZ-compressed TAR in the host's temp directory.

2.2 Restore: Volumes & Container

#!/bin/bash
# Usage: restore_volumes.sh backup_file.tar.gz
tar -xzf "$1" -C /
# Remove old volumes
docker compose -f /opt/otobo-docker/compose.yml down
rm -rf /var/lib/docker/volumes
# Restore and restart
tar -xzf "$1" -C /
docker compose -f /opt/otobo-docker/compose.yml up -d

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

OTOBO provides its own CLI scripts within the container:

# Show help
/opt/otobo/scripts/backup.pl -h

Options

Option	Default	Description
-d, --backup-dir	required	Target directory for backups
-c, --compress	gzip	Compression method (gzip | bzip2)
-r, --remove-old-backups DAYS	none	Deletes older backups (in days)
-t, --backup-type	fullbackup	fullbackup (all) | nofullbackup | dbonly

fullbackup: Database + Home directory (excluding cache).
dbonly: Database only.

Example: Full Backup in 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

Restore in 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. Automation & Error Handling

Wrapper Script with Error Checking

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

Old: Cron for Volume Backup

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

Cleaning Up Old Backups

#!/bin/bash
BACKUP_DIR="/path/to/backups"
echo "Removing backups older than 30 days in $BACKUP_DIR"
find "$BACKUP_DIR" -mindepth 1 -mtime +30 -exec rm -rf {} \;
echo "Done."

5. Long-Term Archiving & Cloud

• AWS S3: Upload .tar.gz and .sql.gz via aws cli or Python script.
• rclone: Supports various targets (S3, Azure Blob, FTP).
• Advantage: Offsite storage, unlimited scalability.

Differences Between OTOBO and Znuny (Backup Context)

In the area of backup and restore, OTOBO and Znuny differ in the following aspects:

• Container Backups

  • OTOBO: Official Docker image provides a pre-installed backup service with CLI hooks (docker compose run backup), including prepared volume mounts and environment variables.
  • Znuny: Community Docker setups require manual addition of a backup container or customization of own scripts.

• OTOBO CLI Scripts

  • OTOBO: backup.pl and restore.pl in the image support automatic cleanup options (--remove-old-backups), compression selection, and the single-transaction flag.
  • Znuny: Similar scripts are available, often without --remove-old-backups or advanced DB dump options; retrofitting via customization is necessary.

• DB Dump Optimizations

  • OTOBO: Default flag --single-transaction is recommended and documented to avoid locks; CLI ensures consistent usage.
  • Znuny: Community documentation usually refers to simple dumps without transaction protection, risking locks under high load.

• Volume Snapshot Strategy

  • OTOBO: Example scripts (e.g., full backup & restore) are official references and tested in multi-container environments.
  • Znuny: Snapshot scripts vary greatly, official best practices are missing; users often need to define their own down/up sequences.

• Automation & Cloud Plugins

  • OTOBO: Integrated S3 uploader examples (Python script) and configuration modules for Azure, Google Cloud Storage.
  • Znuny: No core plugins for cloud storage; solutions are usually external via rclone or separate upload scripts.

6. Conclusion

With these detailed scripts and strategies, your OTOBO data will be securely backed up, automatable, and quickly restorable. Whether it's a DB dump, Docker volumes, or OTOBO's standard tools – you have all options under control.