restic-backup-suite: Stopping services

Stopping services around the backup: systemd services, Docker Compose services and standalone containers, order, wait times and automatic restart when the script exits.

Deutsche Version

Back to overview

Stopping services

For consistent file snapshots, backup.sh can stop services before the backup and start them again afterwards. Both lists are empty by default, in which case nothing happens.

systemd services

SERVICES_TO_STOP=("myapp" "myapp-worker")
SERVICE_STOP_WAIT=2
SERVICE_START_WAIT=3

For each entry the script checks systemctl is-active. If the service is running, it is stopped with systemctl stop and remembered for the restart. If it is not running, the script skips it with a warning and does not start it later either.
After stopping, the script waits SERVICE_STOP_WAIT seconds, after starting SERVICE_START_WAIT seconds.

Docker services and containers

DOCKER_SERVICES_TO_STOP=(
    "/srv/seafile/docker-compose.yml:seafile"
    "some-standalone-container"
)
DOCKER_STOP_WAIT=2
DOCKER_START_WAIT=3

Entry format	Behaviour
`/path/docker-compose.yml:service`	`docker compose -f <file> stop <service>`, later `docker compose -f <file> start <service>`. If the file does not exist, the entry is skipped
`container-name`	`docker stop <name>`, later `docker start <name>`

If the service or container is not running, it is skipped with a warning. If docker is missing, the script skips all Docker entries.

Do not list database containers. The dumps run via docker exec against the running container and would fail otherwise.

Order

Stop systemd services
Stop Docker services
Database dumps
restic backup, retention (restic forget --prune), integrity check
When the script exits: remove temporary directories, start systemd services, start Docker services

Services are only started in the cleanup at the end of the run. They therefore stay down during retention, prune and the integrity check as well, not only during the backup.

How reliable the restart is

The restart is tied to the cleanup handler, which runs on normal exit, on errors (ERR) and on the INT and TERM signals. If starting a service fails, the script only logs a warning and continues with the others. If the script is killed hard (SIGKILL) or the system crashes, no cleanup runs and the services stay stopped.

With --dry-run, systemd services are still stopped (and started again afterwards), Docker services are not. With --dump-only nothing is stopped.