Wer mehrere Docker-Stacks selbst betreibt, sollte nicht nur seine compose.yml sichern. Für eine vollständige Wiederherstellung sind vor allem persistente Docker-Volumes, Konfigurationsdateien, .env-Dateien und Datenbanken entscheidend.

In dieser Anleitung richten wir ein Docker Backup mit Borgmatic und BorgBackup ein. Borgmatic läuft direkt auf dem Docker-Host und überträgt die Backups verschlüsselt per SSH auf einen Raspberry Pi. MySQL- und PostgreSQL-Datenbanken werden vor jedem Backup automatisch als konsistente SQL-Dumps gesichert.

Anschließend führen wir einen echten Restore-Test durch. Denn erst wenn sich WordPress und Authentik tatsächlich aus dem Backup wiederherstellen lassen, wissen wir, dass unser Backup-Konzept funktioniert.

Inhalt

Das Backup-Konzept

Der grundsätzliche Aufbau sieht folgendermaßen aus:

Docker-Host
│
├── Docker-Stacks
│   ├── WordPress + MySQL
│   ├── Authentik + PostgreSQL
│   ├── Grafana
│   └── weitere Dienste
│
├── Borgmatic
│   ├── sichert Stack-Verzeichnisse
│   ├── sichert Docker-Volumes
│   ├── erstellt Datenbank-Dumps
│   └── verwaltet Retention und Checks
│
└──── SSH / WireGuard ───────────────┐
                                     ▼
                               Raspberry Pi
                                     │
                                     └── verschlüsseltes
                                         Borg-Repository

Borgmatic läuft dabei bewusst direkt auf dem Docker-Host und nicht in einem zusätzlichen Container.

Das vereinfacht den Zugriff auf Docker-Volumes und Stack-Verzeichnisse erheblich. Zusätzliche Bind-Mounts oder ein komplizierter Backup-Container sind nicht notwendig.

Borg und Borgmatic installieren

Auf einem Ubuntu- oder Debian-basierten Docker-Host:

sudo apt update
sudo apt install borgbackup borgmatic

Die installierten Versionen lassen sich anschließend prüfen:

borg --version
borgmatic --version

Auf dem Raspberry Pi benötigen wir lediglich BorgBackup:

sudo apt update
sudo apt install borgbackup

Borg-Repository auf dem Raspberry Pi erstellen

Auf dem Raspberry Pi erstellen wir zunächst ein eigenes Verzeichnis für das Repository:

sudo mkdir -p /backup/borg-vps

Das Verzeichnis sollte dem Benutzer gehören, über den später die SSH-Verbindung aufgebaut wird:

sudo chown -R backupuser:backupuser /backup/borg-vps

Anschließend wird das Repository initialisiert:

borg init --encryption=repokey-blake2 /backup/borg-vps

Dabei wird eine Passphrase für das verschlüsselte Repository festgelegt.

Die Passphrase unbedingt außerhalb des Docker-Hosts sicher aufbewahren. Ohne Repository-Schlüssel beziehungsweise Passphrase kann das verschlüsselte Backup im Ernstfall nicht wiederhergestellt werden.

SSH-Zugriff zum Backup-Server einrichten

Damit Borgmatic vollständig automatisch arbeiten kann, verwenden wir einen separaten SSH-Key.

Auf dem Docker-Host:

sudo ssh-keygen -t ed25519 -f /root/.ssh/borg_backup

Den öffentlichen Schlüssel anschließend auf den Raspberry Pi übertragen:

sudo ssh-copy-id \
  -i /root/.ssh/borg_backup.pub \
  backupuser@RASPBERRY-PI-IP

Die Verbindung testen:

sudo ssh \
  -i /root/.ssh/borg_backup \
  backupuser@RASPBERRY-PI-IP

Für vollständig automatische Backups darf der SSH-Key keine interaktiv erforderliche Passphrase besitzen.

Eine vorhandene Passphrase kann entfernt werden mit:

sudo ssh-keygen -p -f /root/.ssh/borg_backup

Als neue Passphrase wird dabei einfach nichts eingegeben.

Der private SSH-Key sollte ausschließlich für diesen Backup-Zweck verwendet und entsprechend geschützt werden.

Backup-Verbindung über WireGuard

Befinden sich Docker-Host und Raspberry Pi nicht im selben Netzwerk, bietet sich eine Verbindung über WireGuard an.

Der Aufbau sieht dann beispielsweise so aus:

Docker-Host
     │
     │ WireGuard
     ▼
Raspberry Pi
     │
     │ SSH
     ▼
Borg-Repository

In der Borgmatic-Konfiguration wird einfach die WireGuard-IP des Raspberry Pi verwendet.

Ein Vorteil dieser Lösung ist, dass der SSH-Dienst des Backup-Servers nicht öffentlich aus dem Internet erreichbar sein muss.

Borgmatic konfigurieren

Zunächst erstellen wir das Konfigurationsverzeichnis:

sudo mkdir -p /etc/borgmatic

Je nach Installation kann anschließend eine Beispielkonfiguration erzeugt werden.

Die zentrale Konfiguration befindet sich normalerweise unter:

/etc/borgmatic/config.yaml

Docker-Stack-Verzeichnisse sichern

Angenommen, sämtliche Docker-Stacks befinden sich unter:

/home/USERNAME/docker/

Dann kann das komplette Verzeichnis gesichert werden:

source_directories:
  - /home/USERNAME/docker

Dadurch landen unter anderem folgende Dateien im Backup:

docker/
├── wordpress-stack/
│   ├── compose.yml
│   ├── .env
│   └── config/
├── authentik-stack/
├── grafana-stack/
├── pihole-stack/
├── traefik-stack/
└── ...

Damit werden auch .env-Dateien und Bind-Mounts innerhalb der Stack-Verzeichnisse gesichert.

Da .env-Dateien häufig Zugangsdaten enthalten, ist die Verschlüsselung des Borg-Repositories besonders wichtig.

Docker-Volumes sichern

Persistente Docker-Volumes befinden sich bei einer Standardinstallation normalerweise unter:

/var/lib/docker/volumes/

Die vorhandenen Volumes lassen sich anzeigen mit:

docker volume ls

Den tatsächlichen Mountpoint eines Volumes zeigt:

docker volume inspect VOLUME-NAME \
  --format '{{.Mountpoint}}'

Relevante Volumes können anschließend gezielt in Borgmatic aufgenommen werden:

source_directories:
  - /home/USERNAME/docker

  - /var/lib/docker/volumes/wordpress-data/_data

  - /var/lib/docker/volumes/grafana-stack_grafana-data/_data
  - /var/lib/docker/volumes/grafana-stack_loki-data/_data
  - /var/lib/docker/volumes/grafana-stack_prometheus-data/_data

Nicht jedes Volume muss zwingend gesichert werden.

Redis-Volumes enthalten beispielsweise häufig lediglich Cache-Daten. Diese können nach einer Wiederherstellung automatisch neu aufgebaut werden.

Auch historische Prometheus- oder Loki-Daten sind optional, sofern die Monitoring-Historie nicht benötigt wird.

Datenbanken nicht einfach im laufenden Betrieb kopieren

Bei MySQL und PostgreSQL gibt es einen wichtigen Punkt.

Die Dateien eines laufenden Datenbank-Volumes können sich während des Backups verändern. Ein reines Datei-Backup des laufenden Volumes ist deshalb nicht die ideale Methode für eine konsistente Datenbanksicherung.

Stattdessen erstellen wir vor jedem Borg-Backup einen SQL-Dump:

WordPress
    │
    ▼
   MySQL
    │
    └── mysqldump
            │
            ▼
      wordpress.sql


Authentik
    │
    ▼
PostgreSQL
    │
    └── pg_dump
            │
            ▼
      authentik.sql

Die Anwendungen können dabei weiterlaufen.

Verzeichnis für Datenbank-Dumps erstellen

Auf dem Docker-Host:

sudo mkdir -p /var/backups/borgmatic/databases
sudo chmod 700 /var/backups/borgmatic/databases

Dieses Verzeichnis wird ebenfalls in Borgmatic aufgenommen:

source_directories:
  - /home/USERNAME/docker
  - /var/backups/borgmatic/databases

WordPress-MySQL sichern

Der MySQL-Dump wird direkt innerhalb des laufenden Datenbankcontainers erzeugt:

docker exec wordpress-db sh -c \
  'mysqldump --single-transaction --quick --no-tablespaces \
  -u"$MYSQL_USER" -p"$MYSQL_PASSWORD" "$MYSQL_DATABASE"' \
  > /var/backups/borgmatic/databases/wordpress.sql

Die verwendeten Optionen haben einen bestimmten Zweck.

`--single-transaction`

Für InnoDB-Tabellen wird ein konsistenter Snapshot erzeugt, ohne die Datenbank für die komplette Dauer des Dumps sperren zu müssen.

`--quick`

Die Tabellen werden zeilenweise gelesen, wodurch der Speicherverbrauch reduziert wird.

`--no-tablespaces`

Dadurch wird unter anderem verhindert, dass der verwendete Datenbankbenutzer für den Dump ein globales PROCESS-Privileg benötigt.

Die mögliche Warnung:

Using a password on the command line interface can be insecure.

ist in diesem Fall eine MySQL-Warnung. Das Passwort wird aus der bereits im Container vorhandenen Umgebungsvariable gelesen.

Authentik-PostgreSQL sichern

Für PostgreSQL verwenden wir pg_dump:

docker exec authentik-database sh -c \
  'PGPASSWORD="$POSTGRES_PASSWORD" \
  pg_dump -U "$POSTGRES_USER" "$POSTGRES_DB"' \
  > /var/backups/borgmatic/databases/authentik.sql

Auch hier stammen Benutzername, Passwort und Datenbankname aus den bereits im Datenbankcontainer vorhandenen Umgebungsvariablen.

Datenbank-Dumps mit Borgmatic automatisieren

Jetzt lassen wir Borgmatic beide Dumps automatisch vor jedem Backup erzeugen.

Dafür verwenden wir Command-Hooks:

commands:

  - before: action
    when: [create]
    run:
      - >
        docker exec wordpress-db sh -c
        'mysqldump --single-transaction --quick --no-tablespaces
        -u"$MYSQL_USER" -p"$MYSQL_PASSWORD" "$MYSQL_DATABASE"'
        > /var/backups/borgmatic/databases/wordpress.sql

      - >
        docker exec authentik-database sh -c
        'PGPASSWORD="$POSTGRES_PASSWORD"
        pg_dump -U "$POSTGRES_USER" "$POSTGRES_DB"'
        > /var/backups/borgmatic/databases/authentik.sql

  - after: action
    when: [create]
    run:
      - rm -f /var/backups/borgmatic/databases/wordpress.sql
      - rm -f /var/backups/borgmatic/databases/authentik.sql

Der Ablauf ist damit vollständig automatisiert:

Borgmatic startet
       │
       ▼
WordPress-Dump erstellen
       │
       ▼
Authentik-Dump erstellen
       │
       ▼
Borg-Backup erstellen
       │
       ▼
SQL-Dumps befinden sich im Archiv
       │
       ▼
temporäre SQL-Dateien löschen

Dadurch liegen die unverschlüsselten SQL-Dumps nicht dauerhaft auf dem Docker-Host.

Datenbank-Volumes zusätzlich sichern?

Grundsätzlich gibt es zwei Möglichkeiten.

Variante 1: SQL-Dump

Die Datenbank selbst wird über mysqldump beziehungsweise pg_dump gesichert.

Das ist portabel und eignet sich gut für eine saubere Wiederherstellung in eine frisch initialisierte Datenbank.

Variante 2: SQL-Dump und Datenbank-Volume

Zusätzlich zum SQL-Dump wird das komplette Datenbank-Volume gesichert.

Damit existiert ein weiterer Wiederherstellungsweg, allerdings werden Daten teilweise doppelt gesichert.

Für ein übersichtliches Backup-Konzept kann es sinnvoll sein, sich bei den eigentlichen Datenbanken auf die getesteten SQL-Dumps zu verlassen.

Repository in Borgmatic eintragen

Das entfernte Repository kann beispielsweise folgendermaßen konfiguriert werden:

repositories:
  - path: ssh://backupuser@RASPBERRY-PI-IP/backup/borg-vps

ssh_command: ssh -i /root/.ssh/borg_backup

Die Borg-Passphrase sollte nicht direkt in der Konfiguration stehen.

Beispielsweise kann sie gespeichert werden unter:

/root/.config/borgmatic/passphrase

Berechtigungen setzen:

sudo chmod 600 /root/.config/borgmatic/passphrase

In Borgmatic:

encryption_passcommand: cat /root/.config/borgmatic/passphrase

Wichtig: Eine zusätzliche Kopie der Passphrase sollte an einem sicheren Ort außerhalb des Docker-Hosts vorhanden sein.

Aufbewahrungsstrategie

Eine mögliche Retention ist:

keep_daily: 7
keep_weekly: 4
keep_monthly: 6

Damit bleiben mehrere tägliche, wöchentliche und monatliche Wiederherstellungspunkte erhalten.

Die Werte können selbstverständlich an den verfügbaren Speicherplatz und die eigenen Anforderungen angepasst werden.

Borg-Backups sind dedupliziert

Borg arbeitet mit Deduplizierung.

Das bedeutet: Jedes Archiv verhält sich bei einer Wiederherstellung wie ein vollständiger Backup-Stand. Bereits vorhandene Datenblöcke werden jedoch nicht erneut gespeichert.

Vereinfacht:

Backup 1
1 GB Daten
     │
     ▼
~1 GB neue Daten


Backup 2
nur 20 MB verändert
     │
     ▼
hauptsächlich ~20 MB zusätzlich


Backup 3
nur 10 MB verändert
     │
     ▼
hauptsächlich ~10 MB zusätzlich

Dadurch können viele Wiederherstellungspunkte aufbewahrt werden, ohne für jedes Archiv den kompletten Datenbestand erneut speichern zu müssen.

Borgmatic-Konfiguration überprüfen

Bevor das erste Backup gestartet wird:

sudo borgmatic config validate

Wenn keine Fehler auftreten:

sudo borgmatic create --verbosity 1 --stats

Für einen vollständigen Borgmatic-Lauf:

sudo borgmatic --verbosity 1

Vorhandene Backups anzeigen

Die Archive lassen sich anzeigen mit:

sudo borgmatic list

Weitere Informationen:

sudo borgmatic info

Interessant sind dabei insbesondere Werte wie:

Original size
Compressed size
Deduplicated size

Tatsächlichen Speicherverbrauch prüfen

Auf dem Raspberry Pi lässt sich der reale Speicherverbrauch des gesamten Borg-Repositories anzeigen:

du -sh /backup/borg-vps

Dieser Wert ist besonders interessant, weil hier Deduplizierung und Kompression bereits berücksichtigt sind.

Gelöschte Borg-Archive und `compact`

Beim Testen kann eine Besonderheit von Borg zunächst verwirrend wirken.

Nach dem Löschen mehrerer Archive kann das Repository weiterhin fast genauso groß sein wie vorher.

Der Grund: Das Löschen eines Archivs bedeutet nicht zwangsläufig, dass die nicht mehr referenzierten Datenblöcke sofort physisch aus dem Repository entfernt werden.

Dafür gibt es:

sudo borgmatic compact

Anschließend erneut auf dem Backup-Server prüfen:

du -sh /backup/borg-vps

Jetzt sollte nicht mehr benötigter Speicherplatz tatsächlich freigegeben worden sein.

Gerade nach dem Löschen größerer Testarchive kann der Unterschied erheblich sein.

Automatische Backups mit systemd

Bei einer Installation über die Paketverwaltung werden häufig bereits systemd-Units für Borgmatic mitgeliefert.

Prüfen:

systemctl list-unit-files | grep borgmatic

Typischerweise erscheinen:

borgmatic.service
borgmatic.timer

Den Timer aktivieren:

sudo systemctl enable --now borgmatic.timer

Den nächsten geplanten Lauf anzeigen:

systemctl list-timers borgmatic.timer --all

Ein Standard-Timer kann beispielsweise folgendermaßen aussehen:

[Timer]
OnCalendar=daily
Persistent=true
RandomizedDelaySec=3h

Damit wird Borgmatic täglich ausgeführt.

RandomizedDelaySec sorgt dafür, dass die tatsächliche Startzeit innerhalb des angegebenen Zeitraums zufällig verschoben wird.

Warum wartet `borgmatic.service` eine Minute?

Beim manuellen Start:

sudo systemctl start borgmatic.service

kann der Status zunächst beispielsweise Folgendes anzeigen:

Active: activating (start-pre)

und:

sleep 1m

Das bedeutet nicht, dass Borgmatic hängt.

In der mitgelieferten systemd-Unit kann folgende Einstellung vorhanden sein:

ExecStartPre=sleep 1m

Dadurch wartet der Service vor dem eigentlichen Backup eine Minute.

Wer diese Verzögerung nicht benötigt, kann einen Override erstellen:

sudo systemctl edit borgmatic.service

Eintragen:

[Service]
ExecStartPre=

Anschließend:

sudo systemctl daemon-reload

Der Borgmatic-Service startet danach ohne diese zusätzliche Wartezeit.

Automatische Backups kontrollieren

Den Status des letzten Borgmatic-Laufs zeigt:

systemctl status borgmatic.service

Die Logs können über das systemd-Journal angezeigt werden:

journalctl -u borgmatic.service

Für die letzten 100 Zeilen:

journalctl -u borgmatic.service -n 100 --no-pager

Zusätzlich sollte kontrolliert werden, ob tatsächlich ein neues Borg-Archiv angelegt wurde:

sudo borgmatic list

Wiederherstellung in der Praxis testen

Ein erfolgreicher Backup-Lauf allein beweist noch nicht, dass sich die Daten später wirklich wiederherstellen lassen.

Deshalb sollte mindestens einmal ein echter Restore-Test durchgeführt werden.

Dafür muss der produktive Server nicht neu installiert werden.

Wir extrahieren zunächst ein Borg-Archiv in ein separates Verzeichnis.

Borg-Archiv in ein Testverzeichnis extrahieren

Zunächst die vorhandenen Archive anzeigen:

sudo borgmatic list

Testverzeichnis erstellen:

sudo mkdir -p /restore-test

Gewünschtes Archiv extrahieren:

sudo borgmatic extract \
  --archive ARCHIVNAME \
  --destination /restore-test

Dadurch werden die produktiven Dateien nicht verändert.

Die Größe des Restores prüfen:

sudo du -sh /restore-test

Wiederhergestellte Dateien kontrollieren

Die .env-Dateien lassen sich beispielsweise suchen mit:

sudo find /restore-test/home/USERNAME/docker \
  -name '.env' -type f

Die Datenbank-Dumps sollten hier vorhanden sein:

sudo ls -lh \
  /restore-test/var/backups/borgmatic/databases/

Beispielsweise:

authentik.sql
wordpress.sql

Auch die gesicherten Docker-Volumes befinden sich unter ihren ursprünglichen Pfaden innerhalb des Restore-Verzeichnisses.

Beispielsweise:

/restore-test/var/lib/docker/volumes/wordpress-data/_data/

Eine schnelle Prüfung:

sudo find /restore-test -name wp-config.php -print

und:

sudo find /restore-test -type d -name wp-content -print

Vor dem echten Restore eine zusätzliche Sicherheitskopie erstellen

Soll die Wiederherstellung auf dem laufenden Server getestet werden, empfiehlt sich zunächst eine temporäre Sicherheitskopie des aktuellen Zustands.

Beispielsweise WordPress stoppen:

cd /home/USERNAME/docker/wordpress-stack
docker compose stop

WordPress-Dateivolume sichern:

sudo tar \
  -C /var/lib/docker/volumes/wordpress-data/_data \
  -czpf /root/wordpress-data-before-restore.tar.gz .

Optional auch das aktuelle MySQL-Volume:

sudo tar \
  -C /var/lib/docker/volumes/wordpress-mysql-data/_data \
  -czpf /root/wordpress-mysql-before-restore.tar.gz .

Die TAR-Dateien anschließend unbedingt kontrollieren:

sudo tar -tzf \
  /root/wordpress-data-before-restore.tar.gz | head

Damit existiert ein Rückweg, falls beim Restore-Test etwas schiefgeht.

WordPress aus Borg wiederherstellen

Das bestehende WordPress-Dateivolume wird zunächst geleert:

sudo find /var/lib/docker/volumes/wordpress-data/_data \
  -mindepth 1 -delete

Anschließend die Dateien aus dem Borg-Restore zurückkopieren:

sudo rsync -aHAX \
  /restore-test/var/lib/docker/volumes/wordpress-data/_data/ \
  /var/lib/docker/volumes/wordpress-data/_data/

Damit sind unter anderem wieder vorhanden:

wp-admin
wp-content
wp-includes
wp-config.php

WordPress-Datenbank wiederherstellen

Für einen vollständigen Restore-Test kann die bestehende MySQL-Datenbank entfernt beziehungsweise das vorher gesicherte Datenbank-Volume geleert werden.

Nur durchführen, wenn vorher eine funktionierende Sicherheitskopie erstellt wurde.

sudo find /var/lib/docker/volumes/wordpress-mysql-data/_data \
  -mindepth 1 -delete

Anschließend zunächst nur die Datenbank starten:

docker compose up -d db

Die Logs beobachten:

docker logs -f wordpress-db

Sobald MySQL bereit ist, wird der SQL-Dump importiert:

sudo cat \
  /restore-test/var/backups/borgmatic/databases/wordpress.sql | \
docker exec -i wordpress-db sh -c \
'mysql -u"$MYSQL_USER" -p"$MYSQL_PASSWORD" "$MYSQL_DATABASE"'

Anschließend prüfen, ob die Tabellen vorhanden sind:

docker exec wordpress-db sh -c \
'mysql -u"$MYSQL_USER" -p"$MYSQL_PASSWORD" "$MYSQL_DATABASE" \
-e "SHOW TABLES;"'

Danach den kompletten WordPress-Stack starten:

docker compose up -d

Nun sollte die Website getestet werden.

Insbesondere:

Startseite
Beiträge
Medien
Benutzer
Plugins
Theme
Einstellungen
WordPress-Backend

Wenn die Website vollständig funktioniert, wurde WordPress erfolgreich aus Borg-Volume + SQL-Dump wiederhergestellt.

Authentik-Restore testen

Dasselbe Prinzip lässt sich für Authentik verwenden.

Zunächst den Stack stoppen:

cd /home/USERNAME/docker/authentik-stack
docker compose stop

Das aktuelle PostgreSQL-Volume als Rückfall sichern:

sudo tar \
  -C /var/lib/docker/volumes/authentik-stack_database/_data \
  -czpf /root/authentik-database-before-restore.tar.gz .

Archiv kontrollieren:

sudo tar -tzf \
  /root/authentik-database-before-restore.tar.gz | head

Danach kann das PostgreSQL-Volume für den Test geleert werden:

sudo find /var/lib/docker/volumes/authentik-stack_database/_data \
  -mindepth 1 -delete

PostgreSQL neu starten

Zunächst nur den Datenbank-Service starten:

docker compose up -d database

Die Logs beobachten:

docker logs -f authentik-database

Sobald PostgreSQL meldet, dass Verbindungen angenommen werden können, kann der Dump importiert werden.

Authentik-Datenbank importieren

Der Restore erfolgt mit:

sudo cat \
  /restore-test/var/backups/borgmatic/databases/authentik.sql | \
docker exec -i authentik-database sh -c \
'PGPASSWORD="$POSTGRES_PASSWORD" \
psql -U "$POSTGRES_USER" "$POSTGRES_DB"'

Anschließend können die Tabellen geprüft werden:

docker exec authentik-database sh -c \
'PGPASSWORD="$POSTGRES_PASSWORD" \
psql -U "$POSTGRES_USER" "$POSTGRES_DB" -c "\dt"'

Wenn die Tabellen vorhanden sind, wird Authentik vollständig gestartet:

docker compose up -d

Anschließend sollten insbesondere folgende Bereiche kontrolliert werden:

Anmeldung
Benutzer
Gruppen
Applications
Provider
Outposts
Policies
Forward-Auth-Funktion

Funktioniert Authentik anschließend wieder vollständig, ist auch der PostgreSQL-Restore erfolgreich getestet.

Was der Restore-Test tatsächlich beweist

Damit wurde die komplette Backup-Kette praktisch getestet:

Docker-Host
     │
     ├── Stack-Dateien
     ├── Docker-Volumes
     └── Datenbank-Dumps
              │
              ▼
          Borgmatic
              │
              ▼
       verschlüsseltes
        Borg-Repository
              │
              ▼
           Restore
              │
       ┌──────┴──────┐
       ▼             ▼
Docker-Volumes    SQL-Dumps
       │             │
       └──────┬──────┘
              ▼
        Docker-Stacks
              │
              ▼
      Anwendungen laufen

Damit wissen wir nicht nur, dass Borg Dateien gespeichert hat.

Wir haben tatsächlich nachgewiesen, dass sich die Anwendungen aus diesen Daten wiederherstellen lassen.

Nach dem Restore-Test aufräumen

Nach erfolgreichem Test sollte das temporäre Restore-Verzeichnis entfernt werden:

sudo rm -rf /restore-test

Das ist auch aus Sicherheitsgründen wichtig.

Innerhalb des Verzeichnisses befinden sich unter anderem:

.env-Dateien
Datenbank-Dumps
Konfigurationsdateien
möglicherweise weitere Zugangsdaten

Das Borg-Repository selbst ist verschlüsselt. Die extrahierten Dateien unter /restore-test sind es dagegen nicht automatisch.

Die zusätzlichen TAR-Sicherungen können zunächst noch aufbewahrt werden.

Nach einigen erfolgreichen automatischen Borgmatic-Läufen können auch diese gelöscht werden.

Bootstrap-Backup für den Totalausfall

Ein weiterer wichtiger Punkt ist der Zugriff auf das Borg-Repository selbst.

Wenn der komplette Docker-Host verloren geht, benötigt man einige Informationen bereits vor dem eigentlichen Borg-Restore.

Deshalb empfiehlt sich ein kleines separates Bootstrap-Backup.

Darin können beispielsweise enthalten sein:

WireGuard-Konfiguration
Borgmatic-Konfiguration
SSH-Key für den Backup-Server
Borg-Repository-Passphrase
Firewall-/UFW-Konfiguration
wichtige Recovery-Dokumentation

Dieses Bootstrap-Backup sollte selbstverständlich ebenfalls sicher und verschlüsselt aufbewahrt werden.

Der Disaster-Recovery-Ablauf sieht dann ungefähr so aus:

Neuer Server
     │
     ▼
Docker, Borg, Borgmatic
und WireGuard installieren
     │
     ▼
Bootstrap-Konfiguration
wiederherstellen
     │
     ├── WireGuard
     ├── SSH-Key
     ├── Borgmatic
     └── Borg-Passphrase
             │
             ▼
      Raspberry Pi erreichbar
             │
             ▼
       Borg-Repository
             │
             ▼
      Hauptbackup einspielen
             │
       ┌─────┴─────┐
       ▼           ▼
    Volumes     SQL-Dumps
       │           │
       └─────┬─────┘
             ▼
       Docker starten

Damit ist man nicht darauf angewiesen, dass wichtige Zugangsdaten ausschließlich auf dem ausgefallenen Server gespeichert waren.

Fazit

Ein Docker Backup mit Borgmatic und BorgBackup lässt sich vergleichsweise schlank aufbauen, ohne dafür einen komplexen zusätzlichen Backup-Stack betreiben zu müssen.

Borgmatic läuft direkt auf dem Docker-Host und sichert:

Docker-Stack-Verzeichnisse
compose.yml
.env-Dateien
Konfigurationsdateien
Bind-Mounts
wichtige Docker-Volumes
MySQL-Dumps
PostgreSQL-Dumps

Borg übernimmt anschließend:

Verschlüsselung
Deduplizierung
Kompression
mehrere Wiederherstellungspunkte
Retention
Repository-Verwaltung

Die Übertragung kann verschlüsselt per SSH und beispielsweise vollständig über ein privates WireGuard-Netz erfolgen.

Besonders wichtig ist jedoch der letzte Schritt: der echte Restore-Test.

Erst nachdem sowohl WordPress als auch eine PostgreSQL-basierte Anwendung tatsächlich aus den Borg-Daten und SQL-Dumps wiederhergestellt wurden, ist nachgewiesen, dass das Backup-Konzept im Ernstfall funktioniert.

Ein erfolgreiches Backup ist gut.

Ein erfolgreich wiederhergestelltes Backup ist besser.

Docker-Backups mit Borgmatic und Borg – inklusive Datenbank-Dumps und Restore-Test