OTOBO / Znuny Backup & Restore – A Comprehensive Guide

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

1. Database Dump via mysqldump
2. Docker Volumes backup and restore
3. OTOBO's Native Scripts backup.pl and restore.pl
4. Automation with Cronjobs and Error Handling
5. Long-Term Archiving (e.g., AWS S3)

1. Database Dump with mysqldump

Advantage: Fast, platform-independent, and includes 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, keeping OTOBO 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 a 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 Backup of Volumes

#!/bin/bash
date=
DATE=$(date +'%d%m%Y_%H%M%S')
# Shut down containers for a consistent file system
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 Restoration: Volumes & Containers

#!/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 inside 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 (everything) | nofullbackup | dbonly

fullbackup: Database + home directory (without cache).
dbonly: Database only.

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

Restoring in the 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"

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 Archive & Cloud

• AWS S3: Upload the .tar.gz and .sql.gz files via aws cli or a 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 & Restore, OTOBO and Znuny differ in the following aspects:

• Container Backups

  • OTOBO: The 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 manually adding a backup container or customizing your 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 exist, often without --remove-old-backups or advanced DB dump options; retrofitting through customization is necessary.

• DB Dump Optimizations

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

• Volume Snapshot Strategy

  • OTOBO: Example scripts (e.g., full backup & restore) are the official reference and are tested in multi-container environments.
  • Znuny: Snapshot scripts vary greatly, and official best practices are lacking; users often have 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.

With this focus on backup-specific differences, you can make an informed decision whether to use the pre-built OTOBO mechanisms or to extend Znuny setups individually.

6. Conclusion

With these detailed scripts and strategies, your OTOBO data is securely backed up, automatable, and quickly restorable. Whether you use DB dumps, Docker volumes, or OTOBO's standard tools, you have all the options under control.