docs: H:-Nearline als Restore-Quelle im DR-Fall dokumentieren

Bisher war die H:-Nearline-Kopie nur als Backup-Ziel beschrieben
(CAPACITY_AND_LIFECYCLE), nicht als Restore-Quelle. Im Ernstfall fehlte der
Hinweis, dass auf baerchen eine frische lokale Kopie aller Dumps + Bundles
liegt.

- ops/h-drive-nearline/README.md: neuer Abschnitt "Restore aus H:/ (DR-Fall)"
  mit Inhalt, Rueckspiel-Weg (-> RESTORE_MATRIX / SERVICES_RECOVERY) und
  Pflicht-Frische-Pruefung (deckt den S4U-Stale-Fall ab).
- docs/DISASTER_RECOVERY.md: baerchen-Abschnitt verweist jetzt auf die
  H:-Fallback-Restore-Quelle und das Runbook.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

docs/DISASTER_RECOVERY.md

@@ -532,8 +532,13 @@ Smoke-Test: `hermes-gateway` healthcheck ist gruen, `hermes.kaleschke.info` leit
 ### Windows-Workstation `baerchen`
 
 `baerchen` ist die Operator-Workstation und haelt den lokalen Clone unter
-`G:\Gitea_Clone\homelab-infra`. Fuer einen schnellen Windows-Bare-Metal-Restore
-existiert ein Veeam-Agent-Image-Workflow.
+`G:\Gitea_Clone\homelab-infra`. Zusaetzlich liegt auf der externen Platte `H:`
+(`H:\kallilab-nearline-backups`) eine taegliche Nearline-Kopie der DB-Dumps,
+Gitea-Bundles und des DR-Kits als **lokale Fallback-Restore-Quelle**, falls
+Unraid/Hetzner nicht erreichbar sind. Restore-Weg und Pflicht-Frische-Pruefung:
+`ops/h-drive-nearline/README.md` Abschnitt "Restore aus H:/ (DR-Fall)". Fuer
+einen schnellen Windows-Bare-Metal-Restore existiert ein
+Veeam-Agent-Image-Workflow.
 
 Wichtige Pfade und Artefakte:
 

ops/h-drive-nearline/README.md

@@ -25,6 +25,30 @@ Nichts weiteres gehört dauerhaft auf die H:/.
 Temporäre Recovery- oder Backup-Ordner aus Notfallsituationen sind nach
 Abschluss zu löschen.
 
+## Restore aus H:/ (DR-Fall)
+
+Wenn Unraid/Hetzner nicht erreichbar sind, ist die H:/ die schnellste **lokale**
+Quelle für die aktuellsten DB-Dumps und Gitea-Bundles. Sie ersetzt **nicht** die
+Hetzner-Borg-Kette (Einordnung: `docs/CAPACITY_AND_LIFECYCLE.md`), verkürzt aber
+den Wiederanlauf, solange die Artefakte frisch sind.
+
+Inhalt und Restore-Weg:
+
+- **DB-Dumps:** `H:\kallilab-nearline-backups\borg-dumps\latest\*` — dieselben
+  Dateien wie `/mnt/user/backups/borg/dumps/latest`. Im DR-Fall auf den neu
+  aufgesetzten Host nach `/mnt/user/backups/borg/dumps/latest` zurückspielen
+  (SMB/Robocopy), dann pro Dienst nach `docs/RESTORE_MATRIX.md` einspielen.
+- **Gitea-Bundles:** `H:\kallilab-nearline-backups\git-bundles\gitea\` — bare
+  Repo-Bundles für den Gitea-Bootstrap (Reihenfolge: `docs/SERVICES_RECOVERY.md`).
+- **DR-Kit (Keys/Secrets):** `H:\kallilab-nearline-backups\_dr-kit\` — SSH-Keys
+  und Offline-Secrets, siehe Abschnitt `_dr-kit` unten.
+
+> **Vor dem Verlassen auf H:/ immer die Frische prüfen:** Die LastWriteTime der
+> Dumps muss vom selben Tag sein
+> (`Get-ChildItem H:\kallilab-nearline-backups\borg-dumps\latest`). Ein still
+> veralteter Spiegel (siehe S4U-Vorfall unten) ist als Restore-Quelle wertlos —
+> dann stattdessen aus Hetzner-Borg restaurieren.
+
 ## Automatischer Pull
 
 `pull-critical-backups.ps1` zieht per Robocopy vom Unraid-SMB-Share: