Add FRITZBox correction plan and offsite options

Two operator decision documents, doc-only, no live action:

- docs/FRITZBOX_PORT_CORRECTION_PLAN.md prepares the three open
  router items: remove 80/tcp (no HTTP-01 in use), do not add
  222/tcp while Tailscale remains the operator path, deactivate
  the UPnP self-exposure from PC-192-168-178-71. Every step waits
  for operator go.

- docs/OFFSITE_BACKUP_OPTIONS.md compares rsync.net, BorgBase EU2
  and rotating cold disk for a second offsite target. Recommends
  rsync.net or cold disk; BorgBase EU2 is explicitly not
  recommended because it does not separate the provider risk.
  No provider booked, no costs triggered.

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

docs/FRITZBOX_PORT_CORRECTION_PLAN.md

@@ -0,0 +1,94 @@
+# FRITZ!Box Portfreigaben - Korrektur-Vorbereitung
+
+Status: **Vorbereitung (Doku-only)**, 2026-05-27. Keine Router-Aenderung.
+Audit-Bezug: `docs/AUDIT_2026-05-25_TODO.md` Sprint 4 ("FRITZ!Box-Portfreigaben gegen Repo-Soll abgleichen") und `docs/NETWORK_INVENTORY.md`.
+
+## Aktueller FRITZ!Box-Befund (2026-05-27)
+
+Aus dem Operator-Live-Check der FRITZ!Box-UI:
+
+- aktiv: `80/tcp` -> `192.168.178.58`
+- aktiv: `443/tcp` -> `192.168.178.58`
+- fehlt: `222/tcp` -> `192.168.178.58` (Gitea-SSH)
+- zusaetzlich gemeldet: eine Portfreigabe durch das Geraet `PC-192-168-178-71` (Selbst-Freigabe per UPnP)
+
+## Soll-Stand laut Repo
+
+`docs/NETWORK_INVENTORY.md` definiert genau zwei aktive Portfreigaben:
+
+| Erwartete Freigabe | Ziel | Begruendung |
+|---|---|---|
+| `443/tcp` -> `192.168.178.58:443` | Traefik HTTPS | einziger Public-HTTPS-Einstieg, Wildcard-Zert ueber Cloudflare-DNS-Challenge |
+| `222/tcp` -> `192.168.178.58:222` | Gitea SSH | Git-SSH-Push/Pull; dokumentierte Ausnahme |
+
+Port `80/tcp` ist im Cloudflare-DNS-Challenge-Modell **nicht** notwendig.
+
+## Drei Korrektur-Punkte
+
+### 1. `80/tcp` entfernen
+
+Begruendung:
+
+- ACME laeuft als Cloudflare-DNS-Challenge (`traefik/docker-compose.yml`), nicht als HTTP-01.
+- Traefik leitet intern jeden HTTP-Request auf `https://` weiter; ein WAN-`80`-Listener bietet keinen Mehrwert, oeffnet aber einen zusaetzlichen Angriffsvektor (Header-/Method-Scanning, Open-Redirect-Versuche bevor TLS terminiert).
+- Innerhalb des LAN funktioniert die Browser-Auto-HTTPS-Umleitung weiter ueber AdGuard-DNS.
+
+Empfehlung: WAN-Eintrag `80/tcp` in FRITZ!Box-UI **entfernen** nach Operator-Go.
+
+Validierung nach Aenderung:
+
+```bash
+# WAN-seitiger Test, idealerweise von einem Geraet im Mobilfunknetz oder Tailscale-Exit-Node
+curl -sI http://kaleschke.info/   # erwartet: Connection refused / Timeout
+curl -sI https://vault.kaleschke.info/   # erwartet: HTTP/2 200 oder Authelia-Redirect
+```
+
+### 2. `222/tcp` ergaenzen (nur wenn externes Git-SSH wirklich gewuenscht)
+
+Frage an Operator: Wird `git@git.kaleschke.info -p 222` von extern gebraucht? Hinweise:
+
+| Pro `222/tcp` extern | Contra `222/tcp` extern |
+|---|---|
+| Push/Pull vom unterwegs-Laptop ohne Tailscale | Tailscale ist schon der Operator-Pfad, deckt das voll ab |
+| GitHub-Mirror-Bootstrap funktioniert dann auch ohne Tailscale | GitHub-Push-Mirror laeuft automatisch von Gitea aus, braucht kein WAN-SSH |
+| Externe Webhooks gegen Git push (nicht in Nutzung) | weniger Angriffsflaeche fuer SSH-Brute-Force |
+
+Empfehlung: `222/tcp` **nicht** ergaenzen, solange Tailscale stabil verfuegbar ist. Stattdessen `docs/NETWORK_INVENTORY.md` und `HOMELAB_ARCHITECTURE_MASTER_V2.md` darauf abgleichen, dass Gitea-SSH bewusst LAN/Tailscale-only ist.
+
+Wenn Operator entscheidet, `222/tcp` doch extern zu oeffnen: zusaetzlich SSH-Login auf Key-only setzen, Brute-Force-Limits in Gitea pruefen, `docs/NETWORK_INVENTORY.md` "Erwartete Freigabe"-Tabelle aktualisieren.
+
+### 3. UPnP-Selbstfreigabe von `PC-192-168-178-71` deaktivieren
+
+Begruendung:
+
+- Geraete-initiierte Portfreigaben (UPnP) sind ausserhalb der Repo-Sollkonfiguration.
+- Welcher Port von welchem Programm geoeffnet wurde, ist aus der FRITZ!Box-UI heraus nicht versionierbar.
+- Wenn der Port gebraucht wird, gehoert er als bewusste Operator-Freigabe in `docs/NETWORK_INVENTORY.md`.
+
+Empfehlung in zwei Stufen:
+
+1. FRITZ!Box-UI: in den Geraete-Details fuer `PC-192-168-178-71` die aktuelle Selbstfreigabe-Liste pruefen und mit dem Operator besprechen.
+2. Wenn der Port nicht gebraucht wird: Selbstfreigabe deaktivieren. Optional: UPnP global pro Geraet abschalten ("Selbststaendige Portfreigaben fuer dieses Geraet erlauben" abwaehlen).
+
+## Schutzregeln
+
+- Keine Router-Aenderung ohne ausdrueckliches Operator-Go.
+- Nach jeder Aenderung: `docs/NETWORK_INVENTORY.md` Abschnitt "FRITZ!Box (WAN -> Host)" gegen den neuen UI-Stand abgleichen.
+- Aenderung in `docs/MIGRATION_LOG.md` als kurzer Eintrag dokumentieren (was/warum/Validierung).
+- Bei `80/tcp`-Entfernung kurz prufen, ob irgendein externer Dienst noch HTTP-01 nutzen wollte (sollte nicht der Fall sein).
+
+## Nicht Teil dieser Vorbereitung
+
+- FRITZ!OS-Update 8.21 -> aktuell. Das ist eigenes Service-Fenster und braucht WAN/Tailscale-Aufbau-Beobachtung.
+- IPv6-Exposure. Wenn Telekom IPv6 zustellt und Apps via Cloudflare-AAAA erreichbar sind, kann WAN-Filter pro Port noetig werden. Separater Doku-Punkt in `docs/NETWORK_INVENTORY.md` Offene Entscheidungen.
+- Mobilfunk-Failover-Stick. Bewusst nicht eingerichtet.
+
+## Offene Punkte
+
+| Status | Punkt | Naechster Schritt |
+|---|---|---|
+| offen (Operator-Go) | `80/tcp` entfernen | FRITZ!Box-UI, danach `docs/NETWORK_INVENTORY.md` aktualisieren |
+| offen (Operator-Go) | `222/tcp` Entscheidung | Operator klaert: extern noetig oder Tailscale-only |
+| offen (Operator-Go) | UPnP-Freigabe `PC-192-168-178-71` | FRITZ!Box-UI Geraete-Detail pruefen |
+| offen | FRITZ!OS 8.21 Update | Service-Fenster, separat geplant |
+| offen | IPv6-Exposure pruefen | bei naechstem WAN-Touch mit erfassen |

docs/OFFSITE_BACKUP_OPTIONS.md

@@ -0,0 +1,104 @@
+# Zweites Offsite-Backup-Ziel - Entscheidungsvorlage
+
+Status: **Entscheidungsvorlage (Doku-only)**, 2026-05-27. Kein Provider gebucht, keine Kosten ausgeloest.
+Audit-Bezug: `docs/AUDIT_2026-05-25.md` Finding **F-03** und `docs/AUDIT_2026-05-25_TODO.md` Sprint 7.
+
+## Zweck
+
+Aktuell laeuft das Off-site-Backup bei genau einem Anbieter (**Hetzner Storage Box**). Diese Vorlage stellt drei realistische Optionen fuer ein **zweites** Off-site-Ziel gegenueber. Die Entscheidung trifft der Operator; dieses Dokument trifft sie nicht.
+
+`H:/` am Windows-PC bleibt **kein** Offsite-Ersatz (siehe `docs/CAPACITY_AND_LIFECYCLE.md`). H:/ ist Nearline-Kopie am gleichen Standort.
+
+## Anforderungen an das zweite Ziel
+
+| Anforderung | Begruendung |
+|---|---|
+| **anderer Anbieter als Hetzner** | Provider-Risiko (Account-Sperre, Insolvenz, Region-Outage) wird sonst nicht reduziert |
+| **anderer physischer Standort** als Unraid-Host | Brand-/Diebstahl-/Wasser-Schutz |
+| **Borg-kompatibel** (SSH + Repo-Layout) | bestehendes Borg-UI-Setup soll wiederverwendbar bleiben |
+| **bezahlbar im Privatrahmen** | grobe Zielgroesse: < 10 EUR / Monat fuer ~1 TB |
+| **stabil ueber Monate** | wenig Eingriff, keine taeglichen Quirks |
+| **keine Konto-Komplexitaet** | 2FA-Recovery muss sauber, ohne Telefon-Nummer-Hacks etc. moeglich sein |
+
+## Drei Optionen
+
+### Option A - rsync.net Borg-Plan
+
+- **Was:** seit Jahren etablierter Anbieter mit dediziertem Borg-Plan (eingebaute `borg`-Binary, SSH-Account, Snapshot-Schutz).
+- **Zielanbindung:** `borg init --encryption=repokey-blake2 user@hostname:repo`.
+- **Standort:** Schweiz/USA (je nach Konto-Region).
+- **Preis (Stand 2026, grob):** ~10-15 USD pro Monat fuer 1 TB; Mindestbestelldauer keine.
+- **Vorteile:** Borg-First, ZFS-Snapshots als zusaetzlicher Schutz vor Repo-Loeschung, sehr lange Track-Record, keine SMB-/CIFS-Quirks.
+- **Nachteile:** USD-Preis, Standort ausserhalb EU je nach Konto, etwas teurer als reine Storage Boxes.
+- **Konto-Risiko:** unabhaengig von Hetzner-Konto.
+
+### Option B - BorgBase EU2 (zweite Region beim gleichen Borg-Spezialisten)
+
+- **Was:** BorgBase ist Borg-as-a-Service mit mehreren Regionen.
+- **Zielanbindung:** identisch zu bestehendem Borg-UI-Pfad.
+- **Standort:** zweite EU-Region als EU1.
+- **Preis (Stand 2026, grob):** ~10 EUR / Monat fuer ~1 TB.
+- **Vorteile:** identisches Borg-Modell, geringer Lernaufwand, einfache Web-UI.
+- **Nachteile:** Anbieter-Risiko nicht vollstaendig getrennt (gleicher Anbieter, andere Region). Bei Account-Sperre/Insolvenz waeren beide Ziele gleichzeitig betroffen.
+- **Konto-Risiko:** **gleicher** Anbieter, **anderes** Geo-Risiko.
+
+### Option C - Rotierende Cold-Wechselplatte ausser Haus
+
+- **Was:** zweite externe HDD (z. B. 2x WD Elements 4 TB), die im monatlichen Wechsel zwischen Heim-LAN und vertrauter dritter Person (Familie, Schliessfach, Buero) rotiert.
+- **Zielanbindung:** Borg-Repo lokal auf der eingesteckten Platte; Backup-Lauf nur wenn die Platte gerade vor Ort ist.
+- **Standort:** echtes Ausserhaus, dazwischen offline (Air-Gap).
+- **Preis (einmalig):** zwei Platten ~250 EUR, keine laufenden Kosten.
+- **Vorteile:** echtes Air-Gap, keine Provider-Abhaengigkeit, keine Bandbreitenfrage, keine Konto-Risiken.
+- **Nachteile:** manuelle Disziplin noetig, Recovery-Zeit haengt davon ab, dass die Platte gerade erreichbar ist. Nicht so taggenau wie Cloud-Borg.
+- **Konto-Risiko:** keines (keine Provider-Bindung).
+
+## Bewertung gegen die Anforderungen
+
+| Anforderung | Hetzner (Ist) | Option A rsync.net | Option B BorgBase EU2 | Option C Cold-Platte |
+|---|---|---|---|---|
+| Anderer Anbieter | - | ja | nein (gleicher) | ja (keiner) |
+| Anderer Standort | - | ja | ja | ja |
+| Borg-kompatibel | ja | ja | ja | ja |
+| Preis < 10 EUR/Monat | ja | grenzwertig | ja | einmalig ~250 EUR |
+| Stabilitaet | hoch | hoch | hoch | Operator-Disziplin abhaengig |
+| 2FA/Konto-Recovery | OK | OK | OK | n/a |
+
+## Empfehlung (nicht Entscheidung)
+
+Wenn der Operator die geringste Bedienung bei maximalem Provider-getrennten Schutz will: **Option A rsync.net**. Echte Anbieter-Trennung gegenueber Hetzner, Borg-First-Anbieter, ZFS-Snapshot-Schutz, keine zusaetzliche Hardware noetig.
+
+Wenn Air-Gap und Null-Provider-Abhaengigkeit am wichtigsten sind und der Operator die monatliche Rotation tatsaechlich diszipliniert macht: **Option C Cold-Platte**.
+
+**Option B (BorgBase EU2) wird nicht empfohlen** als zweites Ziel, weil das das Provider-Risiko nicht reduziert.
+
+## Was vor einer Buchung zu tun ist
+
+1. Operator-Entscheidung Option A vs. C dokumentieren (kein Provider-Kontakt vor Entscheidung).
+2. Falls Option A:
+   - Konto bei rsync.net anlegen, Borg-Plan waehlen.
+   - SSH-Key vom Borg-UI-Container exportieren bzw. dediziertes Key-Pair erzeugen.
+   - `borg init` gegen das neue Repo durchfuehren (separate Passphrase oder gleiche - bewusst entscheiden).
+   - Borg-UI um zweites Repository erweitern (separater Eintrag, kein Replace).
+   - Schedule pruefen: erstes Vollbackup als One-Shot, danach inkrementell.
+   - `docs/SECRETS_MAP.md` und `docs/EXTERNAL_DEPENDENCIES.md` um neuen Provider ergaenzen.
+   - `docs/RESTORE_MATRIX.md` und `docs/STORAGE_LAYOUT.md` Backup-Ziel-Liste aktualisieren.
+3. Falls Option C:
+   - zwei Platten beschaffen, Filesystem XFS oder ext4 (kein NTFS).
+   - Rotations-Plan in `docs/STORAGE_LAYOUT.md` §8.1 ergaenzen.
+   - Borg-Repo-Init pro Platte; Borg-UI um lokales Repo erweitern (nur aktiv wenn Platte eingesteckt).
+   - Operator-Disziplin: monatliche Rotation als Kalender-Reminder.
+
+## Was bewusst NICHT in dieser Vorlage steht
+
+- Konkrete Hetzner-Konto-Daten, rsync.net-Accountnamen, IBANs, Telefonnummern. Diese Daten gehoeren nirgendwo in dieses Repo.
+- Borg-Passphrasen. Bleiben ausserhalb des Repos.
+- "Migrieren weg von Hetzner" als Option. Hetzner bleibt; das zweite Ziel ist Ergaenzung, nicht Ablosung.
+
+## Offene Punkte
+
+| Status | Punkt | Naechster Schritt |
+|---|---|---|
+| offen | Entscheidung Option A vs. C | Operator |
+| offen | Budget-Freigabe | Operator |
+| offen | Provider-/Hardware-Beschaffung | nach Entscheidung |
+| offen | Schedule-Anpassung in `ops/borg-ui` | nach Provider-Bereitstellung |