Backup and Restore (Docker)
This documentation pertains to Docker deployments, all other deployments should read Backup and Restore (Generic) documentation.
The backup and restore scripts back up everything that makes up a Docker deployment: the database, the help desk
files, the data of the bundled services (Redis, Caddy, Meilisearch) and the files in the deployment directory
(docker-compose.yml, .env, and so on).
docker-compose.yml lives). If you're on Windows, use
Git Bash.
Backup
Backup Formats
The backup script can create three kinds of backup:
| Format | Description |
|---|---|
| Docker volumes (default) |
A copy of the Docker volumes. This is the fastest format to create and restore, as the data is copied as is rather than exported and imported. It can only be restored to another Docker deployment. |
Portable--portable |
The help desk's own backup format: a database dump and an archive of the application files, as created by
the app:backup command. It is slower to
create and restore, but can be restored to any deployment type, including non-Docker deployments.
|
Rollback point--pre-upgrade |
A snapshot of the deployment taken before an upgrade, so that the upgrade can be undone. The Docker volumes
are copied to <volume>_pre_upgrade volumes and only the deployment directory is archived.
See rolling back an upgrade.
|
Output Directory
All backups are generated in a backup directory within the deployment directory.
backup directory itself.
Keep the deployment directory free of unrelated files to avoid bloating your backups.
Downtime and Disk Space
The Docker volumes can only be copied consistently while the container is stopped, so the default and
--pre-upgrade backups stop the container for the duration of the copy. The storage/
volume (attachments and caches) and the log volume are archived while the container is running, so the downtime
is determined by the size of the database. From SupportPal 6.2.0 the database is copied while it is running using
the MySQL clone plugin,
reducing the downtime to a few seconds.
The volume copies are plain copies on the host's filesystem. On filesystems that support reflinks, such as XFS
(with reflink=1) and Btrfs, the copies are created almost instantly and use no additional disk space
until the data changes. On other filesystems, such as ext4, the host needs enough free space in the Docker data
root (typically /var/lib/docker) to hold a full copy of the database and the smaller volumes, in
addition to the archive in the backup directory. See
Filesystem for details.
The --portable format does not copy the Docker volumes, but it stops the help desk services while
the backup is created unless --online is given.
Usage
bash <(curl -fLsS https://raw.githubusercontent.com/supportpal/helpdesk-install/6.x/templates/docker-monolithic/backup.sh)Additional Options
| Option | Description |
|---|---|
--pre-upgrade |
Create a rollback point for an upgrade rather than a full backup. Cannot be
combined with --portable or --online.
|
--portable |
Create the backup in the help desk's own format rather than copying the Docker volumes. |
--online |
Do not stop the help desk services while the backup is created. Implies --portable, as the
Docker volumes can only be copied while the container is stopped.
|
--debug |
Enable verbose output. |
If the bundled MySQL server is disabled (
MYSQL_ENABLED=0), the database is not included in the
backup. Backing up your external database server is your responsibility.
Restore
The restore script creates a new deployment directory alongside the current one, for example
../supportpal_1745573480_17734, and restores the backup into it. If a supportpal
container already exists, you will be asked whether to remove it and its Docker volumes before the backup is
restored; the restored help desk then takes its place.
Usage
By default the script restores the most recent app-* archive in the backup
directory, as determined by the timestamp in the file name. Both backup formats are detected automatically
(Docker volume backups are named app-<timestamp>.tar.gz and portable backups
app-<timestamp>.tar).
bash <(curl -fLsS https://raw.githubusercontent.com/supportpal/helpdesk-install/6.x/templates/docker-monolithic/restore.sh)To restore a specific archive, pass its path with --file:
bash <(curl -fLsS https://raw.githubusercontent.com/supportpal/helpdesk-install/6.x/templates/docker-monolithic/restore.sh) --file backup/app-2025-04-25-09-31-18.tar.gz--portable backup, the help desk's app:restore command asks for the
database connection details. The script prints the details to use before the prompts appear.
Rolling Back an Upgrade
The upgrade script offers to create a rollback point before upgrading. A rollback point can also be created manually:
bash <(curl -fLsS https://raw.githubusercontent.com/supportpal/helpdesk-install/6.x/templates/docker-monolithic/backup.sh) --pre-upgrade
This copies the Docker volumes to <volume>_pre_upgrade volumes (for example
supportpal_db_pre_upgrade) and archives the deployment directory to
backup/pre-upgrade-<timestamp>.tar.gz. The storage/ and log volumes are not
copied, as an upgrade does not modify them. Each run replaces the copies made by the previous one, so only the
most recent rollback point can be restored.
To roll back, pass the archive to the restore script:
bash <(curl -fLsS https://raw.githubusercontent.com/supportpal/helpdesk-install/6.x/templates/docker-monolithic/restore.sh) --file backup/pre-upgrade-2025-04-25-09-31-18.tar.gz
Unlike a full restore, a rollback is applied in place: the files in the deployment directory are replaced with
the copies in the archive, and the Docker volumes are replaced with their _pre_upgrade copies.
Once you are satisfied with the upgrade, remove the rollback point to free the disk space. The exact commands are printed when the rollback point is created, for example:
docker volume rm supportpal_db_pre_upgrade supportpal_config_pre_upgrade supportpal_redis_pre_upgrade supportpal_addons_pre_upgrade supportpal_caddy_pre_upgrade supportpal_meilisearch_pre_upgrade
rm backup/pre-upgrade-2025-04-25-09-31-18.tar.gz