UGREEN NAS: Verschlüsselte Sicherung mit restic zu Hetzner
Teil 55 der UGREEN-Serie: verschlüsselte Sicherung außer Haus mit restic im Docker-Container, Hetzner Object Storage mit Object Lock, Zeitplan, Aufräumen und Wiederherstellen.
Mit KI erstellt – redaktionelle Prüfung ausstehend
Werbung Mit * markierte Links sind Werbelinks: Bei einem Kauf erhalten wir eine Provision, der Preis bleibt gleich. Als Amazon-Partner verdiene ich an qualifizierten Verkäufen. Mehr dazu
Eine Sicherung im selben Haus hilft nicht bei Brand, Einbruch oder Überspannung. Für die Kopie außer Haus eignet sich restic: Es verschlüsselt auf der NAS, bevor etwas das Haus verlässt, speichert nur Geändertes und hält viele Versionen vor. Als Ziel nutzen wir Hetzner Object Storage, einen S3-Speicher mit Rechenzentren in Deutschland. Diese Anleitung zeigt den kompletten Aufbau als Docker-Projekt auf einer UGREEN NAS: Bucket mit Object Lock, Zugangsdaten, Compose-Datei, Sicherungsskript mit Zeitplan, Aufräumen, Prüfen und Wiederherstellen.
Voraussetzungen
- Eine UGREEN NAS mit UGOS Pro und der App Docker.
- SSH-Zugang zur NAS, siehe Teil 52.
- Ein Konto bei Hetzner mit einem Projekt in der Cloud Console.
- Ein Passwortmanager für das restic-Passwort und den S3-Schlüssel.
- Eine Upload-Bandbreite, die zur Datenmenge passt. Die erste Sicherung überträgt alles, danach nur noch Änderungen.
Wo die Kopie außer Haus im Sicherungsplan steht, erklärt Teil 53. Wie Sie Container-Daten so sichern, dass sie sich wieder starten lassen, zeigt Teil 61.
Warum restic und Object Storage
restic legt ein Repository an, in dem jede Sicherung als Snapshot steht. Dateien zerlegt es in Blöcke und speichert jeden Block nur einmal. Alles im Repository ist mit Ihrem Passwort verschlüsselt, Hetzner sieht nur unlesbare Dateien.
Object Storage rechnet nach belegtem Speicher ab und braucht keinen eigenen Server. Den aktuellen Preis nennt Hetzner auf seiner Preisseite. Laut Hetzner-Dokumentation kosten eingehender Datenverkehr und Anfragen nichts extra.
Schritt 1: Bucket mit Object Lock anlegen
Melden Sie sich in der Hetzner Cloud Console an, öffnen Sie Ihr Projekt und legen Sie einen Bucket an, wie es die Hetzner-Dokumentation beschreibt. Wählen Sie einen Standort wie Falkenstein (fsn1) und einen Namen wie mein-nas-backup, der Bucket bleibt privat.
Aktivieren Sie beim Anlegen Object Lock. Laut Hetzner lässt sich Object Lock nur beim Anlegen einschalten, nicht nachträglich. Object Lock verhindert, dass eine Datei vor Ablauf ihrer Frist gelöscht oder überschrieben wird. Das gilt auch für Ihren eigenen Schlüssel. Ein Angreifer, der Ihre NAS samt Zugangsdaten übernimmt, kann frisch gesicherte Dateien deshalb nicht sofort vernichten.
Die Frist gilt aber für jede Datei nur ab dem Hochladen. restic schreibt Datenblöcke einmal und nutzt sie über Jahre weiter, bei diesen älteren Dateien ist die Sperre längst abgelaufen. Wer Ihren Schlüssel hat, kann sie endgültig löschen und die übrigen als gelöscht markieren. Object Lock ist deshalb eine zusätzliche Hürde, kein Ersatz für eine zweite Sicherung, etwa auf einer USB-Festplatte im Schrank.
Legen Sie danach in der Cloud Console S3-Zugangsdaten an, siehe Hetzner-Dokumentation. Speichern Sie Access Key und Secret Key sofort im Passwortmanager.
Frist und Aufräumregel setzen
Die Standardfrist für neue Dateien und eine Regel, die gelöschte Fassungen später endgültig entfernt, setzen Sie über die S3-Schnittstelle. Das geht mit dem offiziellen AWS-CLI-Container direkt auf der NAS. Melden Sie sich per SSH an der NAS an und legen Sie einen Arbeitsordner an:
mkdir ~/hetzner && cd ~/hetzner
nano lock.jsonIn lock.json kommt die Frist:
{"ObjectLockEnabled":"Enabled","Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Days":30}}}Die Aufräumregel kommt mit nano lifecycle.json in lifecycle.json:
{"Rules":[{"ID":"geloeschte-fassungen","Status":"Enabled","Prefix":"","NoncurrentVersionExpiration":{"NoncurrentDays":30},"AbortIncompleteMultipartUpload":{"DaysAfterInitiation":7}},{"ID":"loeschmarker","Status":"Enabled","Prefix":"","Expiration":{"ExpiredObjectDeleteMarker":true}}]}Dann im selben Ordner. Die beiden read-Zeilen fragen Access Key und Secret Key ab, so landen sie nicht im Verlauf der Shell:
read -r -p "Access Key: " AWS_ACCESS_KEY_ID; read -r -s -p "Secret Key: " AWS_SECRET_ACCESS_KEY; echo
aws() { sudo docker run --rm -e AWS_ACCESS_KEY_ID="$AWS_ACCESS_KEY_ID" -e AWS_SECRET_ACCESS_KEY="$AWS_SECRET_ACCESS_KEY" -e AWS_DEFAULT_REGION=fsn1 -v "$PWD:/work:ro" amazon/aws-cli:2.22.35 --endpoint-url https://fsn1.your-objectstorage.com "$@"; }
aws s3api put-object-lock-configuration --bucket mein-nas-backup --object-lock-configuration file:///work/lock.json
aws s3api put-bucket-lifecycle-configuration --bucket mein-nas-backup --lifecycle-configuration file:///work/lifecycle.json
aws s3api get-object-lock-configuration --bucket mein-nas-backup
unset AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEYPassen Sie Standort und Bucket-Namen an. COMPLIANCE bedeutet: Die Frist kann niemand verkürzen, auch Sie nicht. Im Modus GOVERNANCE lässt sich die Sperre mit dem Schlüssel wieder aufheben. Zum Ausprobieren ist das bequem, gegen einen Angreifer mit Ihrem Schlüssel hilft es nicht. 30 Tage sind ein guter Mittelweg zwischen Schutz und Speicherkosten.
Verifizieren: get-object-lock-configuration zeigt ObjectLockEnabled Enabled und Ihre Frist mit Mode und Days.
Wie Object Lock und restic zusammenspielen
restic löscht beim Aufräumen nicht mehr benötigte Dateien. In einem Bucket mit Object Lock entfernt das Löschen die Datei nicht, sondern legt eine Löschmarkierung an. Die alte Fassung bleibt danach noch 30 Tage erhalten, erst dann entfernt die Lifecycle-Regel sie. Für restic ist die Datei sofort verschwunden, das Repository bleibt sauber. Aufgeräumte Daten bezahlen Sie aber noch rund 30 Tage weiter.
In unserem eigenen Aufbau läuft dieses Zusammenspiel seit mehreren Wochen mit täglichen Sicherungen. Das Aufräumen am Sonntag meldete jeweils done, die Prüfung danach no errors were found.
Schritt 2: Ordner und Dateien auf der NAS anlegen
Melden Sie sich per SSH an und legen Sie den Projektordner an. Wir nutzen den freigegebenen Ordner docker auf Volume 2, passen Sie den Pfad an Ihre NAS an:
sudo mkdir -p /volume2/docker/restic-offsite/scripts
cd /volume2/docker/restic-offsiteDie Zugangsdaten kommen in eine Datei .env, die nur root lesen darf:
sudo tee .env > /dev/null <<'EOF'
RESTIC_PASSWORD=ein-langes-zufaelliges-passwort
AWS_ACCESS_KEY_ID=IHR_ACCESS_KEY
AWS_SECRET_ACCESS_KEY=IHR_SECRET_KEY
KUMA_PUSH_URL=
EOF
sudo chmod 600 .envEin gutes Passwort erzeugt openssl rand -base64 32. Speichern Sie es im Passwortmanager, bevor Sie weitermachen. Ohne dieses Passwort ist die Sicherung nicht lesbar, auch nicht für Hetzner.
Die folgenden Dateien legen Sie im Ordner scripts an, etwa mit sudo nano scripts/backup.sh. Passen Sie in der Compose-Datei später /volume1/Daten an den Ort Ihrer Freigabe an, sie kann auf einem beliebigen Volume liegen. In scripts/auswahl.txt steht je Zeile ein Ordner, der gesichert wird. Die Pfade beziehen sich auf den Container, in dem Ihre Freigabe Daten unter /quelle/Daten eingebunden ist:
/quelle/Daten/Dokumente
/quelle/Daten/Fotosscripts/start.sh entfernt eine Sperre, die ein abgebrochener Lauf hinterlassen hat, lädt den Zeitplan und startet cron im Container:
#!/bin/sh
# Zeitplan laden und cron im Vordergrund laufen lassen
mkdir -p /data/logs /data/cache
rmdir /tmp/backup.lock 2>/dev/null # Sperre aus einem abgebrochenen Lauf entfernen
crontab /scripts/crontab
echo "$(date '+%F %T') restic-offsite gestartet ($(restic version | cut -d' ' -f1-2))"
exec crond -f -l 8scripts/crontab startet die Sicherung jede Nacht um 03:30. Zwischen 02:00 und 03:00 fällt bei der Zeitumstellung im März ein Lauf aus, im Oktober kann einer doppelt kommen:
# Minute Stunde Tag Monat Wochentag Befehl
30 3 * * * /scripts/backup.sh >> /data/logs/backup.log 2>&1scripts/backup.sh erledigt die eigentliche Arbeit. Es verhindert einen doppelten Start, prüft die Verbindung, mit --test zusätzlich die Liste der Snapshots, sichert, dünnt sonntags alte Stände aus und prüft das Repository. Am ersten Sonntag im Monat liest es zusätzlich 2 Prozent der Daten zurück:
#!/bin/sh
# Sicherung außer Haus mit restic. Aufruf ohne Option: ganzer Lauf, mit --test: nur Verbindung prüfen.
log() { echo "$(date '+%F %T') $*"; }
kuma() { [ -n "$KUMA_PUSH_URL" ] && wget -q -T 15 -O /dev/null "${KUMA_PUSH_URL%%\?*}?status=$1&msg=$2"; return 0; }
fehler() { log "FEHLER: $*"; kuma down "Fehler"; exit 1; }
mkdir /tmp/backup.lock 2>/dev/null || { log "läuft bereits"; exit 0; }
trap 'rmdir /tmp/backup.lock' EXIT
log "===== Sicherung startet ====="
restic cat config >/dev/null 2>&1 || fehler "Repository nicht erreichbar"
if [ "$1" = "--test" ]; then restic snapshots --compact || fehler "restic snapshots"; exit 0; fi
restic unlock >/dev/null 2>&1
restic backup --files-from /scripts/auswahl.txt --tag nas \
--exclude '@eaDir' --exclude '#recycle' --exclude '.DS_Store' --exclude '._*' --exclude 'Thumbs.db' \
|| fehler "restic backup"
if [ "$(date +%u)" = "7" ]; then
restic forget --prune --group-by host,tags --keep-daily 7 --keep-weekly 8 --keep-monthly 12 --keep-yearly 3 || fehler "restic forget"
if [ "$(date +%d)" -le 7 ]; then restic check --read-data-subset=2% || fehler "restic check"
else restic check || fehler "restic check"; fi
fi
log "===== fertig ====="
kuma up "OK"sudo chmod +x scripts/*.shrestic unlock am Anfang entfernt nur Sperren, die von abgebrochenen Läufen übrig sind. Das ist wichtig: Nach einer kurzen Störung beim Anbieter blieb in unserem Aufbau eine Sperre liegen, ohne unlock wären die folgenden Läufe daran gescheitert.
Verifizieren: ls -la /volume2/docker/restic-offsite zeigt .env mit -rw------- und den Ordner scripts mit vier Dateien.
Schritt 3: Projekt in der Docker-App bereitstellen
Öffnen Sie die App Docker, wählen Sie Projekt und klicken Sie auf Erstellen. Geben Sie als Name restic-offsite ein und wählen Sie als Speicherpfad den Ordner aus Schritt 2.
Fügen Sie unter Compose-Konfiguration diese Datei ein und passen Sie Standort, Bucket und den Pfad Ihrer Freigabe an:
services:
restic:
image: restic/restic:0.19.1
container_name: restic-offsite
hostname: ugreen-nas
restart: unless-stopped
init: true
entrypoint: ["/bin/sh", "/scripts/start.sh"]
env_file: .env
environment:
- TZ=Europe/Berlin
- RESTIC_REPOSITORY=s3:https://fsn1.your-objectstorage.com/mein-nas-backup/restic
- AWS_DEFAULT_REGION=fsn1
- RESTIC_CACHE_DIR=/data/cache
volumes:
- ./scripts:/scripts:ro
- ./data:/data
- /volume1/Daten:/quelle/Daten:ro
Drei Zeilen sind wichtiger, als sie aussehen. Die feste Version verhindert, dass ein Update ungeprüft eingespielt wird. Der feste Hostname hält alle Snapshots derselben Maschine zusammen, auch wenn der Container neu erstellt wird. Und die Freigabe ist nur lesend eingebunden, das Sicherungsprogramm kann Ihre Daten also nicht verändern.
Lassen Sie den Haken bei Nach der Erstellung sofort ausführen gesetzt und klicken Sie auf Bereitstellen.
Verifizieren: Im Reiter Protokoll steht restic-offsite gestartet mit der Version von restic.
Schritt 4: Repository anlegen
Das Repository legen Sie einmal von Hand an:
sudo docker exec restic-offsite restic initrestic meldet created restic repository und erinnert daran, dass ohne Passwort kein Zugriff möglich ist. Bekommen Sie einen Fehler, prüfen Sie Schlüssel, Bucket-Namen und Endpunkt in .env und Compose-Datei.
Verifizieren: sudo docker exec restic-offsite /scripts/backup.sh --test läuft ohne FEHLER durch.
Schritt 5: Erste Sicherung starten
Die erste Sicherung überträgt alle Daten und kann bei großen Datenmengen Tage dauern. Starten Sie sie deshalb im Hintergrund, die Ausgabe landet im Log:
sudo docker exec -d restic-offsite sh -c '/scripts/backup.sh >> /data/logs/backup.log 2>&1'Den Fortschritt sehen Sie mit:
sudo tail -f /volume2/docker/restic-offsite/data/logs/backup.logLäuft um 03:30 noch die erste Sicherung, beendet sich der geplante Lauf mit läuft bereits. Bricht die erste Sicherung ab, setzt der nächste Lauf fort: Das meiste, was schon hochgeladen ist, überträgt restic nicht noch einmal.
Ab dem zweiten Lauf liest restic nur geänderte Dateien. In unserem Test meldete der zweite Lauf 0 new, 0 changed und fügte dem Repository 0 B hinzu. In unserem eigenen Aufbau mit rund 450 GiB überträgt die tägliche Sicherung meist zwischen 20 und 150 MiB und ist nach unter einer Minute fertig.
Verifizieren: sudo docker exec restic-offsite restic snapshots zeigt einen Snapshot mit Host ugreen-nas, Tag nas und Ihren Ordnern.
Schritt 6: Alte Stände ausdünnen und prüfen
Das Skript behält 7 tägliche, 8 wöchentliche, 12 monatliche und 3 jährliche Stände. Sonntags entfernt restic forget mit --prune alles andere und gibt nicht mehr benötigten Speicher frei. Danach prüft restic check das Repository, am ersten Sonntag im Monat liest es zusätzlich 2 Prozent der Daten zurück und vergleicht sie. So fallen beschädigte Dateien beim Anbieter auf, ohne jeden Monat alles herunterzuladen.
Ein ganzer Prüflauf dauerte in unserem Aufbau mit Aufräumen rund vier Minuten. --group-by host,tags sorgt dafür, dass die Regeln auch dann für alle Snapshots gelten, wenn Sie später einen Ordner in auswahl.txt ergänzen.
Verifizieren: Nach dem ersten Sonntag steht im Log eine Zeile mit Applying Policy und am Ende no errors were found.
Schritt 7: Überwachen
Jeder Lauf hängt seine Ausgabe an data/logs/backup.log an. Die Datei wächst langsam, leeren Sie sie bei Bedarf mit sudo truncate -s 0 data/logs/backup.log.
Das Skript meldet jeden Lauf an Uptime Kuma, wenn Sie in der .env eine Push-Adresse eintragen. Legen Sie in Uptime Kuma einen Monitor vom Typ Push an, mit einem Intervall von 25 Stunden, und kopieren Sie die Push-URL in KUMA_PUSH_URL. Bleibt die Meldung aus oder kommt status=down, schlägt Uptime Kuma Alarm. Wie Sie Uptime Kuma einrichten, zeigt Teil 68.
Die .env liest Docker nur beim Erstellen des Containers, ein Neustart genügt nach einer Änderung nicht. Erstellen Sie den Container per SSH neu:
cd /volume2/docker/restic-offsite
sudo docker compose up -d --force-recreateDie Docker-App hat die Compose-Datei als docker-compose.yaml in diesem Ordner abgelegt, der Befehl findet sie dort.
Verifizieren: Starten Sie einen ganzen Lauf wie in Schritt 5 und prüfen Sie, ob der Monitor in Uptime Kuma auf grün geht. Der Lauf mit --test meldet nichts an Uptime Kuma.
Schritt 8: Dateien wiederherstellen
Solange die NAS läuft, holen Sie einzelne Ordner in den Datenordner des Projekts zurück:
sudo docker exec restic-offsite restic snapshots
sudo docker exec restic-offsite restic restore latest --target /data/wiederherstellen --include /quelle/Daten/DokumenteDie Dateien liegen danach unter /volume2/docker/restic-offsite/data/wiederherstellen/quelle/Daten/Dokumente. Statt latest können Sie die ID eines älteren Snapshots angeben. In unserem Test war die zurückgeholte Datei bitgleich mit dem Original. Die Dateien gehören root. An ihren alten Platz bringen Sie sie mit sudo cp -a oder in der App Dateien mit einem Administratorkonto.
Ist die NAS weg, genügt ein beliebiger Rechner mit restic ab Version 0.14 und diesen Angaben aus dem Passwortmanager, einschließlich der Adresse des Repositorys:
export AWS_ACCESS_KEY_ID=IHR_ACCESS_KEY
export AWS_SECRET_ACCESS_KEY=IHR_SECRET_KEY
export RESTIC_PASSWORD=IHR_RESTIC_PASSWORT
export AWS_DEFAULT_REGION=fsn1
export RESTIC_REPOSITORY=s3:https://fsn1.your-objectstorage.com/mein-nas-backup/restic
restic snapshots
restic restore latest --target ./zurueckSchreiben Sie diese Schritte samt Repository-Adresse und dem Namen des Eintrags im Passwortmanager auf Papier und legen Sie den Zettel zu Ihren Unterlagen. Wie Sie eine Wiederherstellung regelmäßig üben, zeigt Teil 62.
Verifizieren: sudo ls -l auf den Ordner wiederherstellen zeigt die Dateien in der Größe der Originale.
Typische Fehler
- Object Lock vergessen: Nachträglich lässt es sich nicht einschalten. Dann bleibt nur ein neuer Bucket.
- restic-Passwort nur auf der NAS: Ist die NAS weg, ist die Sicherung ohne Passwort wertlos.
- Image ohne feste Version: Mit latest kommt jedes Update ungeprüft.
- Hostname nicht gesetzt: Ohne festen Hostnamen hat jeder neu erstellte Container einen anderen Namen, und die Regeln zum Ausdünnen greifen getrennt.
- Keine Überwachung: Ein gelöschter Schlüssel, ein geändertes Passwort oder ein Netzproblem fällt erst beim Wiederherstellen auf.
Häufige Fragen
Warum nicht Sync & Backup von UGOS?
restic verschlüsselt auf der NAS, hält viele Versionen platzsparend vor und lässt sich von jedem Rechner aus wiederherstellen, auch ohne UGREEN-Gerät. Das Repository ist nicht an UGOS gebunden.
Kann ich statt Hetzner einen anderen Anbieter nutzen?
Ja, restic spricht jeden S3-Speicher an. Sie ändern nur RESTIC_REPOSITORY und die Schlüssel. Object Lock und Lifecycle-Regeln müssen beim jeweiligen Anbieter verfügbar sein.
Schützt Object Lock vor Erpressungstrojanern?
Teilweise. Dateien, die jünger als die Frist sind, kann niemand löschen oder überschreiben. Ältere Dateien des Repositorys sind nicht mehr gesperrt, ein Angreifer mit Ihrem Schlüssel kann sie löschen. Halten Sie deshalb eine zweite Sicherung vor, die keine Verbindung zur NAS hat.
Was kostet die Sicherung?
Das hängt von Datenmenge und Frist ab. Durch Deduplizierung und Komprimierung belegt das Repository oft weniger als die Originaldaten, durch Object Lock und die Lifecycle-Regel kommt aufgeräumter Speicher noch rund 30 Tage dazu. Die aktuellen Preise nennt Hetzner auf der Preisseite.
Fazit
Mit restic und Hetzner Object Storage liegt eine verschlüsselte Kopie Ihrer wichtigen Daten außer Haus, mit vielen Versionen und Schutz vor dem Löschen durch Object Lock. Der Container sichert jede Nacht von selbst, räumt sonntags auf und prüft das Repository. Entscheidend sind drei Dinge außerhalb der Technik: das Passwort sicher aufbewahren, die Überwachung einrichten und die Wiederherstellung einmal üben.
