OTOBO Backup & Restore – Database, Docker Volumes & Automation

In this guide: Protect your OTOBO data with proven backup and restore strategies.

Related: Staging system · Hosting · Performance · Get support

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

Reliable OTOBO operations & expert support

Dependable support for version upgrades, staging environments, disaster recovery strategies, and 2nd-level technical support.

View support plans

Frequently asked questions

What are the essential components of a comprehensive OTOBO backup?

A complete OTOBO backup must include both the database and the application's file data. The database (typically MySQL) stores critical information like tickets, users, and most system settings. The application file data, often referred to as the "home directory," contains attachments, custom configurations, and logs. For OTOBO deployments using Docker, it's crucial to also back up the associated Docker volumes, as these are where all persistently stored files reside. Neglecting any of these components could lead to incomplete data recovery, rendering the backup ineffective.

Quellen / Sources:

• OTOBO Backup & Restore – Database, Docker Volumes & Automation
• Backup and Restore — OTOBO Installation Guide 11.0 documentation

How can `mysqldump` be used to back up the OTOBO database, and what are important considerations?

mysqldump is a fast and platform-independent tool for backing up the OTOBO database, which contains almost all tickets, users, and settings. A key consideration when using mysqldump is to include the --single-transaction flag. This option minimizes table locks during the backup process, ensuring that OTOBO remains available and operational for users, even under high load. It's also vital to implement a retention policy, such as keeping the last 72 hourly dumps (3 days), which can be managed effectively with a cron job that creates new dumps and deletes older ones. The output should ideally be compressed (e.g., with gzip) to save disk space.

Quellen / Sources:

• OTOBO Backup & Restore – Database, Docker Volumes & Automation
• Backup and Restore — OTOBO Installation Guide 10.1 documentation

What is the process for backing up and restoring OTOBO Docker volumes?

All persistently stored OTOBO files, including attachments, configuration, and logs, reside within Docker volumes. For a consistent backup, it's recommended to temporarily shut down the OTOBO Docker containers using docker compose down before archiving the /var/lib/docker/volumes directory. This ensures that no files are being written during the backup, preventing data corruption. The volumes can then be archived into a compressed TAR file (e.g., docker_volumes_$DATE.tar.gz). For restoration, the existing OTOBO containers should be stopped, old volumes removed, and the archived volumes extracted back to /var/lib/docker/volumes before restarting OTOBO with docker compose up -d. This guarantees a clean and complete restoration of the application's file system.

Quellen / Sources:

• OTOBO Backup & Restore – Database, Docker Volumes & Automation
• Backup and Restore using Docker - OTOBO Documentation

How do OTOBO's native `backup.pl` and `restore.pl` scripts work, and what options do they offer?

OTOBO provides its own command-line interface scripts, backup.pl and restore.pl, located in /opt/otobo/scripts/ within the container. These scripts simplify the backup process by handling both the database and the application's home directory. Key options for backup.pl include --backup-dir to specify the target directory, --compress for choosing between gzip or bzip2 compression, and --remove-old-backups DAYS for automated cleanup of older backups. The --backup-type option allows for fullbackup (database + home directory), nofullbackup, or dbonly. These scripts are particularly useful in Docker environments, where they can be executed via docker run with appropriate volume mounts.

Quellen / Sources:

• OTOBO Backup & Restore – Database, Docker Volumes & Automation
• Backup and Restore — OTOBO Installation Guide 11.0 documentation

What are the best practices for automating OTOBO backups and handling potential errors?

Automating OTOBO backups is crucial for data protection. This can be achieved using cron jobs to schedule regular execution of backup scripts, such as those for mysqldump or Docker volume backups. A best practice is to wrap backup commands in a shell script that includes error checking. For instance, after executing a backup command, checking the exit status ($?) allows you to detect if the backup failed. If an error occurs, the script should log the failure and potentially send a notification, ensuring that administrators are aware of any issues. Regular cleanup of old backups, perhaps using find with -mtime +DAYS -delete, is also essential to manage disk space.

Quellen / Sources:

• OTOBO Backup & Restore – Database, Docker Volumes & Automation
• OTOBO Hosting Guide – Self-Hosted, Docker & Provider Comparison

How can OTOBO backups be archived for long-term storage, including cloud solutions?

For long-term archiving and disaster recovery, it's highly recommended to store OTOBO backups offsite, ideally in cloud storage. Services like AWS S3 are popular choices due to their scalability and durability. Backups, typically in .tar.gz or .sql.gz format, can be uploaded to S3 using the aws cli or custom Python scripts. Another versatile tool is rclone, which supports various cloud targets including S3, Azure Blob Storage, and FTP, providing flexibility for different cloud providers. Offsite storage ensures that data is protected even in the event of a local disaster affecting the primary OTOBO server.

Quellen / Sources:

• OTOBO Backup & Restore – Database, Docker Volumes & Automation
• OTOBO Hosting Guide – Self-Hosted, Docker & Provider Comparison

What are the key differences in backup strategies between OTOBO and Znuny?

OTOBO offers several advantages in its backup mechanisms compared to community Znuny setups. OTOBO's official Docker image includes a pre-installed backup service with CLI hooks (docker compose run backup), prepared volume mounts, and environment variables, simplifying container backups. Its backup.pl and restore.pl scripts support advanced features like automatic cleanup (--remove-old-backups), compression selection, and a --single-transaction flag for database dumps to avoid locks. In contrast, Znuny's community Docker setups often require manual addition of backup containers or custom scripts, and its similar CLI scripts may lack advanced options like --remove-old-backups or transaction protection, necessitating more customization by the user. OTOBO also provides integrated S3 uploader examples and configuration modules for cloud storage, which are typically external solutions for Znuny.

Quellen / Sources:

• OTOBO Backup & Restore – Database, Docker Volumes & Automation
• Backup and Restore using Docker - OTOBO Documentation