Backup & Restore (Docker)¶

This section shows some basics about the backup and restore process for a Docker Compose based deployment of Zammad.

If you are familiar with volume based backup and restore procedures in Docker, and perhaps already use a different method or tool, then you can keep using it. A backup would typically mean shutting down the stack to ensure all in-memory files get written to disk, then backing up the volume contents, and then starting the stack again. When using such a method, you can consider using the disable-backup-service scenario so that the built-in backup and restore mechanism of Zammad is not activated.

The rest of this page describes the built-in backup and restore mechanism of Zammad’s Docker Compose stack.

If you’re familiar with Docker, the sections below include the information you’ll need. The File Handling Examples page covers some examples about how to handle the backup files and to copy it into a Docker volume to restore it.

Backup¶

By default, a backup is created at at 3 o’clock each night. The backup is stored in the volume of the zammad-backup container under /var/tmp/zammad. To trigger a one-time backup manually, use one of the commands below, depending on your deployment method.

In your Docker Compose directory, run:

$ docker compose run --rm --env BACKUP_ONCE=true zammad-backup

Open the console via Portainer’s GUI for the zammad-backup container with the standard entrypoint /bin/bash and run:

$ BACKUP_ONCE=true bin/docker-entrypoint zammad-backup

Restore¶

Start the new stack at least once so a Zammad database is available.
Stop the stack.
In case you restore to a production stack with activated file system storage, you should purge the content of the directory /opt/zammad/storage/ inside the volume. The restore process only adds/overwrites files there, no cleanup will take place.
Copy or move the backup files to /var/tmp/zammad/restore/ inside the volume of the zammad-backup container. Be aware that the restore process always uses the latest backup according to the timestamp of the file name. Only backups from package and Docker installations are supported by this built-in backup method. Don’t provide the latest_zammad_*.gz files because they link to an unknown location for the restore process.
Start the stack. The restore process is triggered in the zammad-backup service if the restore directory is detected and the backup files are in place. As a part of this process, the Rails cache will be cleared. All other containers wait for the restore to finish before they resume their normal operations.
After the restore process has finished, the restore directory got renamed. You can safely delete it now.
Rebuild the Elasticsearch index. You can use Zammad while the rebuild is running, but search performance is degraded and some data may be temporarily unavailable in search results. Use one of the commands below, depending on your deployment method.
Without specifying CPU cores:
$ docker compose run --rm zammad-railsserver bundle exec rake zammad:searchindex:rebuild
With specifying CPU cores to use (example: 8):
$ docker compose run --rm zammad-railsserver bundle exec rake zammad:searchindex:rebuild[8]
Open the console via Portainer’s GUI with the standard entrypoint /bin/bash and run:

Without specifying CPU cores:
$ bundle exec rake zammad:searchindex:rebuild
With specifying CPU cores to use (example: 8):
$ bundle exec rake zammad:searchindex:rebuild[8]