E1 · Backup & Restore: Design¶

Datum: 2026-10-28 Epic: homeserver#179 · Konzept-Issue homeserver#216 Status: Entscheidungen von Robin getroffen (Denk-Session 28.–30.10.2026), nach der Prüfung durch einen frischen Leser ergänzt und von Robin freigegeben (30.10.). Belege: Ist-Aufnahme 29.09. und Runbooks 1+2 (Kommentare in #216) · Recherche: Werkzeuge, UNAS, Storage Box · Übergaben aus D1, Abschnitte 6, 10 und 13

Das Dokument legt fest, wie das Backup künftig aufgebaut ist, wie Robin Daten zurückholt, wer wann alarmiert wird und was Lars und Thies tun, wenn zu Hause etwas hängt. Gebaut wird in den Teil-Issues aus Abschnitt 15.

1. Kontext und Ziel¶

Robin, 13.09.: „Das muss dann wirklich RockSolid sein und nicht auf Vermutungen basieren.“

Robin, 28.10.: Das Backup soll vernünftig durchdacht sein, nach heutigem Stand der Technik, „nicht zu unnötig und zu viel“, ohne Single Point of Failure. Robin soll wissen, wie man Sachen wiederherstellt. Werkzeug und Topologie sollen einmal grundsätzlich hinterfragt werden. Das USB-RAID am NUC hält Robin nicht für sinnvoll.

Größte Sorge (Robin): Lars hat im Ernstfall keine Ahnung, was zu tun ist. Gemeint ist kein Wiederaufbau durch Lars, sondern ein Störungs-Handbuch: Strom war weg, etwas ist abgestürzt, die Heizung reagiert nicht. Dann soll Lars nachsehen und gefahrlos neu starten können. Alles Weitere macht Robin aus der Ferne. Thies, Robins bester Freund und bald Nachbar gegenüber, kann mithelfen.

Bedrohungen, gewichtet (Robin):

Brand und Überspannung in der Wohnung
Versehentliches Löschen und kaputte Updates
Angriff und Ransomware: soll Thema sein, „wenn es nicht so aufwendig ist“

Alles ist verschlüsselt.

2. Ziele, Nicht-Ziele, Anti-Ziele¶

Ziele

Jede Datenklasse liegt auf einem anderen Gerät als die Quelle und zusätzlich außer Haus, verschlüsselt.
Ein kompromittierter oder durchgedrehter Host kann seine eigenen Backups löschen, aber weder die Snapshots noch die Backups anderer Hosts.
Robin hat drei Restore-Rezepte (klein, mittel, groß) einmal selbst durchgespielt.
Jeden Morgen kommt ein Status. Jede Lücke alarmiert, nicht nur ein Fehlschlag.
Lars und Thies haben ein gedrucktes Störungs-Handbuch.
Die Configs sind im Git nachvollziehbar.

Nicht-Ziele

Lars oder Thies bauen keinen Host neu auf und besorgen keine Ersatz-Hardware (Robin).
Medien (Filme, Serien, Musik) bekommen kein Backup. Das gilt seit #227 und D1.
Eine dritte Kopie der Originale gibt es vorerst nicht (Abschnitt 6.4).
Kein Werkzeugwechsel (Abschnitt 4).
Ausfallsicherer Fernzugriff: „Wenn ich Zugriff habe, dann ist es so. Wenn nicht, dann ist es halt auch so“ (Robin).

Anti-Ziele (wäre ein Fehlschlag, selbst wenn es technisch läuft)

Ein Aufbau, der mehr Pflege kostet, als er schützt: zweites Werkzeug, eigene Wartungsmaschine, Sonderwege je Host.
Ein Backup, das nie zurückgespielt wurde.
Ein Alarm, der still bleibt, wenn der Lauf ausbleibt.

3. Ist-Stand (Abgleich 28.10.2026)¶

Die Ist-Aufnahme vom 29.09. (#216) gilt. Seitdem sind Runbook 1 (02.10.) und Runbook 2 (05.10.) durch. Am 28.10. am System geprüft:

NUC:
- Seit dem 06.10. liefen 23 Nächte durch, beide Configs Successfully (46/46), kein WARN, alle Dumps OK.
- borgmatic 2.1.5, borg 1.4.0. Die Passphrasen liegen als Credential-Dateien vor.
- Auf der Box ruft borgmatic borg serve ohne remote_path auf. Dort antwortet also borg 1.2 (Hetzner-Standard).
aiserver: borgmatic 2.0.11, borg 1.4.4, läuft jeden Abend erfolgreich. Die Live-Config ist weiter ungelesen, weil dafür sudo nötig ist.
Füllstände: Storage Box BX11 bei 621 GiB von 1 TiB (61 %). Die Box meldet selbst 1.0T (df -B1: 1 099 511 627 776 B), die 931 GiB in D1 Abschnitt 6 sind zu niedrig. UNAS: 91 TB, davon 25 TB belegt. Das NUC-Repo belegt 663 GB, das neueste Archiv 469 GB komprimiert, der Neuzuwachs liegt bei ~1,7 GB pro Nacht. Das USB-RAID ist zu 6 % belegt.
Lücken:
- Der VPS hat kein Backup.
- Die Archivordner auf der UNAS sind ungesichert.
- Drei Keys mit Vollzugriff auf den Hauptaccount der Box, keine Snapshots, robin hat per rclone-Mount Schreibzugriff auf die ganze Box.
- Das USB-RAID hängt am NUC.
- Dump-Fehler alarmieren nicht.
- Die Configs sind unversioniert.
- Die Appliance-Configs sind ungeklärt.
- Restores wurden nie geübt.

4. Werkzeug: Borg 1.4 + borgmatic bleiben¶

Entscheidung (Robin, nach der Recherche): Borg bleibt.

Begründung:
- Borg 2 ist Beta.
- restic bietet über SFTP auf der Storage Box keinen Löschschutz.
- Kopia spielt seine Stärke nur mit S3 Object Lock aus.
- Die echten Risiken liegen in der Anordnung.
Update auf borg 1.4.5 auf NUC und aiserver.
remote_path: borg-1.4 in jeder Config mit Storage-Box-Ziel.
Borg 2 wird neu bewertet, wenn 2.0 final ist und Hetzner es serverseitig anbietet. Vorher nicht.

5. Grundsätze¶

Wer die Daten nutzt, sichert sie (Robin). Ob die Daten auf der SSD des Hosts oder auf einer Freigabe der UNAS liegen, ist egal. Immich und Paperless laufen auf dem NUC, also sichert der NUC Fotos und Dokumente. Später gilt dasselbe für Cluster-Apps. Daten, die niemand nutzt (die Archivordner), nimmt der NUC mit.
Backup auf ein anderes Gerät als die Quelle, plus eine Kopie außer Haus. Originale, die auf der UNAS liegen, bekommen deshalb kein lokales Borg-Repo auf der UNAS. Das wäre dasselbe Gerät. Lokal schützen sie Snapshots.
Jeder Host sieht nur sein eigenes Ziel: eine eigene NFS-Freigabe, ein eigener Sub-Account, ein eigener Key.
Snapshots verwaltet nur Robin. Kein Host hat Zugriff auf die Verwaltung der UNAS oder der Storage Box, also weder Passwort noch Admin noch API-Token mit Schreibrecht. Lesen ist erlaubt: ein Hetzner-Token nur zum Lesen und ein UniFi-Konto mit der Rolle „View Only“, falls diese Rolle reicht (Abschnitt 13). Root-SSH auf die UNAS gehört nicht dazu, denn Root kann immer schreiben.
Alles ist verschlüsselt (Robin), auch die lokalen Repos auf der UNAS. Borg nutzt repokey-blake2, jedes Repo hat eine eigene Passphrase, so wie heute schon lokal und Hetzner verschieden sind. Die einzige Ausnahme ist das Hetzner-Image des VPS (Abschnitt 8).

6. Topologie¶

6.1 Übersicht¶

Quelle	Daten	lokal	außer Haus
NUC	Dienst-Zustand (`/mnt/ssd/container-data`, `/etc`, `/opt`, `/root`, `/home`, `/var` ohne Docker-Interna), DB-Dumps, Appliance-Exporte	UNAS, Freigabe für NUC-Backups, eigenes Borg-Repo	Storage Box, Sub-Account `nuc` (bestehendes `backups/nuc`)
NUC stellvertretend für die UNAS	Originale: `/mnt/pictures`, `/mnt/paperless`, `/mnt/scanner`, Archivordner	– (Snapshots auf der UNAS)	dasselbe NUC-Repo auf der Box
aiserver	Dienst-Zustand laut eigener Config	UNAS, Freigabe für aiserver-Backups, direkt gemountet, ohne den NUC dazwischen	Storage Box, Sub-Account `aiserver` (bestehendes `backups/aiserver`)
VPS	Identity (Authelia, lldap), Headscale, ntfy, Uptime Kuma, Healthchecks, Compose-Verzeichnisse	–	Hetzner Cloud Backup (Image, 7 Tage) und Borg → Sub-Account `vps` (neu)
UNAS	Originale	Btrfs-Snapshots auf den Original-Freigaben	über den NUC, siehe oben

Das USB-RAID (QNAP TR-004) fällt als Ziel weg.

6.2 Originale im bestehenden NUC-Repo (mein Call, mit Robin besprochen)¶

Die Originale bekommen kein eigenes Repo auf der Box. Ein neues Repo hieße, ~465 GB neu hochzuladen. Die alten Monatsarchive im NUC-Repo hielten die Foto-Chunks dann noch 12 Monate fest, über das Jahresarchiv sogar bis 2028. Die Fotos lägen also mindestens ein Jahr lang doppelt auf der Box. Die Archivordner kommen als zusätzliche Quellen in die Hetzner-Config des NUC.

Daraus folgt: Die lokale NUC-Config und die Hetzner-Config unterscheiden sich in den Quellen. Lokal enthält keine Originale, Hetzner alles.

6.3 Die Wege im Bild¶

flowchart LR
  subgraph Haus
    NUC[NUC<br/>Dienst-Zustand + Dumps]
    AI[aiserver<br/>Dienst-Zustand]
    subgraph UNAS[UNAS Pro · RAID 6]
      ORIG[(Originale<br/>Fotos · Paperless · Archiv<br/>+ Snapshots)]
      BNUC[(Freigabe Backup NUC<br/>+ Snapshots)]
      BAI[(Freigabe Backup aiserver<br/>+ Snapshots)]
    end
  end
  subgraph Hetzner
    VPS[VPS]
    HB[(Cloud Backup<br/>7 Tage)]
    subgraph SB[Storage Box · Snapshots täglich]
      SNUC[(Sub nuc)]
      SAI[(Sub aiserver)]
      SVPS[(Sub vps)]
    end
  end
  NUC --> BNUC
  NUC --> SNUC
  ORIG -. liest per NFS .-> NUC
  AI --> BAI
  AI --> SAI
  VPS --> SVPS
  VPS --> HB

6.4 Dritte Kopie der Originale: vorerst nicht¶

Entscheidung (Robin): Für die Originale gibt es die UNAS (RAID 6 mit Snapshots) und die Storage Box (mit Snapshots). Eine dritte Kopie an einem dritten Ort will Robin nicht, weil das Kosten und einen weiteren Ort bedeutet.

Restrisiko: Die UNAS geht verloren und gleichzeitig ist das Repo auf der Box unbrauchbar. Dagegen helfen regelmäßige check --verify-data-Läufe (Abschnitt 11) und die Box-Snapshots.
Bis 2027 liegen die iPhone-Fotos zusätzlich in iCloud. Das ist eine dritte Kopie auf Zeit.
Auslöser für die Neubewertung: die iCloud-Kündigung 2027. Zur Wahl stehen dann das TR-004 als Offline-Kopie an einer schaltbaren Steckdose, eine Kopie bei Thies oder Hetzner Object Storage mit Object Lock (Recherche, Abschnitt 3).

7. Lokales Ziel: UNAS¶

Neue Freigaben für die Backups, eine je Host. Getrennte Freigaben, weil UniFi Drive NFS-Exporte und Snapshots je Shared Drive vergibt. Jede Freigabe wird nur für die IP ihres Hosts exportiert, also NUC 10.10.10.3 und aiserver 10.10.10.7. Ob Unterordner einer einzigen Freigabe getrennt exportierbar sind, prüft der Umsetzer (Abschnitt 17).
Snapshots:
- täglich auf jeder Backup-Freigabe und auf den Original-Freigaben (pictures, paperless, Archiv)
- Aufbewahrung: mein Call, 14 Tage. Das ist länger als die 10 Tage der Box, damit der lokale Rückweg weiter reicht.
Archivordner umziehen: Die Archivordner liegen heute in der Freigabe nas zwischen 17 TB Medien. Snapshots auf nas würden jede ersetzte Filmdatei festhalten. Deshalb ziehen die Archivordner in eine eigene Freigabe archiv (mein Call). Vorher sichtet Robin sie (D1). Die Ordner sind immich-nicht-importiert-2026-09-16 mit den Kindheits-DVDs (57 GB), nextcloud-archiv-2026-09-15 (39 GB), stack-archiv-2026-09-16 und wallos-export-2026-09-16.
Repos neu anlegen:
- NUC: neu auf der UNAS, ohne Originale, ~100 GB. Die Historie des alten TR-004-Repos geht dabei nicht in das neue Repo über.
- aiserver: Das Repo (4 GiB) wird samt Historie vom TR-004 auf die UNAS kopiert (mein Call, kostet nichts).
TR-004: bleibt nach dem Umbau als ruhende Rückfalloption angeschlossen, bis das neue lokale Repo drei Monate Historie hat (mein Call). Danach baut Robin es ab. Ob es 2027 als Offline-Kopie wiederkommt, entscheidet Abschnitt 6.4.
Mount-Units für die Ziele: Docker darf nicht davon abhängen (#278). Fehlt der Ziel-Mount, muss der Lauf scheitern. Er darf kein leeres Verzeichnis für ein neues Repo halten. Der Mount-Guard aus dem before-Hook wird um das Ziel erweitert.
Wartung: Data Scrubbing auf der UNAS (seit Drive 4.2.2) wird regelmäßig geplant. Firmware und Version prüft der Umsetzer.
Freier Platz (mein Call): Fällt der freie Platz unter etwa 10 %, legt die UNAS laut Test keine Snapshots mehr an. Heute sind 67 TB frei. Medien wachsen um 1,2–1,3 TB im Monat, die 10-%-Grenze ist also rund vier Jahre entfernt. Der Alarm kommt bei 15 % frei. Dann geben die Medien nach, denn sie sind wiederbeschaffbar. Was genau weg kann, entscheidet Robin, wenn es so weit ist.

8. Außer Haus: Storage Box und Hetzner Cloud Backup¶

Storage Box

Sub-Accounts nuc, aiserver und vps. Die Home-Verzeichnisse der beiden ersten zeigen auf die vorhandenen Repo-Verzeichnisse, es wird also nichts neu hochgeladen. Jeder Sub-Account hat SSH auf Port 23 und einen eigenen Key, den nur sein Host kennt.
Hauptaccount:
- keine Host-Keys mehr
- das Passwort neu gesetzt, nur in Infisical und Proton Pass
- die drei alten Keys entfernt
rclone-Mount /mnt/storagebox fällt weg, und damit der Schreibzugriff von robin auf die ganze Box. Der Füllstand kommt künftig aus der Hetzner-API, mit einem Lese-Token auf dem NUC, der keine Snapshots löschen kann (Abschnitt 10). Der Wegfall nimmt auch den rclone-Teil aus #278.
Snapshots:
- automatischer Plan täglich, 10 Stück (BX11-Maximum), Zeitpunkt nach dem Backup-Fenster (UTC beachten)
- manuelle Snapshots vor riskanten Eingriffen, etwa vor dem Umstellen der Sub-Accounts
Ransomware vorerst über die Snapshots (Entscheidung Robin, Vorschlag Claude). Ein gekaperter Host kann sein Repo löschen, die Snapshots nicht. Zurückgeholt wird der Stand von gestern.
Gelöschtes Repo zurückholen (mein Call): Robin kopiert vom Laptop aus über den Hauptaccount. Die Box-Shell kennt cp, also cp -r aus /.zfs/snapshot/<snapshot>/<verzeichnis> in ein neues Verzeichnis. Danach das Sub-Account-Home umhängen. Ein Rollback setzt die ganze Box zurück, also auch die Repos der anderen Hosts, und löscht neuere Snapshots. Er kommt nur in Frage, wenn die ganze Box getroffen ist.
Lese-Zugang für den Notfall: Sub-Account restore, nur lesend, Home backups/. Sein Key liegt nur in Proton Pass, sein Passwort im Umschlag (Abschnitt 12). Damit kommt Robin an jedes Repo, ohne das Hauptaccount-Passwort mit Vollzugriff zu benutzen. Ob borg einen nur lesbaren Zugang mit --bypass-lock akzeptiert, prüft der Umsetzer.
Append-only kommt später, falls nötig. Der Weg ist frei, weil jeder Host seinen eigenen Key und Sub-Account hat. Umgestellt würde so:
1. dem Key command="borg serve --append-only --restrict-to-path …" voranstellen
2. prune und compact auf einen vertrauenswürdigen Rechner verlegen

Auslöser (mein Vorschlag): E10, wenn der VPS die einzige Tür nach außen wird. Auf der UNAS-Seite gibt es kein append-only, dort sind die Snapshots der Schutz. - Kapazität (Rechnung vom 28.10.):

Posten	GB
heute: NUC 663 + aiserver 4	667
+ Archivordner	+95
+ Snapshot-Polster (≈ 10 Tage × 2 GB nächtliche Freigabe)	+20–40
+ VPS (klein, Schätzung)	+5
nach dem Umbau	≈ 790 (≈ 72 %)
+ Fotos 15–20 GB/Monat, + iCloud-Rest ≤ 50 GB (Robin)	bis 80 % ≈ Feb./März 2027
− SABnzbd-Altlast (92 GB, nur im Monatsarchiv vom 31.08.)	läuft im Sept. 2027 aus
− ollama-Modelle (≈ 60 GB)	nur, wenn die Modell-Verzeichnisse vor dem 31.12.2026 ausgeschlossen sind. Sonst hält `keep_yearly` das Jahresarchiv 2026 und damit die Modelle bis Anfang 2028. Ausschluss in T4, `openwebui/` bleibt drin

Entscheidung (Robin): Bei 80 % wird auf BX21 hochgestuft (5 TB, 10,90 € statt 3,20 €). Das geht in place, ohne Umzug. Object Storage ist verworfen.

Hetzner Cloud Backup für den VPS (Entscheidung Robin)

Wird eingeschaltet: täglich, 7 Stände, rund 0,80 € im Monat.
Stellt den ganzen Server wieder her. Das Image liegt unverschlüsselt bei Hetzner, genau wie die VPS-Platte selbst, das ist also keine neue Preisgabe.
Die Backups werden mit dem Server gelöscht. Die D1-Regel „VPS nie löschen“ deckt das ab.
Vor dem Rebuild auf 26.04 (E2b) wird ein Backup in einen geschützten Snapshot umgewandelt (mein Call).
Zusätzlich sichert der VPS per Borg in den Sub-Account vps. Das liefert einzelne Dateien, verschlüsselt und unabhängig vom Lebenszyklus des Servers (Robin: „Den VPS würde ich aber dennoch backuppen auf die Storagebox“).

9. Taktung und Aufbewahrung¶

Wird mit Robin entschieden, wenn die Configs geschrieben werden (Robin). Eingänge dafür:

Heute läuft das Backup nachts um 02:00 mit 7/4/12/2. keep_yearly greift erst ab 2027.
Die Aufbewahrung beeinflusst die Kapazitätsrechnung aus Abschnitt 8 direkt.
Die Box hält 10 Snapshots, die UNAS 14 Tage.
Lokale und Offsite-Repos dürfen unterschiedliche Aufbewahrung haben.
Die DB-Dumps laufen heute zweimal pro Nacht, weil beide Configs denselben before-Hook haben. Künftig laufen sie einmal je Nacht (Abschnitt 13).

10. Alarmierung¶

Quelle für den Totmann-Alarm (mein Call): das selbst gehostete Healthchecks auf dem VPS. Je Host und Config gibt es einen Check, und das Morgenstatus-Skript liest dessen API. Den Uptime-Kuma-Push nimmt borgmatic heraus. Er liefert dasselbe Signal noch einmal, und damit verschwindet auch das Token aus dem Journal. Robin schaut fürs Backup nicht in Kuma (30.10.).

Morgenstatus (Robin): Jeden Morgen gegen 7 Uhr kommt eine ntfy-Nachricht. Sie enthält:

alle Hosts und Repos mit letztem Lauf und Ergebnis
den Füllstand von Box und UNAS-Freigaben
das Alter des jüngsten Snapshots auf Box und UNAS
das Ergebnis der letzten Restore-Probe

Ist alles grün, bleibt die Nachricht kurz. Ist etwas rot, steht drin, was.

Was schiefgehen kann	Signal	Abnahme
Backup schlägt fehl	ntfy über borgmatic (`fail`), wie heute	–
Backup läuft gar nicht	Healthchecks je Host und Config, Grace passend zum Zeitplan	provoziert: Timer anhalten, Alarm muss kommen
Ein DB-Dump scheitert	eigener Alarm. Das Backup läuft trotzdem weiter, der Dump-Fehler wird aber sichtbar	provoziert
Ziel- oder Quell-Mount fehlt	Lauf scheitert, das ist ein `fail`	provoziert (Mount weg)
Storage Box ≥ 80 %	Alarm = Upgrade-Signal	–
Kein frischer Snapshot (Box oder UNAS)	Alarm. Laut Test legt die UNAS Snapshots teils still nicht an	–
Restore-Probe oder `verify-data` rot	Alarm	–
VPS tot, alles stumm	zweiter Alarmweg über healthchecks.io: gehört zu E3 (#225). E1 hängt daran	–

Die Kuma-Push-URL steht weiter im Journal. Rotiert wird sie, wenn das Token nach Infisical umzieht (schon in #216 so akzeptiert).

11. Restore¶

Restore-Handbuch mit drei Rezepten (Robin: „klein, mittel, groß“):

Klein, eine einzelne Datei: Foto, Dokument, HA-Automation oder Config.
- Fotos und Dokumente: zuerst über die UNAS-Snapshots.
- Alles andere: über borgmatic mount bzw. extract aus dem lokalen Repo.
Mittel, ein Dienst auf den Stand von gestern: Container anhalten, Daten und DB-Dump aus dem Backup holen, Dump einspielen, Container starten, Funktion prüfen.
Groß, Host-Daten nur aus der Storage Box: auf einem anderen Rechner (Robins Laptop), nur mit der Notfallkopie aus Proton Pass, also Passphrase und Paper-Key. Das prüft, ob der Weg ohne NUC, ohne Infisical-Agent und ohne lokales Repo funktioniert. Der echte Neuaufbau des NUC ist Teil der Neuinstallation Feb./März 2027 (E2b, D1 Abschnitt 9) und wird dort geprobt.

Probe (Abnahme): Robin spielt jedes Rezept einmal selbst durch, Claude begleitet. Danach gibt es keine Pflicht-Wiederholung (Robin).

Automatisch (mein Vorschlag, von Robin angenommen):

Wöchentlich: Eine Testdatei mit bekanntem Hash wird aus dem jüngsten Archiv extrahiert und verglichen, je Repo.
Regelmäßig: check --verify-data liest alle Daten.
- Lokal: monatlich.
- Storage Box: Ein voller Lauf lädt ~660 GB herunter. Den Rhythmus legt der Umsetzer nach gemessener Bandbreite fest, mindestens vierteljährlich.
- Nur von zu Hause, nie vom VPS (mein Call). Vom VPS aus wäre der Lauf schneller, aber dann lägen Key und Passphrase des NUC-Repos auf dem Rechner, der in E10 die einzige Tür nach außen wird.
- check sperrt das Repo exklusiv. Der Lauf liegt deshalb am Wochenende tagsüber, mit Abstand zum Nachtlauf. Dauert er länger, wartet der Nachtlauf über lock_wait oder fällt in dieser Nacht bewusst aus, ohne dass der Totmann-Alarm losgeht.

Ein Fehler läuft in den Alarm.

12. Störungs-Handbuch für Lars und Thies¶

Flughöhe (Robin, am Entwurf bestätigt): nachsehen, gefahrlos neu starten, sonst Robin oder Thies anrufen. Mehr nicht.

Form (mein Call): 1–2 Seiten Papier neben dem Rack, dazu ein PDF auf Lars' iPhone. Die Doku-Seite taugt dafür nicht, weil sie Internet und Login braucht.

Inhalt (Struktur aus dem Entwurf vom 28.10.):

Was ist los? Symptom → Abschnitt. Kein Internet · Internet geht, aber Heizung, Licht und App nicht · Fotos, Filme, Dokumente nicht · nach einem Stromausfall geht vieles nicht
Nach einem Stromausfall: 10 Minuten warten. Dann der Reihe nach prüfen, ob USV → UDM → UNAS → NUC → aiserver laufen. Ist ein Gerät aus, kurz den Knopf drücken, 5 Minuten warten, erst danach das nächste.
Kein Internet: Anzeige der UDM, Anschluss-Box, UDM neu einstecken.
Heizung oder Home Assistant: Die Thermostate halten die letzte Temperatur, man kann sie am Gerät verstellen. Dann HA im Browser prüfen, sonst den NUC neu starten.
Fotos, Filme, Dokumente: Es geht nichts verloren. Prüfen, ob die UNAS leuchtet, sonst den NUC neu starten.
Bitte nicht: keine Platten ziehen, keinen Stick abziehen, die USV nicht ausschalten, nichts auf Werkseinstellungen zurücksetzen. Im Zweifel so lassen und anrufen.
Zugänge und Telefonnummern

Faktenprüfung vor dem Druck: Knöpfe und Fotos je Gerät, HA-Adresse, Anzeige der UDM, Anschluss-Box, Bedienung der Thermostate, ob es einen Zigbee-Stick gibt. Robin und Lars legen das Blatt einmal gemeinsam neben das Rack und gehen es durch (mein Vorschlag als Abnahme, ersetzt das „real durchgespielt“ aus #179).

Notfallkonten (E1, Teil des Handbuchs): lokale Konten auf den Heimdiensten, die ohne den zentralen Login (Authelia/lldap auf dem VPS) funktionieren. Mindestens Home Assistant für Lars und der Zugang zur UniFi-App. Lars legt sie in seinem Bitwarden ab, Ordner „Zuhause“.

Papierfassung (E1, Robin): Im versiegelten Umschlag liegen die Borg-Passphrasen und Paper-Keys aller Repos und das Passwort des nur lesenden Sub-Accounts restore (Abschnitt 8). Wo er liegt, entscheidet Robin.

13. Configs, Dumps und Appliances¶

Configs ins Git (#71):
- Die borgmatic-Configs aller Hosts kommen ins jeweilige Host-Repo (NUC: homeserver/backup/, aiserver: aiserver/, VPS: homelab-external/).
- Credentials bleiben draußen: Dateien unter /etc/borgmatic.d/credentials/, Quelle der Wahrheit ist Infisical.
- Wie die Configs auf den Host kommen, entscheidet der Umsetzer. Die Lösung muss aber mit bootstrap.sh aus E2b zusammenpassen.
PR #71 (native DB-Hooks) wird geschlossen (mein Call). Scheitert ein nativer Hook, scheitert der ganze Lauf der Config. Damit fiele wegen eines einzelnen Dumps das ganze Backup aus, und genau das soll nicht passieren. Das Dump-Skript bleibt und bekommt einen eigenen Alarm (Abschnitt 10). Die Doku-Teile aus #71, die noch stimmen, wandern in T4.
Dumps einmal pro Nacht statt zweimal, zum Beispiel über einen before: everything-Hook oder einen getrennten Dump-Timer.
Exclude **/backup/* und **/backups/* überarbeiten: Heute schließt das Muster unter anderem /etc/lvm/backup, HA-eigene Backups (14 GB), Immichs eigene DB-Dumps (2,1 GB) und /home/robin/backup aus.
- Bedingung: Rezept „mittel“ muss für Home Assistant funktionieren.
- Redundante Großkopien dürfen draußen bleiben.
- Ob nur das jüngste HA-Backup mitgesichert wird, entscheidet der Umsetzer.
Appliance-Configs: UDM, UNAS-System-Config und das Zigbee-Netzwerk (Coordinator-Backup und Netzwerk-Key) landen regelmäßig als Export auf dem NUC und damit in seinem Backup. Wie der Export abläuft (UniFi-Auto-Backup, API, Z2M-Datenverzeichnis), entscheidet der Umsetzer. Liegt das Coordinator-Backup schon in container-data, genügt der Nachweis.
- Grenze aus Grundsatz 4 (mein Call): Für UDM und UNAS wird automatisch nur exportiert, was ein „View Only“-Konto darf. Reicht das nicht, exportiert Robin vierteljährlich von Hand auf die NUC-Backup-Freigabe, und der Morgenstatus zeigt das Alter des letzten Exports. Ein Admin-Konto oder Root-SSH kommt nicht auf einen Host.
aiserver:
- Live-Config lesen (braucht Robins sudo).
- Passphrase rotieren nach dem Muster aus Runbook 2.
- Ablage in Infisical /borgmatic, Notfallkopie in Proton Pass.

14. Abnahme E1¶

15. Zuschnitt in Teil-Issues (Vorschlag)¶

#	Teil	Inhalt	hängt an
T1	Box-Fundament	borg 1.4.5, `remote_path`, Sub-Accounts auf bestehende Verzeichnisse, Keys tauschen, Hauptaccount-Passwort neu, Snapshot-Plan, rclone-Mount weg, Füllstand über die API	–
T2	UNAS-Ziel	Freigaben, Exporte, Snapshots, Archivordner sichten und umziehen, neue Repos NUC und aiserver, TR-004 parken	T1 (Quellen und Configs)
T3	VPS	Hetzner Cloud Backup, Borg in den Sub-Account `vps`	T1
T4	Configs und Dumps	Configs ins Git, #71, Dumps einmal pro Nacht, Exclude-Review, Appliance-Exporte, aiserver-Rotation	T2
T5	Alarmierung	Healthchecks je Config, Dump-Alarm, Snapshot-Alter, Füllstand, Morgenstatus, automatische Probe	T1–T4
T6	Restore	Handbuch mit drei Rezepten, Proben mit Robin, Ransomware-Probe	T1–T5
T7	Störungs-Handbuch	Faktenprüfung, Blatt, PDF, Notfallkonten, Papierfassung, Durchgang mit Lars	– (parallel möglich)

216 geht in T1–T6 auf und wird danach geschlossen. #71 geht in T4 auf.¶

16. Dem Umsetzer überlassen¶

Konkrete Snapshot-Zeitpunkte (Box in UTC, UNAS) und deren Abstand zum Backup-Fenster.
Wie die Configs auf die Hosts kommen (Abschnitt 13) und wie der Dump-Lauf gebaut ist (Hook oder Timer).
Wo das Morgenstatus-Skript läuft und woher es seine Daten nimmt (Healthchecks-API, Hetzner-API, Journal).
Wie oft verify-data gegen die Box läuft, nach gemessener Bandbreite, mindestens vierteljährlich.
Exportweg je Appliance.
Healthchecks-Grace je Check.
Wie das Snapshot-Alter der UNAS gemessen wird, sofern es einen Weg gibt (Abschnitt 17).

17. Offene Prüfpunkte¶

UNAS:
- Lassen sich Unterordner einer Freigabe getrennt per NFS exportieren, oder braucht es eine Freigabe je Host?
- Wie verhält sich root_squash bei Repo-Dateien?
- Installierte Drive- und OS-Version: Scrubbing ab 4.2.2, der Bremsen-Bug bei der Snapshot-Löschung unter 5.1.8.
- Lässt sich das Snapshot-Alter von außen lesen, über NFS oder mit einem „View Only“-Konto über die API? Gibt es keinen solchen Weg, entfällt die automatische Prüfung für die UNAS, und die Ransomware-Probe prüft die Snapshots einmal von Hand.
Storage Box:
- Sub-Account-Home auf ein vorhandenes Verzeichnis setzen und die Repo-Pfade in den Configs anpassen (/./backups/nuc → Home des Sub-Accounts).
- Gibt es einen Lese-Token in der Hetzner Console, der nur describe darf?
Bandbreite: Download vom Box-Standort nach Hause (für verify-data und Rezept „groß“). Upload ist ein offener D1-Punkt.
VPS: Liste der zu sichernden Pfade, Zeitpunkt des Hetzner-Backups gegenüber dem Borg-Lauf.
Zigbee: Gibt es einen USB-Coordinator am NUC oder einen Netzwerk-Coordinator? Wo liegt das Coordinator-Backup? Das betrifft auch das Störungs-Handbuch.

18. Änderungen an Übergaben und Roadmap¶

Kaltstart-Drill (D1-Übergabe an E1) zieht nach E3 zu #278 und #270. E1 prüft nach einem Neustart nur die Backup-Seite: Mounts da, Lauf grün.
Lars ins Tailnet (bisher E1 T2) zieht nach E5, wo es zum Foto-Upload gehört.
aiserver#9 (BIOS „Power On after power loss“) und der gh-Token auf dem aiserver laufen nebenher als kleine Einzelaufgaben.
D1 Abschnitt 6 gilt mit einer Präzisierung: Die UNAS ist lokales Ziel für den Dienst-Zustand, nicht für die Originale. Die gehen über den NUC direkt zur Box. Der Cluster sichert 2027 nach demselben Muster.
Korrektur an D1 Abschnitt 6: Die Storage Box hat 1 TiB, nicht 931 GiB.
Nebenfund: Der UNAS-Export thies ist für 10.10.10.6 freigegeben, und das ist Robins Laptop. Mit Thies hat er nichts zu tun.