OTOBO Backup & Restore – Comprehensive Guide

OTOBO Backup & Restore – Comprehensive Guide

In this guide, we take a deep dive into backup strategies for OTOBO and examine:

1. Database dump via mysqldump
2. Backing up and restoring Docker volumes
3. OTOBO-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, 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 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 container 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 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 in 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 the 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

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

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 archive & cloud

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

Differences from other systems (backup context)

In the area of backup & 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 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 a single-transaction flag.
  • Znuny: Similar scripts exist, often without --remove-old-backups or advanced DB dump options; retrofitting via customization is necessary.

• DB dump optimizations

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

• Volume snapshot strategy

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

6. Conclusion

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

6. Conclusion

With these detailed scripts and strategies, your OTOBO data is securely backed up, ready for automation, and quickly restorable. Whether it’s a DB dump, Docker volumes, or standard OTOBO tools – you have all options under control.