docs 🔀 TP15: CSS326→CRS326 (RouterOS/in-model) + TP20.1 Vaultwarden ausgelagert

- Switches: CSS326-Fehlbestellung storniert, 2x CRS326-24G-2S+RM bestellt → RouterOS-fähig, damit in MikroMCP + Nautobot Golden Config (in-model statt SwOS-Insel). Kein PoE → EAP via Injektor.
- TP21 Scope-Grenze: Golden Config deckt jetzt Router + beide CRS-Switches (ganzer Kabel-Fabric); außerhalb nur noch Omada-WLAN.
- TP20.1 neu: Vaultwarden MariaDB→PG-Migration + Cross-Site-2-Site-HA aus TP20 ausgelagert (User-Wunsch). TP20 = reine Plattform (Cluster/Tiering/Backup/Nautobot-DB).

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

docs/teilprojekte.md

@@ -323,9 +323,9 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung".
 
 ### TP15 — HW-Refresh: Switching + WLAN-Ecosystem + DC-USV ▸ 🟡 ENTSCHIEDEN, Beschaffung läuft (2026-07-14) — `docs/hw-refresh-requirements.md`, Memory `project_mikrotik_commit_nautobot_gc`
 - **🧭 Grundsatzentscheid (2026-07-14): Ecosystem-Split nach Layer.** **MikroTik = config-gemanagter Kern** (Routing/L3/CAKE + alle Switches), **Omada = ausschließlich WLAN**. Begründung: Projektziel #1 **CAKE** nur RouterOS/OpenWrt/OPNsense (Omada-Gateway kann kein CAKE); WLAN = Schmerzpunkt → Omada-EAP; Switching = MikroTik. Grenze **„MikroTik = Kabel+Routing, Omada = Funk"** deckt sich mit den 2 bestehenden Control-Planes (MikroMCP + Omada-Controller). Verworfene Vollvarianten (Omada-only, MikroTik-only) samt Begründung + Ansible/Nautobot-Recherche → Memory.
-- **🛒 Switches: 2× CSS326-24G-2S+RM im Zulauf (2026-07-14).** 24×1G + 2×SFP+, lüfterlos, DC-input (USV-tauglich). Lösen ALLNET-Core (sw1) + Omada-ES208G (sw2 raus aus Switching-Rolle) + Cudy ab.
-  - ⚠️ **CSS = SwOS-only, KEIN RouterOS** → **außerhalb** MikroMCP/Nautobot-Golden-Config; VLANs statisch per SwOS-Web-UI. Die Config-as-Code-Grenze liegt damit am RouterOS-**Router**, nicht an den Switches. ⚠️ **kein PoE** → Omada-EAPs + Sonoff via **PoE-Injektoren**.
-  - 🚩 **Offener Flag (Switches „im Zulauf", noch änderbar):** wer die Switches *im* Golden-Config-Modell will → **CRS326-24G-2S+RM** (RouterOS, +~€50/St.) statt CSS. Sonst CSS = bewusste, billigere SwOS-L2-Insel (für statische VLANs robust).
+- **🛒 Switches: 2× CRS326-24G-2S+RM bestellt (2026-07-14 — CSS326-Fehlbestellung storniert → CRS).** 24×1G + 2×SFP+, lüfterlos, DC-input (USV-tauglich). Lösen ALLNET-Core (sw1) + Omada-ES208G (sw2 raus aus Switching-Rolle) + Cudy ab.
+  - ✅ **CRS = RouterOS-fähig → in-model:** MikroMCP-Write + Nautobot Golden Config (TP21) managen auch die **Switches**, nicht nur den Router → config-as-code deckt den **ganzen Kabel-Fabric**. (SwOS-Boot bliebe als Fallback möglich, aber nicht genutzt.)
+  - ⚠️ **kein PoE** → Omada-EAPs + Sonoff via **PoE-Injektoren**.
 - **📶 WLAN → Omada EAPs** (ersetzt hAP-Funk + CAPsMAN): löst CAP-ARP/Broadcast-Quirks (P750W-Fall), reifes 802.11k/v/r-Roaming, VLAN→SSID im bereits laufenden Controller. hAP ax² werden Reserve. (Ersetzt die alte hAP-be³-Linie dieses Docs.)
 - **🧭 Router → RB5009 (mittelfristig):** L3/CAKE/Firewall vom hAP ax² lösen (device-mode=home blockt scheduler/fetch; „AP=Router"-Fragilität) → dedizierte RouterOS-Box, in MikroMCP + Nautobot. hAP ax² danach nur noch WLAN/Reserve.
 - **🔋 DC-USV** (unverändert gültig): MeanWell LRS-150-48 + DDR-120-48 + LiFePO4 20Ah (~€190), 48V-Bus; CSS326 DC-input passt.
@@ -410,17 +410,24 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung".
 ### TP20 — Platform-Datenbank (Postgres Precious-Tier + MariaDB Tier-2) ▸ 🔜 KONZEPT (2026-07-14) — Memory `project_mikrotik_commit_nautobot_gc`
 - **Auslöser:** Mehrere Dienste brauchen zentrale DB (Nautobot-SoT [TP21], Vaultwarden, HA-Recorder). Grundsatzentscheid statt Nautobot-Insellösung — „wir skalieren schneller als wir schauen können" (User).
 - **✅ 2-Tier (User 2026-07-14):**
-  - **Tier-1 „Platform-Postgres" (precious):** EIN Postgres-Cluster, getrennte DBs für **Nautobot + Vaultwarden**. **PG 16** (Nautobot-Matrix-safe; **Nautobot unterstützt kein MariaDB**, nur PG/MySQL-8 → Postgres ist gesetzt, nicht optional).
-  - **Tier-2 (Bestand):** **HA-Recorder + Vaultwarden laufen aktuell auf MariaDB.** HA **bleibt** MariaDB (Write-Churn, andere Zuverlässigkeitsklasse, single-site). **Vaultwarden migriert MariaDB→Postgres** (in Tier-1 hochgezogen). Engine-Split fällt sauber entlang der Tier-Grenze. *(Alternative, dokumentiert-aber-verworfen: vw auf MariaDB lassen + MariaDB-Repl — verworfen zugunsten EINER Replikations-/Backup-Mechanik im Precious-Tier.)*
+  - **Tier-1 „Platform-Postgres" (precious):** EIN Postgres-Cluster, getrennte DBs für **Nautobot** (hier provisioniert) **+ Vaultwarden** (Onboarding = **TP20.1**). **PG 16** (Nautobot-Matrix-safe; **Nautobot unterstützt kein MariaDB**, nur PG/MySQL-8 → Postgres ist gesetzt, nicht optional).
+  - **Tier-2 (Bestand):** **HA-Recorder bleibt MariaDB** (Write-Churn, andere Zuverlässigkeitsklasse, single-site). *(Vaultwarden liegt heute ebenfalls auf MariaDB → wandert per TP20.1 nach Tier-1.)* Engine-Split fällt sauber entlang der Tier-Grenze.
 - **✅ Single-Site-first (User 2026-07-14):** jetzt nur BF-Primary. Nimmt das **2-Site-Quorum/Split-Brain**-Problem (bräuchte 3. Witness) vom Tisch. **ABER replication-ready ab Tag 1:** `wal_level=replica`, `archive_mode=on`, **pgBackRest (WAL+Base) → Garage-S3 (TP18)** = PITR sofort (DR auch ohne Standby) + späterer Standby = `pg_basebackup`, **kein** Primary-Umbau/Restart.
 - **Substrat:** Postgres in **LXC auf pve** (DB-Klasse, nicht Docker).
-- **Phase 2 (später):** Cross-Site-Standby für Vaultwarden — `db-platform-standby`-LXC am 2. Standort, Streaming-Replication über WG (TP10), manuelles Promote-Runbook. Patroni + Witness nur falls Auto-Failover gewünscht.
-- **Offene Sub-Steps:** Vaultwarden MariaDB→PG-Migration (`vw` .20.127); pgBackRest-Bucket in Garage (Abh. TP18-Startpfad ①); PG-Version final (16 vs 17).
-- Abh.: **TP18** (Garage-S3 für Backups — mind. BF-Node ①), **TP10** (WG-Transport für Phase-2). **Blockt TP21.**
+- **Scope TP20 = Plattform:** Cluster hoch, Tiering, Backup/PITR, **Nautobot-DB** anlegen. **vw-Migration + Cross-Site-HA = TP20.1** (ausgelagert).
+- **Offene Sub-Steps:** pgBackRest-Bucket in Garage (Abh. TP18-Startpfad ①); PG-Version final (16 vs 17); Rollen/DB-Anlage Nautobot.
+- Abh.: **TP18** (Garage-S3 für Backups — mind. BF-Node ①). **Blockt TP21 + TP20.1.**
+
+#### TP20.1 — Vaultwarden → Platform-Postgres + Cross-Site-HA ▸ 🔜 KONZEPT (2026-07-14, ausgelagert aus TP20)
+- **Ziel:** `vw` (`.20.127`, heute MariaDB) auf den Precious-Tier holen **und** das eigentliche User-Ziel erfüllen: **DB-Replikation über 2 Sites** (Standort-Verlust überlebbar).
+- **Phase 1 — Migration (single-site):** vw **MariaDB→Postgres** (Export → Import in Tier-1-DB `vaultwarden` → `DATABASE_URL` umstellen → verifizieren). Danach ist vw precious + im pgBackRest/PITR-Schirm von TP20. *(Alternative verworfen: vw auf MariaDB lassen + MariaDB-Repl — zugunsten EINER Replikations-/Backup-Mechanik im Precious-Tier.)*
+- **Phase 2 — Cross-Site-Standby:** `db-platform-standby`-LXC am 2. Standort → `pg_basebackup`/Streaming-Replication über **WG (TP10)** → **manuelles Promote-Runbook**. Repliziert den ganzen Tier-1-Cluster (vw = HA-Ziel, Nautobot bekommt Gratis-DR-Kopie). **Patroni + 3. Witness** nur, falls später Auto-Failover statt manuellem Promote gewünscht.
+- **Verwandt/Abgrenzung:** vw ist auch in **TP16** offen (CF-Access: `bypass`→WARP-geschützt) — **DB-HA ≠ Access**, getrennt behandeln. Reziprokes 2-Site-Muster analog **TP16**/**TP18**.
+- Abh.: **TP20** (Tier-1 Postgres muss stehen), **TP10** (WG-Transport für Phase-2), **TP18** (Backup-Schirm). Kein Blocker für TP21.
 
 ### TP21 — Nautobot Golden Config (config-as-code Control-Plane) ▸ 🔜 KONZEPT (2026-07-14) — Memory `project_mikrotik_commit_nautobot_gc`
 - **Ziel:** modellierter Control-Plane über den MikroTik-**RouterOS**-Kern: GUI-SoT + **Config-Compliance/Drift** + intended-config + Push. **Ergänzt** MikroMCP (interaktiv/Debug), **ersetzt es nicht** (deklarativ/DR/Compliance). Aus User-Recherche 2026-07-14: MikroTik in Golden Config **erstklassig** (`mikrotik_routeros` + `_api`, Nornir/NAPALM, backup+deploy).
-- **Scope-Grenze (wichtig):** RouterOS in-model (ap1 heute / RB5009 künftig). **CSS326-Switches = SwOS = NICHT in Golden Config** (s. TP15-Flag); **Omada-WLAN = eigener Controller**. Golden Config deckt also den **RouterOS-Router**, nicht den ganzen Fabric. *(Wenn Switches in-model sollen → CRS statt CSS, TP15-Flag.)*
+- **Scope-Grenze:** RouterOS in-model = **Router (ap1 heute / RB5009 künftig) + beide CRS326-Switches** (RouterOS-Boot) → Golden Config deckt den **ganzen Kabel-Fabric**. Außerhalb bleibt nur **Omada-WLAN** (eigener Controller).
 - **Stack:** `nautobot-docker-compose` (Django/gunicorn + Redis + Celery worker/beat) auf Docker-Host; **DB extern → Platform-Postgres (TP20)**; Redis lokal/ephemer; **Git-Backend (backups/intended/templates) → bestehendes Gitea** (`project_gitea_backup_state`).
 - **PoC-Pfad:** Nautobot-Stack hoch → ap1 via RouterOS-API adoptieren → Backup + Compliance/Drift an *einem* Gerät zeigen → dann Templates/intended für VLAN-/Firewall-Standards.
 - **Offen:** Nautobot- + GC-App-Version; ob OpenWrt je in-model muss (custom Nornir-Dispatcher — nur relevant falls Router doch OpenWrt+cake-autorate statt RB5009).
@@ -447,4 +454,4 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung".
    ⏳ **TP3.3 (WLAN-Coverage-Kur) offen** — Fortsetzung neue Session (`docs/wifi-p750w-coverage-and-map.md`).
 5. ~~**TP10 (VPN)**~~ ✅ Kern durch (2026-06-27) + Edge-Cutover (2026-07-01) → DURCH. Offen nur: DDNS-Auto-Updater.
 6. **Nachgelagert/Research-getrieben:** TP8 (Access), TP9 (HA), TP11 (Monitoring + CF-Tunnel-Track-B/C), TP12 (IPv6), TP13 (Spaß).
-7. **Foundation (2026-07-14):** **TP15** (MikroTik-Switching / Omada-WLAN, 2× CSS326 im Zulauf) ∥ **TP20 (Platform-Postgres, single-site replication-ready)** → **TP21 (Nautobot Golden Config)**. TP20 hängt an **TP18 ①** (Garage-Bucket für pgBackRest).
+7. **Foundation (2026-07-14):** **TP15** (MikroTik-Switching / Omada-WLAN, 2× CRS326 bestellt) ∥ **TP20 (Platform-Postgres, single-site replication-ready)** → **TP21 (Nautobot Golden Config)** ∥ **TP20.1 (Vaultwarden→PG + 2-Site-HA)**. TP20 hängt an **TP18 ①** (Garage-Bucket für pgBackRest).