126 lines
3.7 KiB
Markdown
126 lines
3.7 KiB
Markdown
---
|
||
navigation: true
|
||
title: Backrest Docker Stop
|
||
main:
|
||
fluid: false
|
||
---
|
||
:ellipsis{left=0px width=40rem top=10rem blur=140px}
|
||
|
||
# Backrest Docker Stop
|
||
---
|
||
|
||
[Backrest](https://github.com/garethgeorge/backrest) is a fantastic backup tool.
|
||
In the case of [Serveex](https://docu.djeex.fr/serveex/introduction), most of the data that needs to be backed up consists of containers — and those containers often include databases.
|
||
The problem? You can’t safely back up a database while it’s running.
|
||
|
||
There are plenty of complex solutions involving database dumps, but often the simplest method is to stop the containers, perform the backup, and then restart them.
|
||
|
||
**Backrest** doesn’t natively provide this functionality, but it does allow the execution of custom scripts triggered by events — for example, at the start and end of a backup plan.
|
||
|
||
Our goal is to stop the containers whose databases need to be backed up when the backup plan starts, and restart them when the backup plan finishes.
|
||
|
||
To achieve this, we’ll need a small Bash script and a secure connection between Backrest and the Docker socket, to enable the following sequence:
|
||
|
||
- The backup plan starts
|
||
- The event triggers the execution of a custom script
|
||
- The script contacts Docker and retrieves a list of containers labeled `backrest.backup.stop=true`
|
||
- It stops those containers
|
||
- The backup plan completes
|
||
- The event triggers another custom script
|
||
- The script contacts Docker again, retrieves the same list, and restarts those containers
|
||
|
||
---
|
||
|
||
## Securely Connecting Backrest and Docker
|
||
|
||
To allow **Backrest** to communicate securely with Docker, we’ll use [Docker Socket Proxy](https://github.com/linuxserver/docker-socket-proxy).
|
||
This avoids exposing the full Docker socket and grants only the necessary permissions.
|
||
Here’s an example Docker stack:
|
||
|
||
```yaml
|
||
---
|
||
services:
|
||
backrest:
|
||
image: garethgeorge/backrest:latest
|
||
container_name: backrest
|
||
hostname: backrest
|
||
security_opt:
|
||
- no-new-privileges:true
|
||
volumes:
|
||
- ... # your volumes
|
||
environment:
|
||
- ... # your environment variables
|
||
- DOCKER_HOST=tcp://socket-proxy-backrest:2375
|
||
restart: unless-stopped
|
||
ports:
|
||
- ... # your ports
|
||
depends_on:
|
||
- socket-proxy
|
||
|
||
socket-proxy:
|
||
image: lscr.io/linuxserver/socket-proxy:latest
|
||
container_name: socket-proxy-backrest
|
||
security_opt:
|
||
- no-new-privileges:true
|
||
environment:
|
||
- CONTAINERS=1
|
||
- ALLOW_START=1
|
||
- ALLOW_STOP=1
|
||
volumes:
|
||
- /var/run/docker.sock:/var/run/docker.sock:ro
|
||
restart: unless-stopped
|
||
read_only: true
|
||
tmpfs:
|
||
- /run
|
||
```
|
||
|
||
With this setup, Backrest can communicate with Docker safely and securely.
|
||
|
||
---
|
||
|
||
## The Scripts
|
||
|
||
Below are the scripts to use for **Backrest**’s *start* and *end* backup events.
|
||
|
||
::code-group
|
||
```sh [Stop]
|
||
#!/usr/bin/env bash
|
||
|
||
BACKUP_LABEL="backrest.backup.stop=true"
|
||
BACKUP_CONTAINERS=$(docker ps -aqf "label=$BACKUP_LABEL")
|
||
for BC in $BACKUP_CONTAINERS
|
||
do
|
||
docker stop "$BC"
|
||
done
|
||
sleep 10
|
||
```
|
||
|
||
```sh [Start]
|
||
#!/usr/bin/env bash
|
||
|
||
BACKUP_LABEL="backrest.backup.stop=true"
|
||
BACKUP_CONTAINERS=$(docker ps -aqf "label=$BACKUP_LABEL")
|
||
for BC in $BACKUP_CONTAINERS
|
||
do
|
||
docker start "$BC"
|
||
done
|
||
sleep 10
|
||
```
|
||
|
||
---
|
||
|
||
## The Label
|
||
|
||
Once the scripts are in place and configured for the proper **Backrest** hooks, you just need to add the label `backrest.backup.stop=true` to the `compose.yaml` files of the containers that should stop and restart during backups:
|
||
|
||
```yaml
|
||
services:
|
||
your_service:
|
||
...
|
||
labels:
|
||
- backrest.backup.stop=true
|
||
```
|
||
|
||
And that’s it!
|
||
At the next backup, all containers with the correct label will automatically stop during the backup and restart once it’s finished.
|