UGREEN NAS Docker-Daten richtig sichern: Auszug, Stopp, restic

Auf vielen UGREEN NAS laufen Docker-Container: ein Passwortmanager, eine Hausautomation, ein Mailarchiv, ein Medienserver. Deren Daten einfach mitzukopieren klingt naheliegend, geht aber oft schief. Eine Datenbank, die während der Kopie schreibt, landet halbfertig in der Sicherung und lässt sich später nicht öffnen. Diese Anleitung zeigt Schritt für Schritt, wie Sie Docker-Daten auf der UGREEN NAS so sichern, dass sie sich auch wiederherstellen lassen. Grundlage ist ein Aufbau, der auf unserer NAS seit Mitte Oktober jede Nacht läuft.

Die Screenshots, Befehle und Abläufe stammen von einer UGREEN DXP4800 Pro mit UGOS Pro 1.21.0.0190. Namen, Adressen und Zugangsdaten sind entfernt oder durch Beispiele ersetzt.

Voraussetzungen

• Ein Konto mit Administratorrechten und SSH-Zugang, siehe Teil 52
• Docker-Stacks mit Compose-Dateien, siehe Docker-Grundlagen
• Ein Sicherungsziel, siehe Teil 53
• Etwa 45 Minuten

Schritt 1: Die Docker-Daten an einem Ort sammeln

Öffnen Sie die App Docker. Die Übersicht zeigt, wie viele Projekte und Container laufen.

Auf unserer NAS laufen 26 Projekte mit 38 Containern, zusammen gut 20 GB Daten. Damit eine Sicherung das alles erfasst, gilt eine einfache Regel: Jeder Stack bekommt einen eigenen Ordner im freigegebenen Ordner docker, und darin liegen die Compose-Datei, die Umgebungsdatei und alle Daten des Containers als Bind-Mount, also etwa ./data oder ./config. Dann reicht es, den Ordner docker zu sichern, und jeder Stack lässt sich aus seinem Ordner neu starten.

Benannte Docker-Volumes, die Docker selbst verwaltet, liegen dagegen unter dem internen Docker-Verzeichnis und fallen leicht aus der Sicherung. Stellen Sie solche Volumes deshalb auf Bind-Mounts im Stack-Ordner um. Pfad und Inhalt des Projekts sehen Sie in der App Docker unter Projekt.

Verifizieren: Jeder Stack hat einen eigenen Ordner, und alle Daten liegen darin.

Schritt 2: Datenbanken richtig erfassen

Das ist der wichtigste Punkt. Datenbanken wie MariaDB, PostgreSQL oder SQLite halten Daten im Arbeitsspeicher und schreiben laufend. Eine Dateikopie im falschen Moment ist inkonsistent. Es gibt zwei sichere Wege.

Weg 1: ein sauberer Auszug. Lassen Sie die Datenbank vor der Sicherung einen Auszug schreiben. Für MariaDB nutzen wir diesen Befehl, bei MySQL heißt das Programm mysqldump. Er liest Benutzer und Passwort aus der Umgebung des Datenbankcontainers, so landen keine Zugangsdaten im Skript:

docker exec mailarchiv-db sh -c 'exec mariadb-dump --single-transaction --quick -u"$MYSQL_USER" -p"$MYSQL_PASSWORD" "$MYSQL_DATABASE"' | gzip > /dumps/mailarchiv.sql.gz

Die Option --single-transaction erzeugt bei InnoDB-Tabellen, dem Standard, einen konsistenten Stand, ohne die Datenbank anzuhalten. Für PostgreSQL ist pg_dump das Gegenstück. Viele kleine Dienste wie Nginx Proxy Manager, Uptime Kuma oder Homarr nutzen SQLite. Für sie kopiert sqlite3 die Datenbank sicher im laufenden Betrieb:

sqlite3 "file:/pfad/database.sqlite?mode=ro" ".timeout 20000" ".backup '/dumps/npm.db'"

Prüfen Sie den Auszug, bevor Sie den alten ersetzen. Unser Skript schreibt zuerst in eine Datei mit der Endung .neu, prüft die Mindestgröße und benennt sie erst dann um. So bleibt bei einem Fehler der letzte gute Auszug erhalten.

Weg 2: den Stack kurz stoppen. Für Dienste ohne Auszugsbefehl stoppen Sie den Stack, sichern den Ordner und starten ihn wieder.

In der App Docker geht das unter Projekt mit Beenden und danach Starten. In einem Skript nutzen Sie dafür docker compose stop und docker compose start im Stack-Ordner. Das kostet einige Minuten Ausfall, deshalb läuft so eine Sicherung am besten nachts.

Verifizieren: Für jede Datenbank liegt ein frischer Auszug im Sicherungsbereich, oder der Stack wird zur Sicherung gestoppt.

Schritt 3: Unnötiges ausschließen

Laufende Datenbankdateien, für die ein Auszug vorliegt, gehören nicht noch einmal in die Sicherung. Dasselbe gilt für Zwischenspeicher, die sich neu erzeugen lassen. Ein Auszug nach dem Muster unserer Ausschlussliste:

# Laufende Datenbankdateien: stattdessen liegt ein sauberer Auszug vor
/quelle/docker/mailarchiv/db
# Plex: Zwischenspeicher, lässt sich neu erzeugen
/quelle/docker/plex/config/Library/Application Support/Plex Media Server/Cache
/quelle/docker/plex/transcode
# Suchindex: wird aus Speicher und Datenbank neu aufgebaut
/quelle/docker/mailarchiv/manticore
# Papierkörbe
/quelle/docker/*/#recycle

Das spart Platz und Zeit, und die Sicherung enthält nur, was sich nicht anders wiederherstellen lässt.

Verifizieren: Die Ausschlussliste nennt Datenbankdateien mit Auszug, Zwischenspeicher und Papierkörbe.

Schritt 4: Den Docker-Ordner sichern

Für den Ordner docker eignen sich zwei Wege. Mit Bordmitteln sichern Sie ihn in Sync & Backup auf eine USB-Platte oder eine zweite NAS, wie in Teil 53 beschrieben. Die Auszüge erzeugt dann ein Skript, das kurz vorher per Zeitplan läuft.

Wir nutzen restic in eigenen Containern. restic sichert verschlüsselt, komprimiert, mit Ständen und überträgt nach dem ersten Lauf nur Änderungen. Bei uns arbeiten zwei Sicherungen zusammen: Ein Container sichert sonntags den ganzen Docker-Ordner und die Freigabe Daten auf eine zweite NAS und behält acht Wochen-, zwölf Monats- und drei Jahresstände. Ein zweiter sichert jede Nacht um 2:00 Uhr ausgewählte Ordner samt den Datenbank-Auszügen außer Haus und behält zusätzlich sieben Tagesstände.

Ein vereinfachtes Beispiel für den Container, der den Docker-Ordner sichert:

services:
  sicherung:
    image: restic/restic:0.17.3
    entrypoint: ["/bin/sh", "/scripts/start.sh"]
    env_file: .env
    volumes:
      - ./scripts:/scripts:ro
      - ./data:/data
      - ./dumps:/dumps
      - ./wiederherstellen:/wiederherstellen
      - /volume2/docker:/quelle/docker:ro
      - /var/run/docker.sock:/var/run/docker.sock

Das restic-Abbild bringt weder sqlite3 noch die Docker-Befehle mit. Unser start.sh lädt sie deshalb beim Start mit apk add --no-cache sqlite docker-cli nach, lädt den Zeitplan aus /scripts und startet crond im Vordergrund. Über den eingebundenen Docker-Socket kann das Skript mit docker exec die Auszüge in den Datenbankcontainern erzeugen. Bedenken Sie: Wer den Docker-Socket hat, hat praktisch Root-Rechte auf der NAS, daran ändert auch ein :ro nichts. Binden Sie ihn nur in Container ein, denen Sie vertrauen, oder erzeugen Sie die Auszüge per Zeitplan direkt auf der NAS.

Passwort und Ziel des Repositorys stehen in der Datei .env, die nur root lesen darf, und zusätzlich im Passwortmanager. Ohne dieses Passwort ist die Sicherung wertlos. Ein Aufruf zum Sichern und Ausdünnen sieht zum Beispiel so aus:

restic backup /quelle/docker /dumps --exclude-file=/scripts/ausschluss.txt --exclude-caches
restic forget --prune --keep-weekly 8 --keep-monthly 12 --keep-yearly 3

Die zweite Zeile dünnt alte Stände aus. Einmal pro Woche prüft restic check das Repository.

Verifizieren: Nach dem ersten Lauf listet restic snapshots einen Stand mit dem Docker-Ordner.

Schritt 5: Die Reihenfolge im Zeitplan festlegen

Auszug und Sicherung müssen in der richtigen Reihenfolge laufen, sonst landet ein Auszug vom Vortag in der Sicherung. Bei uns schreibt der eine Container den Auszug, der andere bindet den Ordner mit den Auszügen lesend ein und sichert ihn mit:

# Container 1, Auszug
40 1 * * *     /scripts/dump.sh   >> /data/logs/dump.log 2>&1
# Container 2, Sicherung außer Haus
0 2 * * *      /scripts/backup.sh >> /data/logs/backup.log 2>&1

Der Auszug läuft um 1:40 Uhr, die Sicherung um 2:00 Uhr. Zwanzig Minuten Abstand reichen für unsere Datenbanken bequem. Noch sicherer ist es, beides in einem Skript nacheinander aufzurufen und die Sicherung abzubrechen, wenn der Auszug fehlschlägt. Achten Sie auch darauf, dass zur gleichen Zeit keine anderen schweren Aufgaben laufen, etwa ein Datenträgerabgleich des RAID oder eine Sicherung zwischen Speicherpools.

Ein Wort zu den Rechten: Viele Container schreiben ihre Dateien als root oder mit eigenen Benutzernummern. Der Sicherungscontainer muss diese Dateien lesen dürfen. Das restic-Abbild läuft als root, und die Quellen sind mit :ro nur lesend eingebunden.

Verifizieren: Im Protokoll steht jede Nacht zuerst der Auszug und danach die Sicherung.

Schritt 6: Snapshots als schnelle Ergänzung

Für den freigegebenen Ordner docker lassen sich in der App Snapshot auch Momentaufnahmen anlegen.

Ein Snapshot vor einem Update eines Containers ist eine gute Absicherung: Geht das Update schief, holen Sie den alten Stand in Minuten zurück. Für Datenbanken gilt aber dasselbe wie bei der Sicherung, ein Snapshot im laufenden Betrieb ist nur so konsistent wie ein Stromausfall. Für wichtige Dienste stoppen Sie den Stack vor dem Snapshot kurz. Wie Snapshots funktionieren, zeigt Teil 21.

Verifizieren: Vor größeren Updates legen Sie einen Snapshot des Ordners docker an.

Schritt 7: Wiederherstellung üben

Schreiben Sie für jeden wichtigen Dienst auf, wie er zurückkommt, und testen Sie es einmal. Bei uns liegt dafür eine Datei WIEDERHERSTELLEN.md im Stack-Ordner. Der Ablauf für einen einzelnen Dienst:

1. Den Stand des Stack-Ordners aus der Sicherung in einen leeren Ordner zurückholen, bei restic etwa mit restic restore latest --target /wiederherstellen --include '/quelle/docker/stackname'.
2. Den Stack stoppen und seinen Ordner durch den zurückgeholten ersetzen.
3. Bei Datenbanken den Auszug in eine leere Datenbank einspielen, bei MariaDB etwa mit gunzip -c mailarchiv.sql.gz | docker exec -i mailarchiv-db sh -c 'exec mariadb -u"$MYSQL_USER" -p"$MYSQL_PASSWORD" "$MYSQL_DATABASE"'.
4. Den Stack starten und prüfen, ob der Dienst seine Daten zeigt.

Laufen Sie das einmal mit einem unwichtigen Dienst durch, bevor Sie es im Ernstfall mit dem wichtigsten brauchen.

Verifizieren: Ein Testdienst läuft nach der Wiederherstellung mit seinen Daten.

Typische Fehler

Fehler	Folge und Lösung
Laufende Datenbank kopiert	Sicherung lässt sich nicht öffnen. Auszug erzeugen oder Stack stoppen.
Benannte Volumes	Daten fehlen in der Sicherung. Auf Bind-Mounts im Stack-Ordner umstellen.
Passwort nur in der Sicherung	Repository nicht mehr lesbar. Passwort im Passwortmanager ablegen.
Zwischenspeicher mitgesichert	Sicherung unnötig groß und langsam. Ausschlussliste pflegen.
Auszug schlägt still fehl	Alter oder leerer Auszug in der Sicherung. Größe prüfen und Fehler melden lassen.

Häufige Fragen

Muss ich die Images sichern?

Nein. Fehlt ein Image, lädt Docker es beim nächsten docker compose up aus der Registry. Wichtig sind Compose-Datei, Umgebungsdatei und Daten. Wer eine bestimmte Version braucht, legt sie in der Compose-Datei fest.

Wie erfahre ich, ob die Sicherung lief?

Lassen Sie das Skript nach jedem Lauf eine Nachricht schicken oder einen Monitoring-Dienst anpingen. Wir nutzen dafür einen Push-Monitor in Uptime Kuma und bei Fehlern eine Nachricht aufs Handy. Bleibt die Meldung aus, fällt das sofort auf.

Reichen Sicherungen auf derselben NAS?

Nein. Eine Kopie gehört nach der 3-2-1-Regel außer Haus, siehe Teil 53. restic kann direkt in einen Objektspeicher in der Cloud sichern.

Fazit

Docker-Daten richtig zu sichern heißt vor allem, Datenbanken nicht im Flug zu kopieren. Mit einem Ordner pro Stack, sauberen Auszügen, einer Ausschlussliste und einem Werkzeug wie restic wird aus einem Haufen Container-Ordner eine Sicherung, aus der jeder Dienst zurückkommt. Prüfen Sie das mit einem Probelauf.

Weiterführende Anleitungen und Quellen

• Teil 53: 3-2-1-Backup
• Teil 62: Wiederherstellung testen
• Teil 52: SSH einrichten
• restic-Dokumentation
• MariaDB: mariadb-dump