Micha/homelab-infra
1
0
Fork 0
Code Issues 1 Pull Requests 5 Actions Packages Projects Releases Wiki Activity

Compare commits

base: Micha/homelab-infra:renovate/traefik-v3.7
Branches Tags
Micha/homelab-infra:master Micha/homelab-infra:renovate/minor-patch-updates Micha/homelab-infra:renovate/docker.n8n.io-n8nio-n8n-2.x Micha/homelab-infra:renovate/nextcloud-34.x Micha/homelab-infra:renovate/nextcloud-33.0.5-apache Micha/homelab-infra:renovate/shaanmajid-unbound-1.25.1 Micha/homelab-infra:renovate/postgres-18.4 Micha/homelab-infra:codex/smart-home-foundation Micha/homelab-infra:renovate/traefik-v3.7
Micha/homelab-infra:audit-2026-05-25-baseline
..
compare: Micha/homelab-infra:8edc2c239488052ad40492b5d82e38a2d0934a81
Branches Tags
Micha/homelab-infra:renovate/minor-patch-updates Micha/homelab-infra:master Micha/homelab-infra:renovate/docker.n8n.io-n8nio-n8n-2.x Micha/homelab-infra:renovate/nextcloud-34.x Micha/homelab-infra:renovate/nextcloud-33.0.5-apache Micha/homelab-infra:renovate/shaanmajid-unbound-1.25.1 Micha/homelab-infra:renovate/postgres-18.4 Micha/homelab-infra:codex/smart-home-foundation Micha/homelab-infra:renovate/traefik-v3.7
Micha/homelab-infra:audit-2026-05-25-baseline

1 Commits
renovate/traefik-v3.7 .. 8edc2c2394

Author SHA1 Message Date
renovate 8edc2c2394 chore(deps): update mongo:8.0.23 docker digest to f93b901 2026-06-02 16:20:22 +00:00
128 changed files with 335 additions and 8663 deletions
Expand all files Collapse all files
.gitignore
-2
View File
@@ -28,5 +28,3 @@ Thumbs.db
*.tmp
*.log
.serena/
.claude/settings.local.json
memory/
CLAUDE.md
+1 -1
View File
@@ -90,7 +90,7 @@ Wenn Drift vermutet wird, nicht raten. Erst die Pflichtmatrix in `docs/GITOPS_DR
- `traefik`: Host-Ports 80/443
- `gitea`: SSH-Port 222
- `AdGuard Home`: DNS-Port 53 und LAN-Admin-Port 8082
- `tailscale`: natives Unraid-Plugin (`tailscale.plg`, Interface `tailscale1`), Subnet-Router fuers LAN; nicht repo-/Komodo-verwaltet. Der frueher repo-verwaltete userspace-Docker-Stack `host-services/tailscale/` wurde am 2026-06-06 entfernt.
- `tailscale`: `network_mode: host`
- `Plex-Media-Server`: historischer Host-Netz-Sonderfall, nicht als Repo-Stack enthalten
- `scrutiny`: `privileged: true` fuer SMART/Laufwerkszugriff
- `Komodo`: Docker-Socket und native Auth ohne pauschale ForwardAuth
HOMELAB_ARCHITECTURE_MASTER_V2.md
+4 -23
View File
@@ -145,7 +145,6 @@ Diese Dienste sind über echte `*.kaleschke.info`-Domains erreichbar:
- `gitea` (Web) — git.kaleschke.info
- `immich_server` — immich.kaleschke.info
- `nextcloud` — cloud.kaleschke.info
- `plex` — plex.kaleschke.info (Traefik, native Plex-Auth; Plex Remote Access/Port 32400 bleibt aus)
### 4.2 Nicht öffentlich / nur Tailscale oder Traefik + Middleware
Diese Dienste sind **keine Public Apps**:
@@ -241,7 +240,7 @@ Legende Status:
| `AdGuard Home` | ✅ | `dns_net` (172.23.0.3), `frontend_net` | Port 53 DNS direkt, Port 8082 Admin nur auf Tailscale-IP `100.80.98.33` | DNS-Server + Upstream zu unbound; kein Traefik fuer Admin-UI | Admin-Port bleibt bewusst ohne Traefik/2FA, aber nicht mehr auf allen LAN-Interfaces |
| `unbound` | ✅ | `dns_net` | intern | Upstream-Resolver für AdGuard, isoliert | — |
| `ddns-updater` | ✅ | `frontend_net` | intern | Cloudflare DNS API; bleibt in `frontend_net` | Dokumentierte Ausnahme |
| `tailscale` | ✅ | `host` | VPN-Zugang / Subnet-Router | **Natives Unraid-Plugin** (`tailscale.plg`, Interface `tailscale1`, State `/boot/config/plugins/tailscale/state`) — **nicht** repo-/Komodo-verwaltet | Subnet-Router fuer `192.168.178.0/24`; der redundante userspace-Docker-Stack `host-services/tailscale/` wurde am 2026-06-06 entfernt |
| `tailscale` | ✅ | `host` | VPN-Zugang | Git-Stack (`host-services/tailscale/`) | nutzt `NET_ADMIN`, `NET_RAW` und `/dev/net/tun` als dokumentierte VPN-Ausnahme |
### 7.2 Sicherheit / Identity
@@ -274,7 +273,7 @@ Legende Status:
| `immich_server` | ✅ | `immich_default`, `frontend_net` | Traefik | aktiv via `immich.kaleschke.info` | — |
| `immich_machine_learning` | ✅ | `immich_default` | intern | bleibt intern | — |
| `nextcloud` | ✅ | `frontend_net`, `nextcloud_internal` | Traefik | aktiv via `cloud.kaleschke.info`, nativer Nextcloud-Login, WebDAV/CardDAV faehig | CalDAV/CardDAV-Redirect via Traefik-Labels |
| `plex` | ✅ | `host` | Traefik via `plex.kaleschke.info` + Plex native Auth; LAN direkt `:32400` | Compose-Stack unter `host-services/plex/`; Host-Netz bleibt fuer Discovery / Plex GDM dokumentierte Ausnahme; Traefik routet per File-Provider-Ausnahme auf `http://192.168.178.58:32400`, weil Docker-Labels Host-Netz-Container aus Traefik heraus auf `127.0.0.1` routen wuerden; kein direkter WAN-Port 32400 und Plex Remote Access bleibt aus; Server geclaimt von `Xeridos`; Smart-TVs (Schlafzimmer, Wohnzimmer) ueber WLAN-LAN per mDNS | — |
| `plex` | ✅ | `host` | Plex native, **LAN/Tailscale-only** (Remote Access aus seit 2026-05-28) | Compose-Stack unter `host-services/plex/`; Host-Netz bleibt fuer Discovery / Plex GDM dokumentierte Ausnahme; Server geclaimt von `Xeridos`; Smart-TVs (Schlafzimmer, Wohnzimmer) ueber WLAN-LAN per mDNS | — |
| `super-productivity` | ✅ vorbereitet | `frontend_net` | Traefik + Middleware | Persoenliche Task-PWA des Operators; Issues kommen aus Gitea `Micha/mails` via n8n-Mail-Workflow | Deploy + Webhook + DNS-Eintrag offen |
| `n8n` | ✅ vorbereitet | `frontend_net` | Traefik, native Auth (keine pauschale Authelia) | Workflow-Automation; erster Workflow: GMX-Mail -> OpenAI-Extraktion -> Gitea-Issue in `Micha/mails`; `N8N_ENCRYPTION_KEY` ist Stack-ENV-Pflichtsecret | Deploy + Webhook + Owner-Setup offen |
@@ -309,7 +308,7 @@ Legende Status:
| Container | Status | Ziel |
|---|---|---|
| — | — | Plex ist nicht mehr direkt offen: der Dienst ist als Repo-Compose-Stack unter `host-services/plex/` dokumentiert; `host`-Netz bleibt als Discovery-Ausnahme. Externer Zugriff laeuft ausschliesslich ueber Traefik/443 auf `plex.kaleschke.info`; keine direkte 32400-WAN-Freigabe. Technisch nutzt Plex als einzige Host-Netz-Route `traefik/dynamic/plex.yml`, weil Docker-Labels fuer `network_mode: host` in Traefik auf `127.0.0.1:32400` zeigen. |
| — | — | Plex ist nicht mehr offen: der Dienst ist als Repo-Compose-Stack unter `host-services/plex/` dokumentiert; `host`-Netz bleibt als Discovery-Ausnahme. |
### 7.8 Entfernte Container
@@ -408,7 +407,6 @@ Für den laufenden Betrieb gilt stattdessen:
| `monitoring-influxdb3-core` | Host-Port 8181 auf LAN-IP; `user: "0"` | Home Assistant laeuft in einer VM ausserhalb des Compose-Netzes und muss Metriken schreiben koennen; keine Traefik-Route, kein `frontend_net`, Zugriff nur ueber Token und LAN-IP `INFLUXDB_BIND_IP`; InfluxDB 3 Core benoetigt im aktuellen Container-Setup Root-Rechte fuer den lokalen Object-Store-Pfad im named volume |
| `monitoring-promtail` | Docker-Socket read-only | Docker-Log-Discovery fuer Loki; keine Schreibrechte, keine Appdaten-Persistenz ueber den Socket |
| `n8n` | keine pauschale Authelia-Middleware | Webhook-Endpunkte (`/webhook/*`, `/webhook-test/*`) muessen ohne ForwardAuth erreichbar bleiben; n8n bringt eigene Owner-/Login-Auth mit (analog Komodo/Nextcloud) |
| `plex` | Traefik ohne Authelia, File-Provider-Ausnahme trotz Host-Netz | Plex bringt native Konto-/Client-Auth mit; vorgeschaltete ForwardAuth wuerde Plex Web, Apps und Client-Flows stoeren. Docker-Labels sind fuer diesen Host-Netz-Container ungeeignet, weil Traefik sonst `127.0.0.1:32400` nutzt; daher `traefik/dynamic/plex.yml` mit Ziel `192.168.178.58:32400`. Route nur ueber Traefik/443 (`plex.kaleschke.info`), direkter Plex-WAN-Port 32400 und Plex Remote Access bleiben deaktiviert. |
---
@@ -466,22 +464,6 @@ Damit ist sofort klar:
## 13. Betriebserfahrungen und Entscheidungs-Log
### Fix Common Problems Plugin entfernt (2026-06-03)
Befund: Drei `grep -R ... /usr/local/emhttp`-Prozesse liefen seit ~7 Tagen durchgehend mit je 100 % CPU (TIME+ 177-179 h). Status `R`, von PID 1 adoptierte Zombies einer laengst beendeten Fix-Common-Problems-(FCP)-Scan-Session. Folge: konstante Load 14.6 auf 12 Cores, IOWAIT-Peaks bis 55 %, USB-Flash unter Dauer-IO.
Ursache: Unraids `/usr/local/emhttp` enthaelt Symlinks `mnt -> /mnt` (mehrere TB Array) und `boot -> /boot` (USB-Flash). GNU `grep -R` dereferenziert Symlinks rekursiv. Ein FCP-Scan-Schritt (`/etc/cron.daily/fix.common.problems.sh -> scripts/scan.php`) hat dadurch effektiv die gesamte Array-Struktur gegrept und ist beim ersten Treffer-Loop haengen geblieben. Der Lock `/tmp/fix.common.problems/scanRunning` war vom 2026-06-03 04:40 - jeder weitere Daily-Cron-Run wuerde dasselbe Verhalten reproduzieren.
Massnahme: FCP-Plugin per `plugin remove fix.common.problems.plg` deinstalliert. Cron-Eintrag, Plugin-Verzeichnis und `/tmp`-Reste sauber. Load fiel innerhalb Minuten auf 1.08 (1-min).
Entscheidung: FCP wird bewusst **nicht** wieder installiert. Begruendung:
- Restliche Risiken werden bereits ueber andere Wege abgedeckt: Scrutiny (Laufwerks-SMART), Monitoring-Stack (Container-Health, Prometheus-Alerts, Blackbox), Posture-Check (Filesystem-/Drift-/Authelia-Audit), Critical-Events-Watcher (`services/posture-check/docker-critical-events.sh`).
- FCP ist ein externes Community-Plugin und nicht Teil der Repo-managed GitOps-Welt; Verhalten haengt von einer Online-Templates-Datei ab.
- Ein einmaliges Hang-up reicht, um die Flash-Drive 7 Tage lang zu thrashen - das Verhaeltnis Nutzen/Risiko ist negativ.
Folgen fuer Doku: Eintrag in `docs/AUDIT_2026-05-25_TODO.md` unter "Zuletzt geschlossen"; FCP taucht nicht mehr als Voraussetzung in DR/Monitoring-Pfaden auf, da es nie produktiv referenziert war.
### Plex Server Reclaim und LAN-only-Profil (2026-05-28)
Befund: Die `Preferences.xml` des Plex-Servers war seit dem 18.05.2026 13:18 jungfraeulich (391 Bytes, ohne `PlexOnlineMail`/`PlexOnlineUsername`/`PlexOnlineToken`). Der Server war damit nicht mit einem Plex.tv-Account geclaimt, obwohl die Smart-TVs ueber LAN-Discovery (mDNS/Plex-GDM) weiter funktionierten. Beim Login als `Xeridos` ueber `app.plex.tv` meldete der Server "Keine Berechtigung", weil kein Owner registriert war. Zusaetzlich war die `library_sections`-Konfiguration leer (Backups vom 19./22./28.05. ebenfalls ~370 KB statt MBs/GBs); die Bibliotheks-Konfiguration war seit dem 18.05. weg, die Filmdateien unter `/mnt/user/media/*` blieben aber intakt (~833 Verzeichnisse, davon `movies/` 1.4 TB und `Heimatfilme/` 300 GB).
@@ -497,8 +479,7 @@ Endstand:
- `PlexOnlineUsername="Xeridos"`, `PlexOnlineMail="michideheld@gmx.de"`, `PlexOnlineHome="1"`.
- Bibliotheken neu angelegt via Plex-Web → Verwalte Mediatheken → `/data/movies`, `/data/Heimatfilme` etc.
- `PublishServerOnPlexOnlineKey="0"` (Remote Access deaktiviert), Plex-Relay aus.
- 2026-06-06: Externer Komfortzugriff ueber `https://plex.kaleschke.info` via Traefik ergaenzt. Das ist **kein** Plex-Remote-Access und keine direkte FRITZ!Box-Freigabe auf `32400`; Plex bleibt hinter Traefik/443 und nutzt native Plex-Auth.
- `PublishServerOnPlexOnlineKey="0"` (Remote Access deaktiviert), Plex-Relay aus → Plex bleibt strikt LAN/Tailscale-only, konsistent zum Tailscale-First-Operator-Modell.
Konsequenzen fuer Doku/Betrieb:
apps/immich/docker-compose.yml
-11
View File
@@ -34,17 +34,6 @@ services:
container_name: immich_machine_learning
image: ghcr.io/immich-app/immich-machine-learning:release@sha256:a2501141440f10516d329fdfba2c68082e19eb9ba6016c061ac80d23beadf7f3
restart: unless-stopped
environment:
# Workaround fuer gunicorn-25.1.0-Control-Socket-Bug: der Worker haengt
# nach "Control socket listening at /usr/src/gunicorn.ctl" und erreicht
# nie "Application startup complete" -> Container bleibt dauerhaft
# unhealthy, ML (Gesichtserkennung/CLIP/Smart-Search) ist tot.
# --no-control-socket deaktiviert das fehlerhafte Feature. immich-ml
# startet gunicorn als Subprozess, der GUNICORN_CMD_ARGS aus der Env
# liest und anhaengt. Bestaetigte Upstream-Regression seit Immich 2.6
# (immich#27228, gunicorn#3510). Re-check: bei Immich-Update, das
# gunicorn auf >25.1.0/<25.1.0 mit Fix bringt, wieder entfernen.
GUNICORN_CMD_ARGS: "--no-control-socket"
volumes:
- model-cache:/cache
networks:
apps/mail-archiver/docker-compose.yml
+1 -1
View File
@@ -1,6 +1,6 @@
services:
mail-archiver:
image: s1t5/mailarchiver@sha256:4ea7ecc47ad1dd2c523b85c3967574b61e39def1b6fd26edf874e21733c4018c
image: s1t5/mailarchiver@sha256:ea7fd8c2e3e0ef0941e8dd9e726e35a8de33296f5c7b9ed811df5168ae6a9714
container_name: mail-archiver
restart: unless-stopped
environment:
apps/mealie/docker-compose.yml
-16
View File
@@ -4,12 +4,6 @@ services:
container_name: mealie
restart: unless-stopped
# OIDC: Authelia ueber Host-LAN-IP -> Traefik erreichbar (Container-DNS loest
# auth.kaleschke.info sonst nicht; gleiches Muster wie Komodo. SNI bleibt der
# Hostname, Let's-Encrypt-Cert validiert weiter.
extra_hosts:
- "auth.kaleschke.info:192.168.178.58"
environment:
TZ: Europe/Berlin
ALLOW_SIGNUP: "false"
@@ -24,16 +18,6 @@ services:
BASE_URL: https://mealie.kaleschke.info
# --- Authelia OIDC SSO (additiv, 2026-06-06; lokaler Login bleibt) ---
OIDC_AUTH_ENABLED: "true"
OIDC_PROVIDER_NAME: Authelia
OIDC_CONFIGURATION_URL: https://auth.kaleschke.info/.well-known/openid-configuration
OIDC_CLIENT_ID: mealie
OIDC_CLIENT_SECRET: ${MEALIE_OIDC_CLIENT_SECRET}
OIDC_SIGNUP_ENABLED: "true"
OIDC_AUTO_REDIRECT: "false"
OIDC_REMEMBER_ME: "true"
volumes:
- /mnt/user/appdata/mealie/data:/app/data
apps/n8n/docker-compose.yml
+1 -1
View File
@@ -1,6 +1,6 @@
services:
n8n:
image: docker.n8n.io/n8nio/n8n:2.26.2@sha256:61ba01bc5e39304bbc928c9dbecd938c3a5cc1331b68affba6a34d0f654c43d9
image: docker.n8n.io/n8nio/n8n:2.22.6@sha256:07138bb60aee990651e9c2090d7dde330cba3a5bd84fcc5cba63b2997243bc45
container_name: n8n
restart: unless-stopped
apps/nextcloud/docker-compose.yml
+1 -1
View File
@@ -1,6 +1,6 @@
services:
nextcloud:
image: nextcloud:33.0.5-apache@sha256:56bdc45109067500fd0832fa64832b7c77a167d9394cbf5f0f4b59740b94194d
image: nextcloud:33.0.4-apache@sha256:caa40b8beaf0057ac213d8dfc515c36ce64f7a8f0825b6a287e6f7cf2f4a095d
container_name: nextcloud
restart: unless-stopped
depends_on:
apps/ntfy/docker-compose.yml
+1 -1
View File
@@ -1,6 +1,6 @@
services:
ntfy:
image: binwiederhier/ntfy@sha256:f8a9b104313b87cc24ae4f775f39e6328205b57dff6ede3eaf098a91e5d79f59
image: binwiederhier/ntfy@sha256:b32b4221a64ec2e7c000f0782b2feef24022e1a09a24e531640f4cbba6cfa1e6
container_name: ntfy
restart: unless-stopped
dns:
apps/paperless/docker-compose.yml
-8
View File
@@ -3,9 +3,6 @@ services:
image: ghcr.io/paperless-ngx/paperless-ngx:2.20.15@sha256:6c86cad803970ea782683a8e80e7403444c5bf3cf70de63b4d3c8e87500db92f
container_name: paperless-ngx
restart: unless-stopped
# OIDC: Authelia ueber Host-LAN-IP -> Traefik erreichbar (Container-DNS sonst nicht)
extra_hosts:
- "auth.kaleschke.info:192.168.178.58"
security_opt:
- no-new-privileges:true
environment:
@@ -20,11 +17,6 @@ services:
- PAPERLESS_OCR_LANGUAGE=deu+eng
- PAPERLESS_URL=https://paperless.kaleschke.info
# --- Authelia OIDC SSO (additiv, 2026-06-06; lokaler Login bleibt) ---
- PAPERLESS_APPS=allauth.socialaccount.providers.openid_connect
- PAPERLESS_SOCIAL_AUTO_SIGNUP=true
- 'PAPERLESS_SOCIALACCOUNT_PROVIDERS={"openid_connect":{"OAUTH_PKCE_ENABLED":true,"APPS":[{"provider_id":"authelia","name":"Authelia","client_id":"paperless","secret":"${PAPERLESS_OIDC_SECRET}","settings":{"server_url":"https://auth.kaleschke.info"}}]}}'
# Barcode / ASN
- PAPERLESS_CONSUMER_ENABLE_BARCODES=1
- PAPERLESS_CONSUMER_ENABLE_ASN_BARCODE=1
apps/super-productivity/docker-compose.yml
+1 -1
View File
@@ -1,6 +1,6 @@
services:
super-productivity:
image: johannesjo/super-productivity:v18.9.1@sha256:773760107344e739f4c29409f7842db66a1b167d50eb2c40248cb5b5b328652e
image: johannesjo/super-productivity:v18.8.0@sha256:c739caca8e0c5e83ea4a6289884079ac49e0c3c87c7f95598b5a9fb10cc2d9c4
container_name: super-productivity
restart: unless-stopped
apps/unbound/docker-compose.yml
+1 -1
View File
@@ -1,6 +1,6 @@
services:
unbound:
image: shaanmajid/unbound:1.25.1@sha256:f140db02a005904802bf5840093e95e675321aa060a00426fdffc2a3ac2eeb6b
image: shaanmajid/unbound:1.25.1@sha256:96809ff052e8bd79bba30e067d8b27ed9a2f069b6b2a3484fe1d0eb45aba07c5
container_name: unbound
restart: unless-stopped
volumes:
audit/raw/01_volumes_partitions.txt
-22
View File
@@ -1,22 +0,0 @@
### VOLUMES ###
DriveLetter Label FS Size_GB Free_GB Health
C (kein Label) NTFS 166.9 59.5 Healthy
D Daten-Projekte NTFS 167.7 148.6 Healthy
E Games NTFS 930.6 714.9 Healthy
G M2 SSD NTFS 930.9 877.5 Healthy
H Externe HDD NTFS 7452.0 3801.3 Healthy
(kein BW) Recovery x5 NTFS diverse diverse Healthy
### DISKS ###
Disk 0 INTEL SSDSC2BW180A3L SATA 167.68 GB GPT Healthy Serial: CVCV3105053K180EGN
Disk 1 INTEL SSDSC2BW180A3L SATA 167.68 GB GPT Healthy Serial: CVCV311302TH180EGN
Disk 2 Samsung SSD 980 PRO 1TB NVMe 931.51 GB GPT Healthy
Disk 3 WDC WDS100T2B0C NVMe 931.51 GB GPT Healthy
Disk 4 asmedia ASM235 USB 7.28 TB GPT Healthy
### PARTITIONS ###
Disk 0: [Reserved 16MB] [C: 166.87 GB Basic] [Recovery 809 MB]
Disk 1: [Reserved 15.98 MB] [D: 167.66 GB Basic]
Disk 2: [Reserved 15.98 MB] [E: 930.63 GB Basic] [Recovery 885 MB] <- F: ist weg
Disk 3: [System 100 MB] [Reserved 16 MB] [G: 930.89 GB Basic] [Recovery 524 MB]
Disk 4: [Reserved 15.98 MB] [H: 7.28 TB Basic]
audit/raw/02_folder_structure.txt
-52
View File
@@ -1,52 +0,0 @@
### D:\ TOP-LEVEL ###
00_Inbox Directory 2026-06-04
10_Dokumente Directory 2026-06-04
11_Bilder Directory 2026-06-04 [ReadOnly-Attribut gesetzt]
12_Videos Directory 2026-06-04
13_Musik Directory 2026-06-04
14_Downloads Directory 2026-06-04
20_Projekte Directory 2026-06-04
30_Finanzen Directory 2026-06-04
90_Archiv Directory 2026-06-04
Micha Directory 2026-06-05 [Altquelle, noch vorhanden]
WSL Directory 2026-06-04 [nicht in Soll-Doku]
DumpStack.log File
### D:\Micha INHALT ###
Videos Directory 2026-06-05 [1 Datei, 0 MB - fast leer]
(alle anderen Unterordner weg)
### D:\00_Inbox INHALT ###
Desktop Directory 2026-06-05 [ReadOnly - das ist das Known-Folder-Ziel!]
### E:\ TOP-LEVEL ###
BattleNet Directory 2026-06-04 [SOLL]
EA Directory 2026-06-04 [SOLL]
EpicGames Directory 2026-06-04 [SOLL]
Riot Directory 2026-06-04 [SOLL]
Steam Directory 2026-06-05 [SOLL]
Ubisoft Directory 2026-06-04 [SOLL]
_Standalone FEHLT! [SOLL laut Doku]
### G:\ TOP-LEVEL ###
Apps Directory 2026-06-04 [nicht in Soll-Doku]
Gitea_Clone Directory 2026-04-15 [nicht in Soll-Doku - bewusst, homelab-infra]
repos Directory 2026-06-05 [SOLL]
Tools Directory 2026-06-05 [SOLL - Doku schreibt 'tools' lowercase, NTFS case-insensitive]
Workspace Directory 2026-06-04 [nicht in Soll-Doku]
### KNOWN FOLDER REDIRECTS (Ist) ###
Desktop -> D:\00_Inbox\Desktop [ABWEICHUNG! Soll: D:\Micha\Desktop]
Documents -> D:\10_Dokumente [OK]
Downloads -> D:\14_Downloads [OK]
Pictures -> D:\11_Bilder [OK]
Music -> D:\13_Musik [OK]
Videos -> D:\12_Videos [OK]
### DOPPELBESTAND D:\Micha\* vs D:\NN_* ###
D:\Micha\Dokumente : NICHT VORHANDEN | D:\10_Dokumente : 4011 Dateien, 595 MB
D:\Micha\Bilder : NICHT VORHANDEN | D:\11_Bilder : 7789 Dateien, 12367 MB
D:\Micha\Videos : 1 Datei, 0 MB | D:\12_Videos : 1 Datei, 0 MB
D:\Micha\Musik : NICHT VORHANDEN | D:\13_Musik : 0 Dateien
D:\Micha\Downloads : NICHT VORHANDEN | D:\14_Downloads : 2186 Dateien, 2211 MB
D:\Micha\Finanzen : NICHT VORHANDEN | D:\30_Finanzen : 126 Dateien, 123 MB
audit/raw/03_os_security.txt
-63
View File
@@ -1,63 +0,0 @@
### OS BASELINE ###
Caption: Microsoft Windows 11 Pro
Build: 26200
Version: 10.0.26200
Architecture: 64-Bit
InstallDate: 2026-05-10 13:11:27
LastBoot: 2026-06-05 07:57:08
Uptime: 0.04 Tage (~1 Stunde zum Audit-Zeitpunkt)
Manufacturer: Micro-Star International Co., Ltd.
Model: MS-7D32
RAM: 31.79 GB
CPU: Intel Core i5-14600KF, 14 Cores, 20 Threads, 3500 MHz
### AKTIVIERUNG ###
Name: Windows(R), Professional edition
LicenseStatus: 1 (Aktiv)
Channel: OEM_DM
### AUSSTEHENDE UPDATES ###
Windows Update pending: 0
Reboot pending: Nein
### DEFENDER ###
AMProductVersion: 4.18.26040.7
AMServiceEnabled: True
AntivirusEnabled: True
AntispywareEnabled: True
RealTimeProtection: True
TamperProtection: True
SignatureAge: 0 Tage (aktuell)
Exclusions: KEIN ADMIN -> nicht lesbar
ASR Rules: KEIN ADMIN -> nicht lesbar (Get-MpPreference liefert leer)
### FIREWALL ###
Domain: Enabled, DefaultInboundAction: NotConfigured, DefaultOutboundAction: NotConfigured
Private: Enabled, DefaultInboundAction: NotConfigured, DefaultOutboundAction: NotConfigured
Public: Enabled, DefaultInboundAction: NotConfigured, DefaultOutboundAction: NotConfigured
HINWEIS: NotConfigured = Windows-Default (eingehend blockieren, ausgehend erlauben)
### BITLOCKER ###
KEIN ADMIN -> Get-BitLockerVolume verweigert (Access Denied). Status unbekannt.
### SECURE BOOT ###
KEIN ADMIN -> Confirm-SecureBootUEFI verweigert. Status unbekannt.
### TPM ###
KEIN ADMIN -> Get-Tpm liefert alle Felder leer. Status unbekannt.
### UAC ###
EnableLUA: 1 (aktiv)
ConsentPromptBehaviorAdmin: 5 (Nachfrage mit UI, ohne Secure Desktop laut Wert, aber...)
PromptOnSecureDesktop: 1 (Secure Desktop ist AN - Standard-Konfiguration korrekt)
### LOKALE ADMINS ###
Gruppe Administratoren: Administrator, michi
### BCD ###
KEIN ADMIN -> bcdedit /enum verweigert.
Letzte bekannte Aussage (Doku boot-cleanup-plan): Keine partition=F: Referenz nach Cleanup + Neustarttest.
### WinRE ###
KEIN ADMIN -> reagentc /info verweigert.
Letzte bekannte Aussage (Doku): WinRE Disabled.
audit/raw/04_network_ssh.txt
-58
View File
@@ -1,58 +0,0 @@
### NETZWERK-ADAPTER (UP) ###
Ethernet Intel I225-V MAC: 04-7C-16-53-04-E4 1 Gbps
Tailscale Tunnel 100 Gbps (virtuell)
vEthernet WSL (Hyper-V) MAC: 00-15-5D-F3-5F-C9 10 Gbps (virtuell)
### IP-ADRESSEN ###
Ethernet: 192.168.178.103/24
Tailscale: 100.78.133.37/32
WSL bridge: 172.26.80.1/20
(WLAN, Bluetooth etc.: APIPA 169.254.x.x - nicht konfiguriert/inaktiv)
### DNS ###
Ethernet DNS: 192.168.178.58 (= Kallilabcore AdGuard Home)
WLAN DNS: 192.168.178.58
### TAILSCALE STATUS ###
100.78.133.37 baerchen-1 (dieser Rechner) online
100.105.203.21 baerchen (alter Rechner) offline, last seen 20h ago
100.73.83.55 iphone-14 iOS online
100.112.0.90 kallilab-core linux online
100.80.98.33 kallilabcore linux active; direct 192.168.178.58:49917
### LAUSCHENDE TCP-PORTS ###
Port Adresse Prozess Bemerkung
135 0.0.0.0/:: svchost RPC Endpoint Mapper
139 192.168.178.103 System NetBIOS
445 :: System SMB
3000 ::1/:: wslrelay / docker Docker / WSL lokal
5040 0.0.0.0 svchost WS-Discovery (WDAS)
5357 :: System WSD HTTP
7680 :: svchost WUDO (Delivery Optimization)
11434 127.0.0.1 ollama Ollama API (lokal)
22885 127.0.0.1 Battle.net lokal
26822 127.0.0.1 MSI.TerminalServer MSI Center
27036 0.0.0.0 steam Steam Remote Play (0.0.0.0 - offen!)
27060 127.0.0.1 steam Steam lokal
32683 127.0.0.1 MSI.CentralServer MSI Center
33683 127.0.0.1 MSI.CentralServer MSI Center
38810 fd7a:... tailscaled
49553 100.78.133.37 tailscaled
50123 127.0.0.1 iCUE Corsair lokal
51037 127.0.0.1 RazerAppEngine
55316 127.0.0.1 RazerAppEngine
59686 127.0.0.1 steam
60999 127.0.0.1 Agent Claude Code
### SSH ###
~\.ssh\config: LEER (keine Host-Eintraege)
~\.ssh\id_ed25519: vorhanden (411 Bytes, erstellt 2026-04-04)
~\.ssh\id_ed25519.pub: vorhanden (97 Bytes)
~\.ssh\known_hosts: vorhanden (4719 Bytes, zuletzt 2026-06-04)
~\.ssh\known_hosts.old + .pre-port222-Backup: vorhanden
KEY PERMISSIONS id_ed25519:
NT-AUTORITAET\SYSTEM FullControl Allow
VORDEFINIERT\Administratoren FullControl Allow
baerchen\michi FullControl Allow
BEFUND: Zu viele Berechtigungen - Admins-Gruppe hat FullControl auf Private Key.
audit/raw/05_dev_tools.txt
-66
View File
@@ -1,66 +0,0 @@
### DEV TOOLCHAIN ###
git: 2.54.0.windows.1
python: 3.13.13
node: 24.16.0 (LTS)
go: 1.26.4 windows/amd64
### GIT CONFIG ###
user.name: michaelkaleschke-spec
user.email: michaelkaleschke@googlemail.com
commit.gpgsign: nicht gesetzt (Commits nicht signiert)
### WSL ###
Ubuntu Stopped Version 2
docker-desktop Running Version 2
### DOCKER CONTEXTS ###
default npipe:////./pipe/docker_engine (nicht aktiv)
desktop-linux* npipe:////./pipe/dockerDesktopLinuxEngine (aktiv)
### KUBECTL ###
Keine Contexts konfiguriert.
### WINGET INVENTAR (158 Pakete, Auswahl) ###
CPUID CPU-Z MSI 2.20.1
CPUID HWMonitor 1.63
CrystalDiskInfo 9.9.1
Docker Desktop 4.76.0
Git 2.54.0
AusweisApp 2.5.1
Node.js LTS 24.16.0
Corsair iCUE5 5.46.67
NVIDIA App 11.0.7.247 / Treiber 610.47
WISO Steuer 2026 33.07.3410
Go 1.26.4
Microsoft Edge 148.0.3967.96
Microsoft OneDrive 23.038 (Update verfuegbar: 26.078)
RivaTuner Statistics Server 7.3.7
Razer Synapse 4.0.683
Steam 2.10.91.91
Banking4 Home
Battle.net / Hearthstone / Overwatch / World of Warcraft
Microsoft 365 16.0.20026.20140
### AUTOSTART ###
HKCU\Run:
BraveSoftware Update -> BraveUpdateCore.exe
Steam -> E:\Steam\steam.exe -silent
RazerAppEngine -> Synapse autoStart
Docker Desktop -> Docker Desktop.exe
HKLM\Run:
SecurityHealth -> SecurityHealthSystray.exe
Corsair iCUE5 -> iCUE Launcher.exe --autorun
RtkAudUService -> Realtek Audio Service
Startup-Ordner (User): Ollama.lnk
Startup-Ordner (Alle): Tailscale.lnk
### GEPLANTE TASKS (nicht-Microsoft, aktiv) ###
OneDrive Reporting Task
OneDrive Startup Task
OneDrive Per-Machine Standalone Update Task
PostponeDeviceSetupToast
BraveSoftwareUpdateTask (2x User-Varianten)
NVIDIA App SelfUpdate
SoftLanding\CreativeManagementTask [UNBEKANNT - pruefen]
audit/raw/06_events_hardware.txt
-45
View File
@@ -1,45 +0,0 @@
### HARDWARE ###
CPU: Intel Core i5-14600KF, 14 Cores / 20 Threads, 3500 MHz Base
RAM: 31.79 GB
MB: MSI MS-7D32
Energieplan: Ausbalanciert (381b4222) - aktiv
Verfuegbare Plaene: Ausbalanciert, Ultimative Leistung, Hoechstleistung, Energiesparmodus
### PHYSICAL DISKS (SMART) ###
INTEL SSDSC2BW180A3L SSD Healthy OK (Disk 0, C:)
INTEL SSDSC2BW180A3L SSD Healthy OK (Disk 1, D:)
Samsung SSD 980 PRO 1TB SSD Healthy OK (Disk 2, E:)
WDC WDS100T2B0C SSD Healthy OK (Disk 3, G:)
asmedia ASM235 Unspecified Healthy OK (Disk 4, H:)
Get-StorageReliabilityCounter: keine Ausgabe (Wear-Daten nicht via WMI verfuegbar - typisch fuer SATA SSDs und USB)
### GERAETE MIT STATUS "Unknown" (PnP) ###
MyBookLiveDuo (SoftwareDevice) - Netzwerkgeraet, nicht angebunden - erwartet
HID-Tastatur (Keyboard) - ghosted device - harmlos
Dell S2722DGM (DP) (Monitor) - Display-Enumeration Artefakt
Generic Monitor x2 - Display-Enumeration Artefakt
[LG] webOS TV OLED65G48LW x2 - Netzwerkgeraet, nicht lokal - erwartet
Standard-Volumeschattenkopie x3 - VSS Snapshots - erwartet
KEINE echten Fehlercodes (kein gelbes Ausrufezeichen).
### EVENT LOG FEHLER seit Installation (2026-05-10) ###
ID 20 (70x): Defender KB4052623 Installation fehlgeschlagen (0x80240016)
-> Timing-Problem bei Update-Kaskade, harmlos wenn aktuell
ID 10010 (15x): DCOM Server-Timeout {3E11DF0F-...}
-> bekanntes Windows-Hintergrundrauschen, harmlos
ID 7000 (3x): Steam Client Service Start fehlgeschlagen
-> Steam war beim Boot noch nicht bereit, harmlos
ID 7023 (3x): Windows Modules Installer beendet mit Fehler
-> Update-Installationsabbrueche, pruefbar nach Analyse der Zeitstempel
ID 6008 (2x): Unerwartetes Herunterfahren am 2026-05-19 13:56:56
-> Einmaliger Vorfall (BSOD oder Stromausfall) kurz nach Installation
ID 7034 (2x): MSI Center Service unerwartet beendet
-> bekannte Instabilitaet MSI Center, harmlos wenn kein Datenverlust
ID 7043 (1x): Dienst konnte nicht gestoppt werden
ID 1012 (3x): unbekannte ID - weitere Analyse noetig
ID 36 (2x): unbekannte ID - weitere Analyse noetig
### CRASH DUMPS ###
C:\Windows\Minidump: nicht vorhanden
C:\Windows\MEMORY.DMP: nicht vorhanden
Bewertung: kein BSOD-Dump vorhanden (ggf. Dump-Einstellung "automatisch neu starten" ohne Dump-Schreiben)
docs/AI_CONTEXT.md
+4 -21
View File
@@ -1,6 +1,6 @@
# AI Context
Stand: 2026-06-05
Stand: 2026-06-01
Kurzer Kontext fuer KI-Agenten. Nicht als Ersatz fuer die echten Runbooks lesen.
@@ -43,36 +43,19 @@ Kurzer Kontext fuer KI-Agenten. Nicht als Ersatz fuer die echten Runbooks lesen.
## Aktuelle Restpunkte
Authoritativ: `docs/MASTER_TODO.md`.
Authoritativ: `docs/AUDIT_2026-05-25_TODO.md`.
Kurzfassung:
- Alt-Volumes fruehestens ab 2026-06-02 freigeben
- Auth-/OIDC-/CrowdSec-/Hermes-Themen bewusst geparkt
- Wochenend-Sprint 2026-06-05: `docs/WEEKEND_EXECUTION_PLAN_2026-06-05.md`
und `docs/WEEKEND_STATUS_2026-06-05.md`
Letzte Bestaetigung:
- Windows-Image `baerchen`: Veeam Agent Free Job `baerchen-c-image` auf
`\\kallilabcore\backups\windows-images\baerchen`, erster Full-Backup-Lauf
2026-06-05 erfolgreich, GUI-Wert 53,8 GB, Dauer 0:11:31. Recovery-USB ist
erstellt; Boot-/SMB-/Restore-Point-Test ohne Restore ist noch offen.
- Veeam Storage Encryption ist beim ersten Full-Lauf nicht aktiv
(`StorageEncryptionEnabled=False`); nachtraegliche Aktivierung ist eine
Operator-Entscheidung, weil sie Passwort- und Restore-Prozess aendert.
- BitLocker fuer `baerchen` ist bewusst nicht aktiviert und bleibt
Operator-Entscheidung.
- Tailscale-Inventar 2026-06-05 real gemessen: `Kallilabcore`
`100.80.98.33`, IPv6 `fd7a:115c:a1e0::2c01:62b2`, kein Exit Node, aber
aktiver Subnet Router fuer `192.168.178.0/24`. Dadurch ist die Tailnet-ACL
sicherheitsrelevant; Entscheidung Default-Allow vs tag-basierte ACL offen.
- Unraid-Flash-Backup-Artefaktpruefung: `ops/maintenance/check-unraid-flash-backup.sh`
prueft Artefakt, SHA256, Alter und Kern-Configs. Test 2026-06-05 gegen Host
erfolgreich laut `docs/MASTER_TODO.md`.
- Borg-Nachlauf 2026-06-01 erfolgreich: Archiv `Taegliche-Sicherung-2026-06-01T04:30:26.913`, Freshness Critical 0 / Warnings 0.
- H:/ Nearline-Pull 2026-06-01 repariert: Borg-Dumps werden kuratiert kopiert, Gitea-Bundles aktuell.
- Family-Status-Dashboard liegt als `monitoring/grafana/dashboards/family-status.json` im Repo.
- Alt-Volumes nach PG18/VectorChord-Burn-in sind seit 2026-06-02 reversibel archiviert unter `/mnt/user/appdata/_archive/pg18-immich-rollback-volumes-20260602`; die alten Originalpfade sind nicht mehr aktiv gemountet.
- Alt-Volume-Freigabe ist per `ops/maintenance/release-alt-volumes.sh` vorbereitet; `--execute` nicht vor 2026-06-02.
- Family-Onboarding ist auf drei Nutzungsziele fokussiert: Vaultwarden, Immich und Mealie; praktischer Ablauf in `docs/FAMILY_ONBOARDING.md`.
- Externer Betreibercheck: `ops/maintenance/check-external-operator.sh`; FRITZ!Box 7590 meldet FRITZ!OS `154.08.25`, DNS fuer Public Apps hat keine AAAA-Records, Host hat keine globale Provider-IPv6.
- FRITZ!Box-UI 2026-06-01: Remote-HTTPS auf FRITZ!Box-UI aus, FTP/FTPS auf Speichermedien aus, WAN-Freigabe nur `443/tcp`, keine aktive IPv6-Freigabe sichtbar, UPnP-Selbstfreigaben aus.
docs/ALERT_RULES.md
+2 -4
View File
@@ -1,6 +1,6 @@
# Alert Rules
Stand: 2026-06-05
Stand: 2026-05-31
Diese Datei beschreibt die produktiven Alarmwege und wichtigsten Regeln. Die
Konfiguration selbst liegt in `monitoring/prometheus/alerts.yml` und in den
@@ -49,6 +49,4 @@ Die Liste der ueberwachten Critical-Container steht in
- Kein Inode-Alarm. Bei Paperless/Immich spaeter sinnvoll, aber aktuell kein
dokumentierter Vorfall.
- Container-Memory-Limits werden erst nach realen Peak-Daten gesetzt; OOM/kill
wird ueber `docker-critical-events.sh` gemeldet, sobald der Host-Watcher per
Unraid User Script aktiviert ist. Start/Stop/Status/Smoke laufen ueber
`services/posture-check/docker-critical-events-supervisor.sh`.
wird bereits ueber `docker-critical-events.sh` gemeldet.
docs/AUDIT_2026-05-25_TODO.md
+5 -31
View File
@@ -3,39 +3,21 @@
Status: **kompakte Restliste**. Die erledigten Sprint-Tabellen und langen
Audit-Snapshots wurden aus der Arbeitskopie entfernt; Detailhistorie liegt in Git.
Letzter Sync mit `docs/MASTER_TODO.md`: 2026-06-05. Offene Punkte sind deckungsgleich;
neue Restore-Runbook-Stubs (Unraid Flash / AdGuard / Tailscale / Redis 8) wurden
in `docs/RESTORE_MATRIX.md` ergaenzt.
## Aktuell offene Punkte
| Prioritaet | Punkt | Naechster Schritt |
|---|---|---|
| P0 | Alt-Volumes nach Burn-in freigeben | Ab 2026-06-02 `ops/maintenance/release-alt-volumes.sh --dry-run` pruefen, danach nur bei sauberem Ergebnis mit `--execute` freigeben |
| P2 | Family-Onboarding praktisch starten | Fokus: Vaultwarden als Passwortbasis, Immich-Mobile-Backup auf jedem Handy, Mealie mit erstem Rezept/Einkaufsliste; Ablauf steht in `docs/FAMILY_ONBOARDING.md` |
## Restore-Audit Backlog (Stand 2026-06-03)
Ergebnis des Restore-Skills-Audits (Session 2026-06-02/03). Die kritischen Bugfixes (Cron-OR-Semantik, ntfy-Race, Cleanup-Trap, Pfad-Inkonsistenz, Vaultwarden-Token, Paperless-Retry, Header-Validierung, Authelia-Test) sind erledigt und committed. Die folgenden Punkte sind bewusst offener Backlog:
| Prioritaet | Punkt | Status | Naechster Schritt |
|---|---|---|---|
| P1 | Nextcloud-Restore-Test | **erledigt 2026-06-03** | Borg-Extract + pg_restore (126 Tabellen) + HTTP 200 + `occ status maintenance:false`. Quelle: `hetzner_borg_appdata_critical`, Archiv `Taegliche-Sicherung-2026-06-03T04:30:41.432`. Zwei Skript-Bugs im Zuge des Laufs gefixt (`check_data_directory_permissions: false` patchen, `.ncdata`-Marker anlegen). Report `/mnt/user/backups/restore-reports/nextcloud-2026-06-03.md`. |
| P1 | Shared PostgreSQL 18 Cluster Restore Drill | **erledigt 2026-06-03** | Globals + 5 DBs (paperless 72t, mailarchiver 1t, authelia 25t, nextcloud 126t, mealie 66t), `data_checksums=on`, Report `/mnt/user/backups/restore-reports/shared-pg-cluster-2026-06-03.md` |
| P1 | Komodo-Mongo-Daten-Restore | **erledigt 2026-06-03** | 86904 Dokumente erfolgreich restored, Report `/mnt/user/backups/restore-reports/komodo-mongo-restore-2026-06-03.md`. Nebenbefund: Dump von Mongo 8.0.23, Test auf 7.0.32 — Cross-Version-Warning, fuer Lesetest harmlos |
| P2 | Mailarchiver-Restore-Test | **erledigt 2026-06-03** | Data-Protection-Keys + 645M pg_restore + HTTP 200. Report `/mnt/user/backups/restore-reports/mailarchiver-2026-06-03.md` |
| P2 | Mealie-Restore-Test | **erledigt 2026-06-03** | Borg-Data + pg_restore + HTTP 200, 3 Rezepte. Report `/mnt/user/backups/restore-reports/mealie-2026-06-03.md` |
| P2 | Traefik-Restore-Test | **erledigt 2026-06-03** | dynamic/ + letsencrypt/ aus Borg, File-Provider + Ping 200. CF-Token bewusst nicht im Smoke. Report `/mnt/user/backups/restore-reports/traefik-2026-06-03.md` |
| P3 | Negativ-Test fuer Frische-Check | offen | Einmal pro Quartal bewusst kaputten Dump einfuettern und pruefen ob `homelab-alerts` feuert |
| P3 | End-to-end-DR-Drill | offen | Komplett-Bootstrap Phase 1-5 auf einem Wegwerf-Host; realistisch nur mit zweiter Hardware |
## Bewusst geparkt
| Punkt | Entscheidung |
|---|---|
| Authelia 2FA fuer Operator-UIs (Rest) | Tier-1-Operator-UIs sind 2026-06-03 auf `two_factor` gehoben (`files`, `scrutiny`, `borg`, `code`). Restliche Admin-UIs (`monitoring`, `glances`, `glance`, `speedtest`, `paperless-gpt`, `pdf`, `mail`, `hermes`, `sp`) bleiben bewusst auf `one_factor`, bis die finale Auth-Policy steht. |
| Authelia 2FA fuer Operator-UIs | In diesem Zyklus nicht umgesetzt; erst mit finaler Auth-Policy |
| Authelia OIDC fuer Apps | Geparkt bis klare Familien-/SSO-Entscheidung |
| CrowdSec vor Traefik | Bewusst nicht umgesetzt: einzige WAN-Tuer ist `443/tcp`, Operator-Pfad ist Tailscale, Authelia-`regulation:` deckt Auth-Brute-Force ab. Neu bewerten bei breiterer Attack Surface. |
| Nextcloud 2FA/Brute-Force-Haertung | UI-Schritt fuer Operator-Account (`twofactor_totp` aktivieren) bleibt offen. App-weite Familien-Policy gemeinsam mit OIDC entscheiden. |
| CrowdSec vor Traefik | Erst nach Auth-Policy neu bewerten |
| Nextcloud 2FA/Brute-Force-Haertung | Gemeinsam mit OIDC/Familienkonten entscheiden |
| Hermes-Agent | NAS-Stack bleibt deaktiviert; Review-Deadline 2026-07-25 |
| USV | Anschaffung verschoben; Power-Loss-Risiko bewusst akzeptiert |
| Zweites Off-site-Ziel | Bewusst nicht umgesetzt; neu bewerten bei Hetzner-Problemen, stark wachsendem Datenwert oder geaenderter Betreiber-Praeferenz |
@@ -43,21 +25,13 @@ Ergebnis des Restore-Skills-Audits (Session 2026-06-02/03). Die kritischen Bugfi
## Zuletzt geschlossen
- DR-Workstation Bare-Metal-Kit abgeschlossen (2026-06-06): WSL2 Ubuntu 24.04, SSH/Git, Borg 1.2.8, DR-Key-Arbeitskopien `~/.ssh/dr-readonly` und `~/.ssh/dr-hetzner`, `~/dr-smoke.sh`. Finaler Operator-Smoke erfolgreich: GitHub HEAD `3a263a4...`, Hetzner Storage Box Repos sichtbar (`backup`, `backup2`, `hetzner_borg_appdata`, `hetzner_borg_appdata_critical`), Borg-Repo `hetzner_borg_appdata_critical` gelesen, Repository ID `5dd9b949...`, encrypted `Yes (repokey)`, `DR-Smoke OK (2026-06-06 10:05:30)`. Borg-Passphrase wurde nur interaktiv eingegeben und nicht gespeichert.
- Nextcloud-Restore-Test 2026-06-03 erfolgreich (Tier-2 damit komplett belegt). Drei Laeufe noetig: Lauf 1 schlug an `chmod()` der data-Dir auf shfs fehl (`OC_Util.php:486`), Lauf 2 an fehlender `.ncdata`-Marker-Datei, Lauf 3 sauber durch. Beide Bug-Fixes ins Skript `ops/restore-tests/nextcloud-restore-test.sh` integriert. Endresultat: HTTP 200 auf `/status.php`, `occ status` ok, 126 Tabellen in der DB. Source: `hetzner_borg_appdata_critical`, Archiv `Taegliche-Sicherung-2026-06-03T04:30:41.432`. Report unter `/mnt/user/backups/restore-reports/nextcloud-2026-06-03.md`.
- Hetzner Storage Box DR-SSH-Key `dr-hetzner-2026-06-03` (ed25519, Passphrase-frei) angelegt: Pubkey via `install-ssh-key` auf der Storage Box autorisiert, passwortloser Login erfolgreich (Borg-Repos `backup`, `backup2`, `hetzner_borg_appdata`, `hetzner_borg_appdata_critical` sichtbar), Private-Key offline neben KOMODO_*-Notiz und GitHub-Deploy-Key abgelegt, Arbeitsplatz-Kopie geloescht. Damit ist Bare-Metal-Borg-Zugang von der DR-Workstation moeglich, sobald WSL2+Borg installiert sind.
- Fix Common Problems Plugin (FCP) 2026-06-03 deinstalliert. Befund: drei `grep -R ... /usr/local/emhttp`-Prozesse aus einem FCP-Daily-Scan hingen seit ~7 Tagen in einem Symlink-Loop (`/usr/local/emhttp/mnt -> /mnt`, gesamte Array). 3 Cores dauerhaft 100 %, IOWAIT bis 55 %, USB-Flash unter Dauer-IO. Plugin via `plugin remove` entfernt, Cron + /tmp-Reste sauber, Load von 14.6 auf 1.08 gefallen. FCP wird bewusst nicht wieder installiert (Begruendung siehe `HOMELAB_ARCHITECTURE_MASTER_V2.md` Sektion 13). Bekannte Risiken decken Scrutiny, Monitoring, Posture-Check und Critical-Events-Watcher bereits ab.
- GitHub-Mirror Read-Only Deploy-Key `DR Read-Only 2026-06-03` (ed25519, Passphrase-frei) angelegt: GitHub Repo Settings -> Deploy Keys ohne Write-Access, Smoke `git ls-remote` erfolgreich (HEAD `d947c7f` = master), Private-Key offline neben der KOMODO_*-Notiz abgelegt, Arbeitsplatz-Kopie nach USB-Transfer geloescht. Damit ist der DR-Read-Pfad zum privaten Mirror ohne Operator-Browser-Login moeglich.
- KOMODO_*-Notiz offline gesichert (Operator-Bestaetigung 2026-06-03). Quelle bleibt host-seitige `.env` unter `/mnt/user/services/stacks/komodo/.env` bzw. die Drift-Recovery-Kopie unter `/mnt/user/appdata/secrets/_komodo_stack_env_recovery_2026-05-04.env`. Damit ist der Bare-Metal-Komodo-Bootstrap ohne Vaultwarden moeglich. Eintrag in `docs/EXTERNAL_DEPENDENCIES.md` Reviews und Pflichtbestandteil im DR-Workstation-Kit nachgezogen.
- DR-Tabletop 2026-06-03 durchgelaufen, Findings in `docs/DR_DRILL_2026-06-03.md` (23 Befunde: 1 CRITICAL, 11 HIGH, 8 MED, 3 LOW). Reine Doku-Fixes in DR.md (Phase 0 Mirror-Klarstellung, neue Phase 4 Stufe 0 Docker-Netze, LE-Staging-Hinweis, Komodo-Stolperfallen, App-DB-Verify in Phase 5) und in `EXTERNAL_DEPENDENCIES.md` (DR-Workstation-Kit, KOMODO_*-Notiz und GitHub-Read-PAT als offene Bootstrap-Bloecke) sind im selben Aenderungsblock erledigt. Operator-Aufgaben (Notiz/PAT/WSL-Setup) wandern als P1 in die offenen Punkte.
- Authelia ACL: `borg.kaleschke.info` und `code.kaleschke.info` 2026-06-03 in den `two_factor`-Block der Repo-Baseline aufgenommen. Beide UIs haben effektiv Host-/Backup-Zugriff (Borg-Restore-Scope inkl. `/local/secrets`, code-server mit Workspaces). Wirkung erst nach manuellem Merge in `/mnt/user/appdata/authelia/config/configuration.yml`, `docker restart authelia` und Smoke-Test auf einer der vier 2FA-Domains; `services/authelia-diff.sh` muss `exit 0` liefern. TOTP-Enrollment des Operator-Accounts ist Voraussetzung, sonst Login-Sperre.
- Alt-Volumes nach Burn-in freigegeben und reversibel archiviert: Shared PG17, Mealie PG17, Nextcloud PG17 und Immich pgvecto.rs liegen seit 2026-06-02 unter `/mnt/user/appdata/_archive/pg18-immich-rollback-volumes-20260602`; Manifest auf dem Host: `/mnt/user/appdata/_archive/pg18-immich-rollback-volumes-20260602/MANIFEST.txt`. Keine harte Loeschung, keine aktiven Container-Mounts auf die alten Pfade.
- Externer Betreibercheck vorbereitet: `docs/EXTERNAL_OPERATOR_RUNBOOK.md` und `ops/maintenance/check-external-operator.sh`; Live-Baseline am 2026-06-01: FRITZ!OS `154.08.25`, keine Public-AAAA-Records fuer `*.kaleschke.info`, Host ohne globale Provider-IPv6, WAN `443/tcp` offen und `80/tcp`/`222/tcp` geschlossen.
- FRITZ!Box-Servicefenster UI-seitig abgeschlossen: FRITZ!Box-Dienste aus dem Internet sind aus (HTTPS auf FRITZ!Box-UI, FTP/FTPS auf Speichermedien), aktive WAN-Freigabe bleibt nur `443/tcp -> 192.168.178.58`, keine aktive IPv6-Freigabe sichtbar, UPnP-Selbstfreigaben aus.
- FRITZ!Box-Konfig-Backup exportiert und extern/off-system in Vaultwarden abgelegt: `Einstellungen_FRITZ.Box_7590_154.08.25_01.06.26_1318.export`; Kennwort und Datei bleiben ausserhalb des Repos.
- Hetzner-Account-Hygiene erledigt: externe Kontakt-/Rechnungs-Mail bestaetigt, Zahlung ok, 2FA mit Google Authenticator aktiv, Recovery Key offline ausgedruckt.
- Hetzner Storage Box geprueft: `storage-box-1`, `u565255.your-storagebox.de`, SSH-Port `23`, SSH aktiv, SMB/WebDAV aus, 64,94 GB / 1 TB belegt; Borg-UI-Key und separater Maintenance-Key funktionieren wieder nach Passwort-Recovery. Borg `append-only` ist bewusst nicht umgesetzt.
- Family-View Dashboard ist repo-seitig gebaut: `monitoring/grafana/dashboards/family-status.json` zeigt Family-App-Uptime, Backup-Alter, TLS-Restlaufzeit, Critical-Container und Image-Drift.
- Alt-Volume-Freigabe ist vorbereitet: `ops/maintenance/release-alt-volumes.sh --dry-run` validiert aktive Pfade, Container-Health, Restore-Freshness und gemountete Altpfade; Test am 2026-06-01 fand vier Kandidaten und keine Blocker, Ausfuehrung bleibt wegen Cutoff bis 2026-06-02 gesperrt.
- Borg-Nachlauf nach dem 2026-05-31-Sprint ist belegt: Archiv `Taegliche-Sicherung-2026-06-01T04:30:26.913`, 101669 Dateien, `rc=0`; Freshness-Check am 2026-06-01: Critical 0, Warnings 0.
- H:/ Nearline-Pull am 2026-06-01 repariert und manuell validiert: kuratierte Borg-Dumps Exit 0, Gitea-Bundles Exit 1 (Robocopy-Erfolg mit Kopien), Report `nearline-pull-2026-06-01-082553.md`.
- Immich-, Paperless-, Gitea- und Vaultwarden-Restore-Pfade sind belegt.
docs/AUTHELIA_OIDC_PLAN.md
-186
View File
@@ -1,186 +0,0 @@
# Authelia OIDC fuer Apps - Plan & Runbook
Stand: 2026-06-06. Authelia-Version: **v4.39.20**.
Ziel: App-uebergreifendes Single-Sign-On ueber Authelia als OpenID-Connect-Provider
(`https://auth.kaleschke.info`). Statt pro App eigener Logins meldet man sich einmal
bei Authelia an (inkl. 2FA) und wird per OIDC an die App durchgereicht.
> **Status:** aktives Runbook. Grafana und Mealie sind seit 2026-06-06 live
> und per Login-Smoke verifiziert. Der weitere Rollout bleibt additiv: lokale
> App-Logins bleiben als Fallback aktiv.
---
## Grundregeln (wichtig)
- **Secrets gehoeren nie ins Repo.** OIDC-Client-Secrets (Klartext und pbkdf2-Hash)
liegen ausschliesslich in der Host-Config `/mnt/user/appdata/authelia/config/configuration.yml`
(Hash) und im jeweiligen App-Stack (Klartext, via Komodo Stack-ENV / Secret-Datei),
plus optional Vaultwarden. Dieses Dokument enthaelt nur Schema und Variablennamen.
- **OIDC-Clients leben host-seitig**, wie der bestehende `beszel`-Client. Die Repo-Baseline
`security/authelia/configuration.yml` haelt nur die nicht-geheime Struktur
(`access_control` etc.); `services/authelia-diff.sh` vergleicht standardmaessig nur
`access_control`, OIDC-Clients auf dem Host loesen also keinen Drift-Alarm aus.
- **Issuer/Endpoints** (Authelia OIDC):
- Issuer: `https://auth.kaleschke.info`
- Authorization: `https://auth.kaleschke.info/api/oidc/authorization`
- Token: `https://auth.kaleschke.info/api/oidc/token`
- Userinfo: `https://auth.kaleschke.info/api/oidc/userinfo`
- JWKS: `https://auth.kaleschke.info/jwks.json`
- Discovery: `https://auth.kaleschke.info/.well-known/openid-configuration`
- **PKCE an, wo moeglich** (`require_pkce: true`, `S256`), wie beim Beszel-Client.
---
## Client-Schema (Authelia v4.39, gespiegelt vom bestehenden `beszel`-Client)
Pro App ein Block unter `identity_providers.oidc.clients` in der **Host-Config**:
```yaml
identity_providers:
oidc:
clients:
- client_id: '<app>'
client_name: '<App-Name>'
client_secret: '<pbkdf2-sha512-Hash - NUR auf dem Host>'
public: false
authorization_policy: 'two_factor' # admin-Apps: two_factor; Familien-Apps: s.u.
require_pkce: true
pkce_challenge_method: 'S256'
redirect_uris:
- 'https://<app>.kaleschke.info/<oidc-callback-pfad>'
scopes:
- 'openid'
- 'profile'
- 'email'
- 'groups'
response_types:
- 'code'
grant_types:
- 'authorization_code'
token_endpoint_auth_method: 'client_secret_basic'
userinfo_signed_response_alg: 'none'
```
### Client-Secret erzeugen (auf dem Host)
```bash
docker exec authelia authelia crypto hash generate pbkdf2 \
--variant sha512 --random --random.length 72 --random.charset rfc3986
```
- Ausgabe: **Random Password** (Klartext) + **Digest** (pbkdf2-Hash).
- **Hash** -> Host-Config `client_secret`.
- **Klartext** -> App-Stack (Komodo Stack-ENV/Secret) + optional Vaultwarden.
- Klartext **nicht** ins Repo, nicht in Logs.
---
## Reihenfolge / Rollout
| Stufe | App | Domain | OIDC-Support | Policy | Risiko | Begruendung |
|---|---|---|---|---|---|---|
| **1 (Proof) ERLEDIGT 2026-06-06** | Grafana (monitoring) | `monitoring.kaleschke.info` | nativ (`generic_oauth`) | `two_factor` | niedrig | **Live + Login verifiziert.** Authelia-Client `grafana` (host), Secret als Datei `/mnt/user/appdata/secrets/grafana_oidc_client_secret` via `__FILE`, ForwardAuth-Middleware durch OIDC ersetzt, lokaler Admin bleibt Fallback |
| 2 | Immich | `immich.kaleschke.info` | nativ (Admin-UI/Config-File) | s. u. (Familie) | mittel | **GEPARKT bis Onboarding (Entscheidung 2026-06-06):** nur `micha` hat Authelia-Account, Familien-SSO-Nutzen entsteht erst mit Familien-Accounts; Immich ist mobil-lastig (hoechste Stoeranfaelligkeit) und braucht UI/Config-File. Erst nach Onboarding gezielt. Runbook bereit. |
| 3 | Nextcloud | `cloud.kaleschke.info` | App `user_oidc` (+occ) | s. u. | mittel | **GEPARKT bis Onboarding (Entscheidung 2026-06-06):** wie Immich; braucht `user_oidc`-App-Install + `occ`. Lokaler Login bleibt. Erst nach Onboarding. Runbook bereit. |
| **4 ERLEDIGT 2026-06-06** | Mealie | `mealie.kaleschke.info` | nativ | `one_factor` | niedrig | **Live + Login verifiziert.** OIDC-Env additiv (lokaler Login bleibt), Secret als Stack-ENV `${MEALIE_OIDC_CLIENT_SECRET}`, `extra_hosts` noetig (s. Gotchas) |
| 5 | Paperless-ngx | `paperless.kaleschke.info` | `django-allauth` (Umgebungsvariablen) | `two_factor` | mittel | dokumentenlastig, Operator-nah |
**Nicht OIDC:** Vaultwarden hat kein Standard-Endnutzer-OIDC (SSO ist Enterprise/Bitwarden-Feature) -> bleibt eigener Login. ntfy bleibt wie gehabt.
### Policy Familien-Apps
- Admin-Apps (Grafana, Paperless): `authorization_policy: two_factor`.
- Familien-Apps (Immich, Nextcloud, Mealie): Start mit `one_factor` und lokalen
App-Logins als Fallback. 2FA fuer Familie erst spaeter, sobald TOTP-Enrollment
pro Person eingerichtet ist; sonst entsteht unnoetiges Lockout-Risiko.
---
## Stufe 1 konkret: Grafana (empfohlener Erststart)
### A) Authelia (Host) - Client anlegen
1. Secret erzeugen (Befehl oben). Klartext + Hash notieren.
2. In `/mnt/user/appdata/authelia/config/configuration.yml` unter
`identity_providers.oidc.clients` neuen Block einfuegen:
```yaml
- client_id: 'grafana'
client_name: 'Grafana'
client_secret: '<HASH>'
public: false
authorization_policy: 'two_factor'
require_pkce: true
pkce_challenge_method: 'S256'
redirect_uris:
- 'https://monitoring.kaleschke.info/login/generic_oauth'
scopes: ['openid', 'profile', 'email', 'groups']
response_types: ['code']
grant_types: ['authorization_code']
token_endpoint_auth_method: 'client_secret_basic'
userinfo_signed_response_alg: 'none'
```
3. `docker restart authelia`, Health + Log pruefen (`Startup complete`, keine Fehler).
### B) Grafana (Komodo Stack-ENV) - generic_oauth
Im `monitoring`-Stack (Grafana) setzen (Klartext-Secret aus Schritt A):
```
GF_AUTH_GENERIC_OAUTH_ENABLED=true
GF_AUTH_GENERIC_OAUTH_NAME=Authelia
GF_AUTH_GENERIC_OAUTH_CLIENT_ID=grafana
GF_AUTH_GENERIC_OAUTH_CLIENT_SECRET=<KLARTEXT-SECRET>
GF_AUTH_GENERIC_OAUTH_SCOPES=openid profile email groups
GF_AUTH_GENERIC_OAUTH_AUTH_URL=https://auth.kaleschke.info/api/oidc/authorization
GF_AUTH_GENERIC_OAUTH_TOKEN_URL=https://auth.kaleschke.info/api/oidc/token
GF_AUTH_GENERIC_OAUTH_API_URL=https://auth.kaleschke.info/api/oidc/userinfo
GF_AUTH_GENERIC_OAUTH_USE_PKCE=true
GF_AUTH_GENERIC_OAUTH_ALLOW_SIGN_UP=true
# optional Rollen-Mapping ueber groups:
# GF_AUTH_GENERIC_OAUTH_ROLE_ATTRIBUTE_PATH=contains(groups[*], 'admins') && 'Admin' || 'Viewer'
```
- `GF_AUTH_GENERIC_OAUTH_CLIENT_SECRET` als Stack-ENV-only (kein `_FILE`-Support) -> in
`docs/SECRETS_MAP.md` als `grafana_oidc_client_secret` (Stack-ENV) nachziehen.
### C) Test + Rollback
- Test: `monitoring.kaleschke.info` -> "Sign in with Authelia" -> Authelia-Login (2FA) -> zurueck in Grafana, eingeloggt.
- **Fallback bleibt:** lokaler Grafana-Admin-Login (`/login`) ist weiter aktiv -> kein Lockout.
- Rollback: `GF_AUTH_GENERIC_OAUTH_ENABLED=false` (Grafana redeploy) und/oder Client-Block in Authelia entfernen + `docker restart authelia`.
---
## Doku-Nachzug bei jedem neuen Client
- `docs/SECRETS_MAP.md`: pro App `<app>_oidc_client_secret` (Stack-ENV) + Hinweis "Hash in Authelia-Host-Config".
- `docs/SERVICE_CATALOG.md`: App-Zeile um "OIDC via Authelia" ergaenzen.
- Dieses Dokument: Rollout-Tabelle abhaken.
- `docs/MASTER_TODO.md`: Fortschritt im OIDC-Punkt nachziehen.
---
## Gotchas (aus dem realen Rollout 2026-06-06)
- **`extra_hosts` ist Pflicht fuer App-Container, die selbst zu Authelia connecten**
(OIDC-Discovery/Token sind Server-zu-Server): Der App-Container loest
`auth.kaleschke.info` per Docker-DNS oft nicht auf -> `httpx.ConnectTimeout` /
500 beim OAuth-Start. Fix wie Komodo:
```yaml
extra_hosts:
- "auth.kaleschke.info:192.168.178.58"
```
Cert validiert weiter (SNI/Hostname bleibt gleich, nur die IP wird gemappt).
Gilt fuer Mealie (bestaetigt) und sehr wahrscheinlich Paperless/Immich/Nextcloud.
- **Additiv heisst additiv:** OIDC als zusaetzlichen Login aktivieren, lokalen
Login NICHT abschalten, `AUTO_REDIRECT`/Force-OIDC aus -> kein Lockout.
- **Account-Linking per E-Mail:** Apps verknuepfen den OIDC-User i. d. R. per
E-Mail-Claim. Stimmt die Authelia-E-Mail mit dem App-Account, wird verknuepft;
sonst legt die App (bei aktivem Signup) einen neuen User an.
- **Secret-Mechanik je App verschieden:** Grafana `__FILE` (Docker-Secret),
Mealie Stack-ENV `${...}`. Hash immer in der Authelia-Host-Config, Klartext nie ins Repo.
## Spaetere Feinschliffe vor breitem Rollout
1. Gruppen/Rollen-Mapping: braucht es Authelia-Gruppen (z. B. `admins`, `family`) fuer
App-Rollen (Grafana Admin/Viewer, Nextcloud-Gruppen)? Wenn ja, in der Authelia
User-Datenbank Gruppen pflegen.
2. Familien-2FA spaeter neu bewerten, nachdem echte Familien-Accounts in Authelia
angelegt und TOTP pro Person verstanden ist.
docs/DISASTER_RECOVERY.md
+11 -103
View File
@@ -62,8 +62,7 @@ Diese Punkte sollten **vor** einem echten Ausfall geklaert sein:
| Thema | Sollzustand |
|---|---|
| Repo-Zugang ausserhalb von Gitea | privater GitHub-Push-Mirror `michaelkaleschke-spec/homelab-infra` und lokaler aktueller Clone vorhanden; fuer Bare-Metal-DR zusaetzlich Read-Only-PAT/Deploy-Key offline im DR-Kit |
| Operator-DR-Workstation | Gaming-PC mit aktuellem Repo-Clone, WSL2 + Borg-Client, SSH-Key fuer Hetzner Storage Box, Offline-Kopie Borg-Passphrase; Bestandteile siehe `docs/EXTERNAL_DEPENDENCIES.md` Abschnitt "DR-Workstation Bare-Metal-Kit" |
| Repo-Zugang ausserhalb von Gitea | privater GitHub-Push-Mirror `michaelkaleschke-spec/homelab-infra` und lokaler aktueller Clone vorhanden |
| Unraid USB-/Flash-Backup | `unraid-flash-config.tar.gz` wird vor Borg unter `/mnt/user/backups/borg/dumps/latest` erzeugt und nach Hetzner/Borg gesichert; Unraid-Connect-Cloud-Backup optional zusaetzlich |
| Borg-Ziel | nicht nur lokal auf demselben Ausfallpfad |
| Borg-Passphrase | Host-Secret-Datei vorhanden und fuer Borg-Zugriff verifiziert; externe Offline-Hinterlegung vom Operator am 2026-05-26 bestaetigt |
@@ -88,15 +87,9 @@ Deshalb gilt:
Verfuegbare Wege:
- externer Push-Mirror: `https://github.com/michaelkaleschke-spec/homelab-infra` (privat, Read-PAT/Deploy-Key noetig — siehe `docs/EXTERNAL_DEPENDENCIES.md` Abschnitt "DR-Workstation Bare-Metal-Kit")
- lokaler Bare-Clone auf der Operator-DR-Workstation (Standardweg)
- normaler lokaler Arbeits-Clone auf der Operator-DR-Workstation
Operativer Pfad fuer den Repo auf den frisch installierten Unraid-Host:
1. Operator-DR-Workstation holt den aktuellen Clone (lokaler Stand oder per `git clone` aus dem GitHub-Mirror mit dem offline gesicherten Read-PAT/Deploy-Key).
2. Kopie via USB, SMB oder `rsync ueber SSH/Tailscale` nach `/mnt/user/services/homelab-infra/` auf dem Unraid-Host.
3. Stand pruefen: `git -C /mnt/user/services/homelab-infra log --oneline -1` zeigt einen plausibel aktuellen Commit.
- externer Push-Mirror: `https://github.com/michaelkaleschke-spec/homelab-infra`
- lokaler Bare-Clone auf dem PC
- normaler lokaler Arbeits-Clone auf dem PC
Wenn **weder GitHub-Mirror noch lokaler Repo-Clone** verfuegbar sind, ist `services/gitea/data` selbst ein kritischer Restore-Pfad.
@@ -155,12 +148,6 @@ Erwartete Basis unter `/mnt/user/appdata/secrets/`:
- `redis_password.txt`
- `borg_repo_passphrase.txt`
- `vaultwarden_admin_token.txt`
- `homelab_smtp_password.txt`
- `n8n_encryption_key.txt`
- `monitoring_grafana_admin_password.txt`
- `monitoring_grafana_influxdb_token.txt`
- `influxdb3_admin_token.json`
- `filebrowser_admin_password.txt`
- `hermes_runner_id_ed25519`
Weitere relevante Secret-Pfade:
@@ -254,52 +241,17 @@ Besonders kritisch:
**Nicht blind alles extrahieren**, wenn nur einzelne Pfade oder Dienste betroffen sind.
### 7.3 Borg-Extract ohne `borg-ui`-Container
Im Bare-Metal-Fall ist `borg-ui` selbst kalt. Der initiale Borg-Extract laeuft deshalb nicht ueber den Container, sondern wahlweise ueber:
1. **Operator-DR-Workstation** (Standardweg) - WSL2 + `borgbackup` extrahieren gezielt nach `/mnt/user/backups/restore-lab/...` oder per `rsync`/SMB auf den Unraid-Host.
2. **Native Docker-Variante auf Unraid** - `docker run --rm -e BORG_PASSPHRASE=... -v /mnt/user/backups/restore-lab:/restore -v ~/.ssh:/root/.ssh:ro borgbackup/borg:1.4 ...`.
Erst nach Stufe 5 Phase 4 ist `borg-ui` produktiv und uebernimmt den weiteren Betrieb. Die Borg-Passphrase wird interaktiv aus der Offline-Sicherung eingegeben, nicht in Skripte/Tickets kopiert.
---
## 8. Phase 4 - Bootstrap-Reihenfolge der Stacks
**Nie alle Stacks gleichzeitig starten.**
### Stufe 0 - Docker-Grundlage
Vor dem ersten `docker compose up` muss sichergestellt sein:
1. `docker info` antwortet ohne Fehler.
2. Externe Docker-Netze existieren. Wenn nicht vorhanden:
```bash
docker network create --driver bridge frontend_net
docker network create --driver bridge --internal backend_net
docker network create --driver bridge monitoring_net
```
3. Pfad `/mnt/user/appdata/traefik/dynamic/` enthaelt `middlewares.yml`, `tls.yml`, `dashboards.yml` (Sonderregel siehe Sektion 10). Ohne diese Dateien startet Traefik ohne Middleware-Definitionen und alle Authelia-geschuetzten Routen brechen still.
Erfolgskriterium: `docker network ls` zeigt `frontend_net`, `backend_net`, `monitoring_net`; Traefik-`dynamic/`-Dateien sind vorhanden und valide.
### Stufe 1 - Netz und Zugang
1. `traefik/`
2. `host-services/Adguard/`
> **Tailscale-Hinweis:** Tailscale laeuft als **natives Unraid-Plugin**
> (`tailscale.plg`, Interface `tailscale1`, State `/boot/config/plugins/tailscale/state`,
> im Flash-Backup gesichert) und ist der Subnet-Router fuer `192.168.178.0/24`.
> Es ist **kein** Compose-/Komodo-Stack mehr und kommt mit dem Host hoch — daher
> nicht in dieser Bootstrap-Liste. Der frueher hier gelistete Docker-Stack
> `host-services/tailscale/` (userspace-only, redundant) wurde am 2026-06-06
> entfernt (siehe `docs/NETWORK_INVENTORY.md`).
**LE-Rate-Limit-Vorsicht:** Wenn `/mnt/user/appdata/traefik/letsencrypt/acme.json` verloren oder unklar ist, zuerst gegen Let's Encrypt Staging ausstellen lassen (`--certificatesresolvers.le.acme.caserver=https://acme-staging-v02.api.letsencrypt.org/directory`). Erst nach gruenem Smoke wieder auf Production-CA. Hintergrund: 50 Zertifikate pro Domain pro Woche reicht bei einem hektischen Wiederanlauf nicht, wenn man die Sub-Domains mehrfach hochzieht.
3. `host-services/tailscale/`
Ziel:
@@ -338,13 +290,6 @@ Ziel:
- Periphery verbindet sich wieder
- Stacks koennen wieder aus Git konsumiert werden
**Wichtige Stolperfallen in Stufe 3:**
- **KOMODO_*-Werte sind nicht aus dem eigenen Mongo-Dump rekonstruierbar.** Pflichtquelle im Bare-Metal: offline gesicherte Operator-Notiz (Status 2026-06-03: noch nicht angelegt, siehe `docs/EXTERNAL_DEPENDENCIES.md` und Audit-Restliste). Vaultwarden ist erst in Stufe 4 verfuegbar.
- **Mongo-Datadir und `komodo_mongo_password.txt` muessen aus demselben Snapshot stammen.** Bei Mismatch akzeptiert Mongo den Login nicht und der Stack startet nicht. Auswege: entweder die zur Datadir passende Secret-Datei aus dem gleichen Borg-Stand restaurieren, oder Datadir leeren, neu initialisieren und Daten via `mongorestore --archive --gzip` aus `komodo-mongo.archive.gz` einspielen (Drill belegt 2026-06-03).
- **`extra_hosts: git.kaleschke.info:192.168.178.58`** in `ops/komodo/docker-compose.yml` ist hardgecodet. Bei geaenderter Host-LAN-IP auf der Recovery-Hardware den Wert vor `compose up` anpassen, sonst kann Komodo-Core das interne Gitea nicht erreichen.
- **Stack-ENV-Werte fuer Apps in Stufe 4** (Paperless/Immich/Mailarchiver/Speedtest) sind in Stufe 3 noch leer. Zwei Wege: (a) optionaler `mongorestore` aus `komodo-mongo.archive.gz` direkt nach Komodo-Start, dann sind alle Stack-ENVs zurueck; (b) Werte manuell in der Komodo-UI eintragen, sobald Vaultwarden in Stufe 4 verfuegbar ist (was Paperless/Immich/Mailarchiver hinter Vaultwarden zwingt, nicht parallel).
### Stufe 4 - Kritische Anwendungen
9. `security/vaultwarden/`
@@ -397,7 +342,6 @@ Ziel:
- Mealie startet
- Mail-Archiver startet
- Nextcloud startet und sieht Dateien
- Pro App: `docker logs <container>` zeigt keine `password authentication failed`-, `FATAL: role does not exist`- oder `Connection refused`-Eintraege (verifiziert, dass Stack-ENV-Werte und DB-Rollen passen)
### 9.4 Backup-/Beobachtungsebene
@@ -438,7 +382,7 @@ Vor dem Start muessen vorhanden sein:
- `/mnt/user/appdata/secrets/authelia_smtp_password.txt`
- SMTP-Zugang fuer `michideheld@gmx.de`
Beim Smoke-Test muss `authelia config validate` erfolgreich sein; der SMTP-Startup-Check darf den Start nicht blockieren.
Beim Smoke-Test muss `authelia validate-config` erfolgreich sein; der SMTP-Startup-Check darf den Start nicht blockieren.
### `nextcloud`
@@ -496,11 +440,11 @@ Aktive Datenpfade:
- Mealie PostgreSQL: `/mnt/user/appdata/mealie/postgres18`
- Nextcloud PostgreSQL: `/mnt/user/appdata/nextcloud/postgres18`
Rollback-Altstaende wurden nach Burn-in am 2026-06-02 reversibel archiviert:
Rollback-Altstaende, bis zur separaten Loeschfreigabe nicht entfernen:
- Shared PostgreSQL 17: `/mnt/user/appdata/_archive/pg18-immich-rollback-volumes-20260602/postgresql17`
- Mealie PostgreSQL 17: `/mnt/user/appdata/_archive/pg18-immich-rollback-volumes-20260602/mealie-postgres17`
- Nextcloud PostgreSQL 17: `/mnt/user/appdata/_archive/pg18-immich-rollback-volumes-20260602/nextcloud-postgres17`
- Shared PostgreSQL 17: `/mnt/user/appdata/postgresql17`
- Mealie PostgreSQL 17: `/mnt/user/appdata/mealie/postgres`
- Nextcloud PostgreSQL 17: `/mnt/user/appdata/nextcloud/postgres`
Restore-Reihenfolge fuer den Shared-Cluster:
@@ -510,7 +454,7 @@ Restore-Reihenfolge fuer den Shared-Cluster:
4. Datenbanken anlegen und Custom-Format-Dumps mit `pg_restore` einspielen.
5. Restore-Logs auf echte `ERROR`, `FATAL` und `PANIC` pruefen.
Immich ist bewusst nicht Teil dieses PostgreSQL-18-Laufs: Die produktive DB bleibt auf PostgreSQL 14 und nutzt das Immich-Postgres-Image mit VectorChord/pgvector. VectorChord-Backups brauchen zum Restore ein Image mit VectorChord; der alte pgvecto.rs-Datenpfad ist als Rollback-Altstand unter `/mnt/user/appdata/_archive/pg18-immich-rollback-volumes-20260602/immich-postgres-pgvecto-rs` archiviert.
Immich ist bewusst nicht Teil dieses PostgreSQL-18-Laufs: Die produktive DB bleibt auf PostgreSQL 14 und nutzt das Immich-Postgres-Image mit VectorChord/pgvector. VectorChord-Backups brauchen zum Restore ein Image mit VectorChord; der alte pgvecto.rs-Datenpfad `/mnt/user/appdata/immich_postgres` bleibt bis zur separaten Loeschfreigabe als Rollback-Altstand erhalten.
### Hermes Agent
@@ -529,40 +473,6 @@ Smoke-Test: `hermes-gateway` healthcheck ist gruen, `hermes.kaleschke.info` leit
`Micha/homelab-infra` wird als privater GitHub-Push-Mirror gespiegelt. Dieser Mirror ist der bevorzugte Repo-Bootstrap, falls Gitea selbst nach einem Ausfall noch nicht laeuft. Wenn weder GitHub-Mirror noch lokaler Clone verfuegbar sind, ist `services/gitea/data` selbst Teil des kritischen Wiederanlaufs.
### 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.
Wichtige Pfade und Artefakte:
- Runbook: `ops/windows-reinstall/docs/windows-image-backup-baseline.md`
- Backup-Ziel: `\\kallilabcore\backups\windows-images\baerchen`
- Host-Pfad: `/mnt/user/backups/windows-images/baerchen/`
- Recovery-Medium: USB-Stick `VEEAMRE`, beschriftet
`baerchen Veeam Recovery - 2026-06-05`
- Veeam Job: `baerchen-c-image`
- Veeam Storage Encryption: erster Full-Lauf 2026-06-05 laut Job-Log
unverschluesselt (`StorageEncryptionEnabled=False`); falls spaeter aktiviert,
Passwort in Vaultwarden Secure Note `Veeam baerchen backup encryption password`
sichern
Restore-Kurzpfad:
1. Von `VEEAMRE` booten.
2. SMB-Ziel `\\kallilabcore\backups\windows-images\baerchen` oeffnen.
3. Mit bestehendem SMB-User `micha` authentifizieren.
4. Restore Point auswaehlen.
5. Falls der Restore Point verschluesselt ist: Veeam-Encryption-Passwort aus
Vaultwarden eingeben.
6. Bare-Metal-Restore nur auf die Windows-Systemdisk ausfuehren.
BitLocker ist am 2026-06-05 bewusst noch nicht aktiv. Falls BitLocker spaeter
aktiviert wird, muss der Recovery-Key vor dem naechsten Restore-Drill in
Vaultwarden, unter `D:\30_Finanzen\BitLocker-RecoveryKey-baerchen-<DATUM>.txt`
und physisch ausserhalb des Rechners abgelegt sein.
---
## 11. Offene Vorbereitungs-To-dos
@@ -572,8 +482,6 @@ und physisch ausserhalb des Rechners abgelegt sein.
- Komodo Stack-ENV-Werte zentral ausserhalb von Komodo dokumentieren
- regelmaessige automatisierte Restore-Smoke-Tests fuer Vaultwarden, Gitea und Paperless etablieren
- `komodo-mongo`-Dump nach Major-Upgrades gezielt kontrollieren
- `baerchen` Recovery-USB-Boot-/SMB-Test nach erfolgreichem erstem Full-Lauf
verifizieren
---
docs/DR_DRILL_2026-06-03.md
-504
View File
@@ -1,504 +0,0 @@
# DR Tabletop Drill - 2026-06-03
Trockenlauf gegen `docs/DISASTER_RECOVERY.md` Phase 0 bis 5 plus referenzierte
Runbooks (`SERVICES_RECOVERY.md`, `RESTORE_MATRIX.md`, `SECRETS_MAP.md`,
`RESTORE_HANDBOOK.md`, `EXTERNAL_DEPENDENCIES.md`).
Szenario: Bare-Metal-Ausfall. Unraid-Host und alle lokalen Festplatten sind
weg. Operator hat: Laptop, Hetzner-Account, Vaultwarden-Export, Repo-Doku.
Soft-Recovery (Host laeuft, Appdata futsch) ist eine Teilmenge dieser
Findings.
Methode: kalter Lesetest. Kein Container gestartet, keine Skripte
ausgefuehrt. Jeder Befund ist mit Repo-Datei und Zeile belegt. Spekulative
"vielleicht unklar"-Befunde sind weggelassen.
Severity:
- **CRITICAL** - blockiert Wiederanlauf, ohne Workaround nicht loesbar
- **HIGH** - blockiert eine Phase, Workaround moeglich aber undokumentiert
- **MED** - kostet Zeit oder fuehrt zu vermeidbarem Fehler
- **LOW** - Konsistenz / Stil
## Zusammenfassung
| ID | Phase | Severity | Thema |
|---|---|---|---|
| P0-1 | 0 | HIGH | Brueckenpfad Windows-Clone -> frischer Unraid-Host fehlt |
| P0-2 | 0 | HIGH | GitHub-Mirror-Zugang im DR ist nicht eigenstaendig dokumentiert |
| P1-1 | 1 | CRITICAL | Unraid-Flash-Restore: kein dokumentierter Extract-Pfad ohne laufenden Host |
| P1-2 | 1 | MED | Unraid-OS-Flash-Restore-Test laut Matrix nie real getestet |
| P2-1 | 2 | HIGH | KOMODO_* externe Operator-Notiz ist Pflichtquelle, Existenz nicht verifizierbar |
| P2-2 | 2 | HIGH | DR.md Phase 4 vs. SERVICES_RECOVERY.md Bootstrap-Reihenfolge widerspruechlich |
| P2-3 | 2 | MED | `homelab_smtp_password.txt` fehlt in DR.md Phase 2.6.1 |
| P2-4 | 2 | MED | `n8n_encryption_key.txt` fehlt in DR.md Phase 2.6.1 |
| P2-5 | 2 | LOW | Monitoring-/Filebrowser-Secrets fehlen in DR.md Phase 2.6.1 |
| P3-1 | 3 | HIGH | Borg-Client ohne `borg-ui`-Container ist nicht dokumentiert |
| P3-2 | 3 | HIGH | Borg-Passphrase-Bootstrap aus Offline-Sicherung nicht als expliziter Schritt |
| P3-3 | 3 | MED | Hetzner-Maintenance-Key aus Vaultwarden ist Henne-Ei im Bare-Metal |
| P4-1 | 4 | HIGH | Externe Docker-Netze in DR.md Phase 4 Stufe 1 nicht erwaehnt |
| P4-2 | 4 | HIGH | Cloudflare-LE-Rate-Limit-Risiko bei verlorenem `letsencrypt`-State |
| P4-3 | 4 | MED | `traefik/dynamic/*` als Phase-4-Pre-Check fehlt in der Reihenfolge |
| P4-4 | 4 | HIGH | Authelia "frische Postgres ohne Dump"-Pfad nicht beschrieben |
| P4-5 | 4 | LOW | Gitea in Stufe 2 hinter Postgres ist faktisch nicht noetig (SQLite) |
| P4-6 | 4 | HIGH | Komodo-Mongo Passwort-Lockout-Risiko bei restauriertem Datadir |
| P4-7 | 4 | MED | Komodo `extra_hosts` mit hardgecodeter LAN-IP bricht bei IP-Wechsel |
| P4-8 | 4 | HIGH | Stack-ENV-Wiederherstellung in Komodo praktisch nur manueller UI-Eintrag |
| P5-1 | 5 | LOW | Smoke-Tests in Phase 5 weniger streng als RESTORE_MATRIX |
| P5-2 | 5 | MED | Kein Verifikationspunkt fuer App-zu-DB-Verbindung nach Stack-ENV-Restore |
| X-1 | uebergreifend | HIGH | Nextcloud-Restore-Skript ist da, aber noch nie real ausgefuehrt |
## Phase 0 - Repo-Zugang
### P0-1 (HIGH) - Brueckenpfad Windows-Clone -> frischer Unraid fehlt
`docs/DISASTER_RECOVERY.md:88-93` listet als Repo-Quellen: GitHub-Mirror,
lokaler Bare-Clone, lokaler Arbeits-Clone. `SERVICES_RECOVERY.md:67-68`
nennt den lokalen Operator-Clone unter `G:\Gitea_Clone\homelab-infra\` als
Vorzug.
Luecke: der Pfad "wie kommt der Windows-Clone auf einen frisch installierten
Unraid-Host" ist nicht beschrieben. Implizit: SMB-Share, USB-Stick, scp ueber
LAN. Aber auf einem frisch aufgesetzten Unraid existiert noch keine
funktionierende SMB-Konfiguration; SSH-Key vom Operator-PC ist nicht
vorbereitet.
Vorschlag: Zwei Saetze in `DISASTER_RECOVERY.md` Phase 0 ergaenzen, wie der
Operator-Clone konkret zum Host kommt (USB-Stick + `mkdir -p
/mnt/user/services/homelab-infra && rsync -a` aus Operator-Windows-PC, oder
direkt vom GitHub-Mirror per `git clone https://github.com/...` auf dem
Unraid-Host).
### P0-2 (HIGH) - GitHub-Mirror-Zugang im DR
`SECRETS_MAP.md:42` sagt, der GitHub-Push-Mirror-PAT liegt in den
Gitea-Mirror-Settings persistent unter `/mnt/user/services/gitea/data`.
`EXTERNAL_DEPENDENCIES.md:18` nennt den Mirror als `michaelkaleschke-spec/
homelab-infra` und betont "privater" Push-Mirror.
Luecke: Wenn der Mirror **privat** ist, scheitert ein anonymer `git clone`
im DR-Bootstrap. Es gibt keine dokumentierte Notfall-Quelle fuer einen
Read-PAT/SSH-Key, der lokal beim Operator (nicht in Gitea, nicht im Repo)
verfuegbar ist.
Vorschlag in `EXTERNAL_DEPENDENCIES.md`: entweder explizit dokumentieren,
dass der Mirror lesend `Public` ist (DR-fit), oder einen Read-PAT in der
Vaultwarden-/Offline-Notiz neben der Borg-Passphrase als Bootstrap-Voraussetzung
benennen.
## Phase 1 - Unraid und Shares
### P1-1 (CRITICAL) - Unraid-Flash-Restore ohne laufenden Host
`docs/DISASTER_RECOVERY.md:107` sagt: "Primaere lokale/off-site
Restore-Quelle fuer die bestehende Flash-Konfiguration ist das
Borg-Artefakt `unraid-flash-config.tar.gz` aus
`/mnt/user/backups/borg/dumps/latest`."
Henne-Ei: der Pfad ist auf den verlorenen Shares oder auf Hetzner. Hetzner-
Zugriff braucht einen funktionierenden Linux-Host mit Borg-Client und
Passphrase. Im Bare-Metal-Fall ist genau das nicht da. RESTORE_MATRIX.md
Tier 1 Zeile `Unraid OS Flash` (`docs/RESTORE_MATRIX.md:29`) sagt nur "Unraid
USB Flash Creator / neuer Boot-Stick" - das beschreibt die Stick-Erzeugung,
nicht den Extract des Borg-Artefakts.
Operativ: Operator braucht einen Laptop mit Borg-Client + Passphrase +
SSH-Key fuer die Hetzner-Storage-Box. Das ist eine **separat zu pflegende
Operator-Workstation-Voraussetzung** und ist in keinem Repo-Dokument als
DR-Vorbedingung gelistet.
Vorschlag: In `EXTERNAL_DEPENDENCIES.md` oder `DISASTER_RECOVERY.md`
Abschnitt 3 als Pflichtposten aufnehmen: "Operator-Laptop mit installiertem
Borg-Client, SSH-Key fuer Hetzner und Zugriff auf die offline gesicherte
Passphrase". Inklusive Test, dass der Operator den Extract tatsaechlich
durchfuehren kann.
### P1-2 (MED) - Unraid-OS-Flash-Restore-Test nie gelaufen
`docs/RESTORE_MATRIX.md:140` Spalte "Letzter Restore-Test" fuer Unraid OS
Flash: `-` (kein Test). Das ist die Grundlage fuer Phase 1 und ist nie als
Smoke verifiziert. Empfehlung: einmaliger Test, der die Tar-Archiv-Struktur
gegen die erwarteten Flash-Pfade prueft (kein echter Boot-Test noetig).
## Phase 2 - Secrets und Stack-ENV
### P2-1 (HIGH) - KOMODO_* externe Operator-Notiz als Pflichtquelle
`docs/SECRETS_MAP.md:132,138-143` macht den Komodo-Sonderfall klar: die
KOMODO_*-Secrets sind aus dem eigenen Mongo-Dump nicht rekonstruierbar,
solange Komodo nicht laeuft. Quellen: Vaultwarden ODER externe Notiz.
Im Bare-Metal-Fall ist Vaultwarden in DR.md Phase 4 Stufe 4, Komodo in
Phase 4 Stufe 3. Damit ist die **externe Operator-Notiz** die einzige
Pflichtquelle in der Reihenfolge.
Luecke: ob diese Notiz wirklich existiert und die 5 Werte
(KOMODO_SECRET_KEY, KOMODO_WEBHOOK_SECRET, KOMODO_JWT_SECRET,
KOMODO_MONGO_PASSWORD, KOMODO_PERIPHERY_PASSKEY) enthaelt, ist in keinem
Repo-Dokument bestaetigt. Die Borg-Passphrase ist als "Operator-Bestaetigung
2026-05-26" dokumentiert; eine analoge Bestaetigung fuer die KOMODO_*-Notiz
fehlt.
Vorschlag: gleiche Form wie Borg-Passphrase - eine Zeile in
`EXTERNAL_DEPENDENCIES.md` "Komodo-Stack-ENV-Notiz offline gesichert,
Operator-Bestaetigung YYYY-MM-DD".
### P2-2 (HIGH) - Reihenfolgen-Inkonsistenz DR vs. SERVICES_RECOVERY
`docs/SERVICES_RECOVERY.md:102` (Stufe C, Komodo-Bootstrap): "Vaultwarden
(sobald restauriert), externe Operator-Notiz, oder Komodo-Mongo-Dump (nur
wenn Mongo separat bereits gestartet ...)".
`docs/DISASTER_RECOVERY.md:247-301` (Phase 4): Stufe 3 = Komodo, Stufe 4 =
Vaultwarden.
Wenn ein Leser sich an DR.md Phase 4 haelt, ist Vaultwarden nach Komodo
fertig. Aber SERVICES_RECOVERY.md Stufe C setzt Vaultwarden als optionale
Vorab-Quelle voraus. Ohne externe Notiz heisst das praktisch: Komodo kann
nicht starten. Die Konsequenz steht nirgendwo explizit in DR.md.
Vorschlag: In `DISASTER_RECOVERY.md` Phase 4 Stufe 3 einen Hinweisblock
ergaenzen: "KOMODO_*-Werte muessen vor Stufe 3 aus externer Notiz oder
einer in Stufe 2 voraus gezogenen Vaultwarden-Instanz vorliegen. Default-
Pfad: externe Notiz."
### P2-3 (MED) - `homelab_smtp_password.txt` fehlt in DR.md 6.1
`docs/SECRETS_MAP.md:20` listet `/mnt/user/appdata/secrets/
homelab_smtp_password.txt` fuer Vaultwarden-SMTP. In `DISASTER_RECOVERY.md`
Abschnitt 6.1 (`docs/DISASTER_RECOVERY.md:136-151`) ist sie nicht
aufgefuehrt. Vaultwarden startet ohne, kann aber keine Einladungs-/
Benachrichtigungs-Mails versenden. Klein, aber unsichtbarer Folgefehler im
Familien-Onboarding-Pfad.
### P2-4 (MED) - `n8n_encryption_key.txt` fehlt in DR.md 6.1
`docs/SECRETS_MAP.md:58` listet `/mnt/user/appdata/secrets/
n8n_encryption_key.txt`. In DR.md 6.1 fehlt sie komplett.
`SECRETS_MAP.md:135` macht die Folgen explizit: "Bei Verlust aller
Quellen: n8n startet, aber alle gespeicherten Credentials sind unbrauchbar".
Da n8n den GMX-Mail-Workflow fuer das Gitea-`Micha/mails`-Repo betreibt,
ist das ein direkter Workflow-Ausfall.
### P2-5 (LOW) - Monitoring-/Filebrowser-Secrets fehlen in DR.md 6.1
`docs/SECRETS_MAP.md:53-55`: `influxdb3_admin_token.json`,
`monitoring_grafana_admin_password.txt`,
`monitoring_grafana_influxdb_token.txt` sowie
`filebrowser_admin_password.txt` sind nicht in DR.md 6.1. Tier-3-Apps,
Folge ist nur ein UI-Initialisierungs-Schritt nach Wiederanlauf. Keine
Critical-Konsequenz, aber Inkonsistenz.
## Phase 3 - Borg-Extract
### P3-1 (HIGH) - Borg-Client ohne `borg-ui`-Container
`docs/RESTORE_HANDBOOK.md:30-33` sagt explizit: "Borg-Zugriff laeuft ueber
den vorhandenen `borg-ui`-Container".
Im Bare-Metal-Fall ist `borg-ui` selbst kalt (Tier 3, DR.md Phase 4 Stufe 5).
Es gibt keinen dokumentierten Pfad, wie der erste Borg-Extract ohne diesen
Container laeuft. Implizite Optionen: nativer Borg auf Unraid (Plugin),
`docker run --rm borgbackup/borg`, oder Operator-Laptop. Keine davon ist
benannt.
Vorschlag: In `RESTORE_HANDBOOK.md` Abschnitt 2 einen "Bare-Metal-Vorlauf"
ergaenzen, der den initialen Borg-Extract ohne borg-ui-Container
beschreibt - z. B. `docker run --rm -v
/mnt/user/backups/restore-lab:/restore borgbackup/borg ...`.
### P3-2 (HIGH) - Borg-Passphrase-Bootstrap nicht als expliziter Schritt
`docs/DISASTER_RECOVERY.md:68`: "Host-Secret-Datei vorhanden und fuer
Borg-Zugriff verifiziert; externe Offline-Hinterlegung vom Operator am
2026-05-26 bestaetigt."
Praktisch heisst das: im Bare-Metal-Fall liest der Operator die Passphrase
aus einem analogen Medium und tippt sie in den Borg-Client. Das ist ein
**Bootstrap-Schritt**, der nicht als Schritt dokumentiert ist. Er steckt
implizit in "extern bestaetigt".
Vorschlag: Ein nummerierter Bullet in `DISASTER_RECOVERY.md` Phase 3 ("Wenn
echte Daten aus Borg benoetigt werden"): "Schritt 1: Borg-Passphrase aus
Offline-Sicherung beschaffen. Wert wird nicht in Skripte oder Tickets
kopiert; nur in den interaktiven Borg-Aufruf eingegeben."
### P3-3 (MED) - Hetzner-Maintenance-Key im Bare-Metal
`docs/EXTERNAL_DEPENDENCIES.md:17`: "Maintenance-Key liegt in Vaultwarden".
Im Bare-Metal-Bootstrap ist Vaultwarden Phase 4 Stufe 4. Damit ist der Key
fuer die initiale Phase-3-Hetzner-Verbindung nicht zugaenglich. Implizit
muss er ebenfalls offline gesichert sein (analog Borg-Passphrase).
Vorschlag: gleiche Form wie Borg-Passphrase - eine Operator-Bestaetigung
in `EXTERNAL_DEPENDENCIES.md`, dass der Hetzner-SSH-Key auch ausserhalb von
Vaultwarden offline verfuegbar ist. Sonst ist die "Vaultwarden"-Aussage
fuer Bare-Metal eine Falle.
## Phase 4 - Bootstrap-Reihenfolge
### P4-1 (HIGH) - Externe Docker-Netze in DR.md Phase 4 Stufe 1 nicht erwaehnt
`docs/SERVICES_RECOVERY.md:82-84` Stufe A schreibt explizit: "Externe
Docker-Netze existieren oder werden erzeugt (`frontend_net`, `backend_net`).
Wenn nicht vorhanden: `docker network create --driver bridge frontend_net`
bzw. `... --internal backend_net`."
`docs/DISASTER_RECOVERY.md:252-260` Phase 4 Stufe 1 nennt nur Traefik,
AdGuard, Tailscale. Kein Hinweis auf externe Netze.
`traefik/docker-compose.yml:70-76` deklariert `frontend_net`, `backend_net`,
`monitoring_net` als `external: true`. Ohne vorab erstellte Netze scheitert
der erste `docker compose up` mit "network frontend_net not found".
Vorschlag: In `DISASTER_RECOVERY.md` Phase 4 vor Stufe 1 einen Vorlauf
"Stufe 0 - Docker-Grundlage" einfuegen, der die Netzwerk-Erzeugung wie in
`SERVICES_RECOVERY.md` Stufe A explizit listet.
### P4-2 (HIGH) - Cloudflare-LE-Rate-Limit-Risiko
`docs/RESTORE_MATRIX.md:30` markiert `letsencrypt` korrekt als
Restore-relevant. `docs/DISASTER_RECOVERY.md:240` listet
`/mnt/user/appdata/traefik/letsencrypt` ebenfalls als kritischen
Borg-Restore-Pfad.
Luecke: kein Hinweis auf den Praxisfall "LE-State verloren, frischer
Acme-Run". Let's Encrypt hat ein Rate-Limit von 50 Zertifikaten/Domain/
Woche und 5 Duplicate-Zertifikate/Woche. Bei einer Multi-Sub-Domain-
Konstellation wie `*.kaleschke.info` (15+ Hostnames) ist das beim
hektischen DR-Bootstrap erreichbar.
Vorschlag: In `DISASTER_RECOVERY.md` Phase 4 Stufe 1 einen Hinweis: "Bei
verlorenem oder unklarem `acme.json` zuerst gegen
`acme-staging-v02.api.letsencrypt.org` ausstellen lassen, erst nach
gruenem Smoke auf Production-CA umschalten." Ist eine Praesentations-
Aenderung in den Compose-Args, kein neuer Code.
### P4-3 (MED) - `traefik/dynamic/*` als Pre-Check fehlt
`docs/DISASTER_RECOVERY.md:357-365` Sektion 10 beschreibt die manuelle
Sonderregel fuer `traefik/dynamic/*`. Korrekt.
`docs/DISASTER_RECOVERY.md:252-260` Phase 4 Stufe 1 verweist nicht auf
diese Sonderregel. Wer der Reihenfolge folgt und Sektion 10 nicht liest,
startet Traefik ohne Middlewares - alle 2FA-Routen brechen still.
Vorschlag: Cross-Reference in Phase 4 Stufe 1: "Vor `docker compose up
traefik` pruefen, dass `/mnt/user/appdata/traefik/dynamic/middlewares.yml`,
`tls.yml`, `dashboards.yml` vorhanden sind (Sonderregel Sektion 10)."
### P4-4 (HIGH) - Authelia "frische Postgres ohne Dump"-Pfad fehlt
`docs/DISASTER_RECOVERY.md:267-275` Phase 4 Stufe 2 startet Postgres und
Authelia. Authelia erwartet eine Rolle `authelia` mit dem Passwort aus
`authelia_postgres_password.txt`. Im Restore-Pfad mit `pg_dumpall --globals-
only` ist die Rolle abgedeckt.
Bei einem **fresh-start** (keine alten Daten, nur Container hochfahren) ist
die Rolle nicht da. Postgres-Image legt sie nicht automatisch an. Authelia
schlaegt mit "FATAL: role authelia does not exist" fehl.
Luecke: Der Initialisierungspfad fuer eine frische Postgres ohne
pg_dumpall ist in der Doku nicht beschrieben. Im echten DR mit Borg ist
das unwahrscheinlich, aber im Soft-Recovery oder Migrations-Drill schon.
Vorschlag: In `DISASTER_RECOVERY.md` Phase 4 Stufe 2 eine optionale
Anweisung: "Falls Postgres frisch ist (kein Dump-Restore), `infra/
postgresql17/init/`-Skripte oder manuelle `CREATE ROLE`/`CREATE DATABASE`-
Schritte ergaenzen."
### P4-5 (LOW) - Gitea nach Postgres ist faktisch unnoetig
`docs/DISASTER_RECOVERY.md:267-275` Phase 4 Stufe 2 ordnet Gitea hinter
Postgres ein. Gitea nutzt SQLite (`gitea.sqlite.dump`), nicht den shared
Postgres. Reihenfolge ist nicht falsch, aber irrefuehrend. Nicht kritisch.
### P4-6 (HIGH) - Komodo-Mongo Passwort-Lockout-Risiko
`ops/komodo/docker-compose.yml:18-20` zeigt: `komodo-mongo` initialisiert
sich bei leerem Datadir mit `MONGO_INITDB_ROOT_PASSWORD_FILE` aus
`/mnt/user/appdata/secrets/komodo_mongo_password.txt`.
Restore-Fall: Datadir aus Borg restauriert, Secret-Datei aus Borg
restauriert - beide aus demselben Snapshot. OK.
Riskanter Fall: Datadir aus Borg, aber Secret-Datei aus einer anderen
(neueren oder aelteren) Quelle. Mongo akzeptiert den Login nicht, Komodo
laeuft nicht. Lockout. Doku erwaehnt diesen Pin-Punkt nicht.
Vorschlag: Hinweis in `DISASTER_RECOVERY.md` Phase 4 Stufe 3: "Mongo-
Datadir und `komodo_mongo_password.txt` muessen aus demselben Snapshot
kommen. Bei Mismatch: leeren Datadir und Re-Init, dann Daten aus
`komodo-mongo.archive.gz` per `mongorestore`."
### P4-7 (MED) - Hardgecodete LAN-IP in `extra_hosts`
`ops/komodo/docker-compose.yml:50` und `:101` haben:
`"git.kaleschke.info:192.168.178.58"`.
Bare-Metal-Recovery auf anderer Hardware oder veraenderter LAN-IP fuehrt
zu stummem Fehler: Komodo-Core kann Gitea nicht ueber den Override
erreichen, faellt auf AdGuard-DNS zurueck (wenn der schon laeuft) oder
scheitert.
Vorschlag: kurzer Hinweis in `DISASTER_RECOVERY.md` Phase 4 Stufe 3: "Bei
geaenderter Host-LAN-IP `extra_hosts`-Werte in `ops/komodo/docker-compose.
yml` vor `compose up` anpassen oder ueber `.env` parametrisieren."
### P4-8 (HIGH) - Stack-ENV-Wiederherstellung praktisch manuell
`docs/DISASTER_RECOVERY.md:188-195` sagt: "Wenn `komodo-mongo.archive.gz`
frisch ist, koennen die Werte beim Komodo-Restart aus dem Dump
zurueckgespielt werden, ohne dass jemand sie sieht."
`docs/RESTORE_HANDBOOK.md:73-74` und `docs/AUDIT_2026-05-25_TODO.md:20`
machen den Daten-Mongo-Restore als "erledigt 2026-06-03" sichtbar - aber
NICHT als Teil des DR-Bootstraps. Komodo-Bootstrap im Trockenlauf benutzt
Wegwerf-Werte.
Praktisch heisst das: Im DR-Bootstrap (Phase 4 Stufe 3) startet Komodo
**ohne** den Mongo-Daten-Restore. Die `KOMODO_*` kommen aus externer
Notiz. Aber die Stack-ENVs fuer `paperless`/`immich`/`mail-archiver`/
`speedtest` (PAPERLESS_DBPASS etc.) **muessen vor Stufe 4** wieder in
Komodo eingetragen sein. Wenn der Mongo-Daten-Restore nicht direkt nach
Komodo-Start passiert, gehen diese Werte manuell in die Komodo-UI.
Vorschlag: Klarstellung in `DISASTER_RECOVERY.md` Phase 4 zwischen Stufe
3 und Stufe 4: "Optionaler Mongo-Daten-Restore aus `komodo-mongo.archive.
gz` per `ops/restore-tests/komodo-mongo-restore-test.sh`-Muster - dann
sind alle Stack-ENVs zurueck. Alternativ: Stack-ENVs manuell in Komodo-
UI eintragen, Quelle Vaultwarden (sobald Stufe 4 Vaultwarden laeuft -
Henne-Ei mit Paperless: Paperless-Start dann erst nach Vaultwarden, nicht
parallel)."
## Phase 5 - Verifikation
### P5-1 (LOW) - Smoke-Tests in DR.md weniger streng als Matrix
`docs/DISASTER_RECOVERY.md:337-345` Phase 5.3 sagt z. B. "Vaultwarden
startet und ist erreichbar". `docs/RESTORE_MATRIX.md:39` sagt: "Login-
Seite erreichbar, Tresor-Daten sichtbar". Das zweite ist faktisch der
echte Smoke-Test.
Geschmackssache, kein Bug. Empfehlung: DR.md auf die Matrix-Smokes
verweisen statt eigene Kurzversion.
### P5-2 (MED) - Kein Verifikationspunkt App-zu-DB-Verbindung
`docs/DISASTER_RECOVERY.md:337-345` prueft App-Start, nicht DB-Auth-
Erfolg. Bei falschem `PAPERLESS_DBPASS`-Stack-ENV startet Paperless
moeglicherweise mit Error-Log und ist via Traefik nicht antwortend - aber
das fehlt als Pruefpunkt.
Vorschlag: Phase 5.3 ergaenzen: "Pro App: `docker logs <app>` zeigt keine
`password authentication failed`/`FATAL: role does not exist`-Eintraege."
## Uebergreifende Findings
### X-1 (HIGH) - Nextcloud-Restore-Skript existiert, ist aber ungetestet
`ops/restore-tests/nextcloud-restore-test.sh` und
`ops/restore-tests/nextcloud-compose.test.yml` existieren im Repo.
`docs/RESTORE_MATRIX.md:147` Spalte "Letzter Restore-Test" fuer Nextcloud:
`-`, naechster Lauf `**hoechste Prio**`. `docs/AUDIT_2026-05-25_TODO.md:18`
fuehrt es als P1 "offen".
Damit ist der echte Tabletop-Gewinn: der Test ist nicht "noch zu bauen",
sondern "noch nie ausgefuehrt". Ein `bash /mnt/user/services/homelab-
infra/ops/restore-tests/nextcloud-restore-test.sh` schliesst die letzte
Tier-2-Luecke.
## Nicht-Findings
Was ich gepruft und als sauber verifiziert habe:
- Referenzierte Skripte existieren alle: `pre-backup-dumps.sh`,
`gitea-bundle-mirror.sh`, `run-restore-checks.sh`,
`komodo-bootstrap-test.sh`, `posture-check.sh`, alle Restore-Test-
Skripte fuer Tier-1 und Tier-2.
- Pfadverweise zwischen DR.md, RESTORE_MATRIX.md, SECRETS_MAP.md,
SERVICES_RECOVERY.md sind konsistent (Borg-Dumps unter `/mnt/user/
backups/borg/dumps/latest`, Secrets unter `/mnt/user/appdata/secrets`).
- Drift-Erkennung Authelia (`services/authelia-diff.sh`) ist in
`posture-check` integriert (`WORKFLOW.md:292`).
- GitHub-Mirror-Pfad und Gitea-Bundle-Mirror als Repo-Bootstrap-Quellen
sind dreifach abgesichert (lokaler Clone, GitHub, Bundle).
- Tier-1-Postgres-Restore-Drill ist 2026-06-03 erfolgreich gelaufen
(`AUDIT_2026-05-25_TODO.md:19`).
- `ops/komodo/docker-compose.yml` ist als Recovery-Anker getestet
(`SERVICES_RECOVERY.md:142-166`).
- Borg-Passphrase und Hetzner-Account-Hygiene sind Operator-bestaetigt
(`AUDIT_2026-05-25_TODO.md:46-47`).
## Vorschlag fuer Reihenfolge der Folge-Arbeit
1. **CRITICAL P1-1 zuerst** - Operator-Laptop-Voraussetzung als
DR-Pflichtposten dokumentieren. Eine Dokuzeile.
2. **HIGH P0-2 + P3-3** - klaeren, ob GitHub-Mirror lesend public ist und
wo der Hetzner-Maintenance-Key offline liegt. Zwei Dokuzeilen oder
eine echte Setup-Entscheidung.
3. **HIGH P2-1** - Operator-Bestaetigung "KOMODO_*-Notiz offline
gesichert YYYY-MM-DD" in `EXTERNAL_DEPENDENCIES.md` ergaenzen (sobald
real angelegt).
4. **HIGH P4-1 + P4-2** - Vorlauf "Stufe 0 - Docker-Grundlage" und
LE-Staging-Hinweis in DR.md Phase 4 einfuegen. Etwa 10 Zeilen Doku.
5. **HIGH X-1** - `nextcloud-restore-test.sh` einmal scharf ausfuehren.
Vermutlich ein Vormittag inklusive Report-Review.
6. **HIGH P2-2 + P4-8** - Reihenfolgen-Konsistenz Komodo/Vaultwarden in
DR.md eindeutig aufloesen.
7. Rest in der Reihenfolge der Tabelle.
Punkte 1-4 sind reine Doku-Arbeit, keine Compose-/Runtime-Aenderung.
Punkt 5 ist ein echter Restore-Lauf mit Report. Punkt 6 ist die
substanziellste Doku-Aenderung in DR.md.
## Folge-Iteration 2026-06-03 (Doku-Fixes im selben Aenderungsblock)
Direkt nach dem Drill und nach Operator-Antworten auf vier offene Fragen wurden folgende Findings im Repo adressiert. Operator-Aufgaben, die ich nicht selbst tun kann, sind als P1 in `docs/AUDIT_2026-05-25_TODO.md` aufgenommen.
| ID | Massnahme |
|---|---|
| P0-1 | DR.md Phase 0 ergaenzt um "Operativer Pfad fuer den Repo auf den frisch installierten Unraid-Host" (USB/SMB/rsync); DR.md Abschnitt 3 mit Zeile "Operator-DR-Workstation"; `EXTERNAL_DEPENDENCIES.md` neuer Abschnitt "DR-Workstation Bare-Metal-Kit" |
| P0-2 | `EXTERNAL_DEPENDENCIES.md` GitHub-Mirror-Zeile praezisiert (privat, Read-PAT/Deploy-Key Pflicht); DR.md Phase 0 verweist explizit darauf; offene Operator-Aufgabe in Audit-Restliste |
| P1-1 | Operator-DR-Workstation als Voraussetzung in DR.md Abschnitt 3 und in `EXTERNAL_DEPENDENCIES.md`; konkrete Pflichtbestandteile (WSL2, Borg, SSH-Key) gelistet |
| P1-2 | Bleibt offen als P3-Test in Restore-Backlog (kein Doku-Fix moeglich) |
| P2-1 | KOMODO_*-Notiz als kritische Secret-Zeile in `EXTERNAL_DEPENDENCIES.md` mit Status "noch nicht angelegt"; Operator-Aufgabe in Audit-Restliste |
| P2-2 | DR.md Phase 4 Stufe 3 ergaenzt um expliziten Hinweis "KOMODO_* aus externer Notiz oder voraus gezogener Vaultwarden" |
| P2-3 | DR.md Abschnitt 6.1 um `homelab_smtp_password.txt` erweitert |
| P2-4 | DR.md Abschnitt 6.1 um `n8n_encryption_key.txt` erweitert |
| P2-5 | DR.md Abschnitt 6.1 um Monitoring-Grafana/InfluxDB-/Filebrowser-Secrets erweitert |
| P3-1 | DR.md neuer Abschnitt 7.3 "Borg-Extract ohne `borg-ui`-Container" mit DR-Workstation- und Docker-Variante |
| P3-2 | DR.md Abschnitt 7.3 nennt Passphrase-Eingabe explizit als interaktiven Bootstrap-Schritt |
| P3-3 | `EXTERNAL_DEPENDENCIES.md` Review-Zeile 2026-06-03: Hetzner-Maintenance-Key auch offline bestaetigt |
| P4-1 | DR.md Phase 4 neue Stufe 0 "Docker-Grundlage" mit `docker network create` Befehlen |
| P4-2 | DR.md Phase 4 Stufe 1 LE-Staging-Hinweis bei verlorenem `acme.json` |
| P4-3 | DR.md Phase 4 Stufe 0 nennt `traefik/dynamic/*` als Pre-Check |
| P4-4 | Wird mit fresh-Postgres-Initialisierungsskripten ohne Doku-Aenderung nicht sinnvoll abgedeckt; bleibt als Doku-Hinweis offen, ist im realen Restore-Pfad mit `pg_dumpall --globals-only` abgedeckt |
| P4-5 | LOW, nicht angepasst (Reihenfolge nicht falsch, nur irrefuehrend) |
| P4-6 | DR.md Phase 4 Stufe 3 "Wichtige Stolperfallen": Mongo-Datadir/Secret-Mismatch und Re-Init-Pfad |
| P4-7 | DR.md Phase 4 Stufe 3 "Wichtige Stolperfallen": `extra_hosts`-Anpassung bei IP-Wechsel |
| P4-8 | DR.md Phase 4 Stufe 3 "Wichtige Stolperfallen": Stack-ENV-Wiederherstellung per `mongorestore` oder manuell |
| P5-1 | LOW, nicht angepasst |
| P5-2 | DR.md Phase 5.3 um `docker logs`-Verifikation der App-zu-DB-Verbindung erweitert |
| X-1 | **erledigt 2026-06-03**: Nextcloud-Restore-Test scharf gelaufen, drei Iterationen (zwei Skript-Bugs gefixt), Endresultat SUCCESS mit HTTP 200, occ status ok, 126 DB-Tabellen. Damit ist Tier-2 vollstaendig belegt. |
Nicht angefasst: P1-2 (kein Doku-Fix moeglich), P4-4 (im echten Restore-Pfad ohnehin abgedeckt), P4-5 und P5-1 (LOW). Die offenen Operator-Aufgaben (KOMODO_*-Notiz, Read-PAT, DR-Workstation, Nextcloud-Restore) stehen jetzt in `docs/AUDIT_2026-05-25_TODO.md` als P1.
## Reproduktion dieses Drills
```text
Methode: kalter Lesetest gegen
- docs/DISASTER_RECOVERY.md
- docs/RESTORE_MATRIX.md
- docs/SECRETS_MAP.md
- docs/SERVICES_RECOVERY.md
- docs/RESTORE_HANDBOOK.md
- docs/EXTERNAL_DEPENDENCIES.md
- ops/komodo/docker-compose.yml
- traefik/docker-compose.yml
Verifizierte Skript-Existenz: ops/borg-ui/scripts/*, ops/restore-tests/*,
services/posture-check/*
Kein Container gestartet, kein Skript ausgefuehrt, keine produktiven
Pfade beruehrt.
```
docs/DR_WORKSTATION_SETUP.md
-227
View File
@@ -1,227 +0,0 @@
# DR-Workstation Setup-Runbook
Stand: 2026-06-03
Konkrete Schritte, um den Operator-Gaming-PC als DR-Workstation einzurichten. Der Endzustand ist in `docs/EXTERNAL_DEPENDENCIES.md` Abschnitt "DR-Workstation Bare-Metal-Kit" beschrieben; dieses Dokument ist der Weg dahin.
Vorbedingung: Repo-Clone unter `G:\Gitea_Clone\homelab-infra`, Hetzner-DR-SSH-Key und GitHub-Deploy-Key liegen offline auf USB.
Aufwand: einmalig ~30-60 Min interaktiv.
---
## Schritt 1 - WSL2 + Ubuntu installieren (~15 Min)
PowerShell als **Administrator** oeffnen:
```powershell
wsl --install -d Ubuntu
```
- Bei "Virtualization nicht aktiviert"-Fehler: BIOS rein, Intel VT-x / AMD-V einschalten, neu starten, Befehl wiederholen.
- Nach Install: Ubuntu startet automatisch und fragt nach Username + Passwort. Username egal (z. B. `dr`), Passwort merken (wird fuer `sudo` gebraucht).
- Reboot kann noetig sein - PowerShell sagt es.
Verifikation in Ubuntu (oeffnet sich automatisch):
```bash
lsb_release -a
uname -r
```
Erwartet: `Ubuntu 24.04 LTS`, Kernel beginnt mit `5.x` oder `6.x` und enthaelt `microsoft-standard-WSL2`.
---
## Schritt 2 - Borg-Client installieren (~3 Min)
In der Ubuntu-Shell:
```bash
sudo apt update
sudo apt install -y borgbackup openssh-client
borg --version
```
Erwartet: `borg 1.2.x` oder `1.4.x`. Beides reicht fuer das produktive Borg-Repo auf Hetzner.
---
## Schritt 3 - Hetzner-DR-SSH-Key in WSL ablegen (~5 Min)
Wichtig: der Private-Key liegt offline auf USB. Fuer die Workstation-Routine wird er auf das WSL-Filesystem kopiert - **das ist die Arbeitskopie**, nicht die Offline-Sicherung. Wenn die WSL kaputtgeht, kommt der Key zurueck vom USB; das Offline-Original bleibt unangetastet.
USB einstecken. In WSL kopieren (Pfad anpassen je nach Laufwerksbuchstabe):
```bash
mkdir -p ~/.ssh
cp /mnt/<USB-Buchstabe>/dr-hetzner-2026-06-03/dr-hetzner ~/.ssh/dr-hetzner
chmod 600 ~/.ssh/dr-hetzner
```
`<USB-Buchstabe>` ist meistens `e`, `f` oder `g` - Windows-Laufwerke werden in WSL unter `/mnt/<buchstabe>` gemountet.
Smoke-Test:
```bash
ssh -i ~/.ssh/dr-hetzner -o IdentitiesOnly=yes -p 23 \
u565255@u565255.your-storagebox.de "ls"
```
Erwartet: vier Verzeichnisse (`backup`, `backup2`, `hetzner_borg_appdata`, `hetzner_borg_appdata_critical`), exit 0, kein Passwort-Prompt.
---
## Schritt 4 - Borg-Passphrase eingeben und `borg list` testen (~5 Min)
Borg verlangt die Passphrase beim ersten Repo-Zugriff. Die liegt offline gesichert (Operator-Bestaetigung 2026-05-26).
Einmaliger Smoke gegen das wichtige Repo:
```bash
export BORG_RSH="ssh -i ~/.ssh/dr-hetzner -o IdentitiesOnly=yes -p 23"
borg list ssh://u565255@u565255.your-storagebox.de/./hetzner_borg_appdata_critical
```
Borg fragt nach der Passphrase. Eingeben (sie wird nicht angezeigt, das ist normal).
Erwartet: Liste mit Archiv-Namen, jeder im Stil `Taegliche-Sicherung-YYYY-MM-DDTHH:MM:SS.xxx`. Wenn ja: Borg-Schicht funktioniert.
**Wert wird nirgendwo gespeichert.** `BORG_PASSPHRASE`-Env-Variable wird **nicht** dauerhaft gesetzt; Passphrase wird im Notfall immer interaktiv eingegeben.
---
## Schritt 5 - GitHub-Deploy-Key in WSL ablegen (~3 Min)
Gleiches Muster wie Hetzner-Key:
```bash
cp /mnt/<USB-Buchstabe>/dr-readonly-2026-06-03/dr-readonly ~/.ssh/dr-readonly
chmod 600 ~/.ssh/dr-readonly
```
Smoke-Test gegen den privaten GitHub-Mirror:
```bash
GIT_SSH_COMMAND="ssh -i ~/.ssh/dr-readonly -o IdentitiesOnly=yes" \
git ls-remote git@github.com:michaelkaleschke-spec/homelab-infra.git | head -3
```
Erwartet: HEAD und mindestens ein `refs/heads/master`-Eintrag.
---
## Schritt 6 - Quartals-Smoke als Skript ablegen (~5 Min)
Damit der "ich pruefe das vierteljaehrlich"-Schritt zur Routine wird, ein kleines Skript ins WSL-Home:
Stand 2026-06-06: Das Skript liegt zusaetzlich versioniert unter
`ops/maintenance/dr-workstation-smoke.sh` und wurde auf `baerchen` bereits nach
`~/dr-smoke.sh` in die Ubuntu-WSL kopiert. Borg 1.2.8 ist installiert, die
DR-Key-Arbeitskopien liegen unter `~/.ssh/dr-readonly` und
`~/.ssh/dr-hetzner`, GitHub-Read-Smoke und Hetzner-SSH-Smoke sind erfolgreich.
Der finale Borg-Smoke via `bash ~/dr-smoke.sh` wurde am 2026-06-06 ebenfalls
erfolgreich gefahren (`DR-Smoke OK (2026-06-06 10:05:30)`). Die Borg-Passphrase
wurde nur interaktiv eingegeben und nicht gespeichert.
```bash
cat > ~/dr-smoke.sh <<'EOF'
#!/bin/bash
# DR-Workstation Quartals-Smoke
# Pruefen: GitHub-Read, Hetzner-SSH, Borg-Repo-Erreichbarkeit
# Passphrase wird interaktiv abgefragt - Skript speichert keinen Wert.
set -e
echo "=== GitHub Deploy-Key ==="
GIT_SSH_COMMAND="ssh -i ~/.ssh/dr-readonly -o IdentitiesOnly=yes" \
git ls-remote git@github.com:michaelkaleschke-spec/homelab-infra.git \
| head -1
echo
echo "=== Hetzner SSH-Login ==="
ssh -i ~/.ssh/dr-hetzner -o IdentitiesOnly=yes -p 23 \
u565255@u565255.your-storagebox.de "ls" | head -5
echo
echo "=== Borg-Repo (Passphrase wird abgefragt) ==="
export BORG_RSH="ssh -i ~/.ssh/dr-hetzner -o IdentitiesOnly=yes -p 23"
borg info ssh://u565255@u565255.your-storagebox.de/./hetzner_borg_appdata_critical | head -10
echo
echo "DR-Smoke OK ($(date '+%F %T'))"
EOF
chmod +x ~/dr-smoke.sh
```
Aufrufen mit:
```bash
bash ~/dr-smoke.sh
```
Termin im Kalender: einmal pro Quartal, ~5 Min Aufwand.
---
## Schritt 7 - Eintrag in EXTERNAL_DEPENDENCIES Review nachziehen
Nach erfolgreicher Einrichtung im Repo dokumentieren. In `docs/EXTERNAL_DEPENDENCIES.md` unter "Review":
```
| 2026-06-XX | DR-Workstation produktiv: WSL2 Ubuntu auf Gaming-PC, borgbackup installiert, Hetzner-DR-Key und GitHub-Deploy-Key in ~/.ssh, Quartals-Smoke-Skript ~/dr-smoke.sh. Bare-Metal-DR-Pillars sind damit alle vier produktionsreif. | Quartalsweise Smoke laufen lassen |
```
Audit-Restliste analog: in `docs/AUDIT_2026-05-25_TODO.md` den P1 "DR-Workstation Bare-Metal-Kit: WSL2 + Borg-Client installieren" auf erledigt setzen und unter "Zuletzt geschlossen" einen Eintrag mit Smoke-Ergebnis machen.
Wenn ich (Claude) am Tag der Einrichtung mit SSH-Zugang dabei bin, ziehe ich das nach. Sonst per `git add docs/EXTERNAL_DEPENDENCIES.md docs/AUDIT_2026-05-25_TODO.md && git commit && git push`.
---
## Troubleshooting
### `wsl --install` schlaegt fehl mit "WSL 2 requires an update"
```powershell
wsl --update
wsl --shutdown
wsl --install -d Ubuntu
```
### Hetzner-SSH fragt nach Passwort statt Key-Login zu akzeptieren
Permissions des Keys pruefen:
```bash
ls -la ~/.ssh/dr-hetzner
```
Muss `-rw-------` (also `600`) sein. Wenn anders:
```bash
chmod 600 ~/.ssh/dr-hetzner
```
Bei weiterhin Passwort-Prompt: Pubkey-Inhalt gegen das authorized_keys-Format der Storage Box pruefen (sollte `ssh-ed25519 AAAA...` ohne Leerzeilen sein).
### `borg list` haengt oder schlaegt mit "Connection refused" fehl
Port 23 explizit pruefen:
```bash
nc -vz u565255.your-storagebox.de 23
```
Wenn das fehlschlaegt: Hetzner-Status-Page pruefen, sonst SSH-Verbindung an sich blockiert (Firewall, ISP).
### GitHub-Pull fragt nach Username/Passwort
Stelle sicher dass die URL `git@github.com:...` ist (SSH), nicht `https://github.com/...`. Bei HTTPS wuerde GitHub Username/PAT verlangen, was wir bewusst nicht eingerichtet haben.
---
## Was nach diesem Runbook gilt
Mit allen Schritten erledigt ist der vierte Bare-Metal-DR-Pillar zu (siehe `docs/EXTERNAL_DEPENDENCIES.md`). Der DR-Workstation-Status ist dann:
- WSL2 Ubuntu installiert
- borgbackup einsatzbereit
- SSH-Keys (Hetzner, GitHub) in `~/.ssh/`
- Quartals-Smoke-Skript laeuft
Damit ist im Bare-Metal-Fall der Pfad "Unraid tot -> Gaming-PC nimmt die DR-Arbeit auf" tatsaechlich gangbar, nicht nur in Doku theoretisch.
docs/EXTERNAL_DEPENDENCIES.md
+2 -27
View File
@@ -15,15 +15,14 @@ Dieses Dokument beschreibt externe Anbieter und Konten, von denen Betrieb, Recov
| Domain-Registrar | Besitz `kaleschke.info` | hoch | Ohne Domain brechen Public URLs/TLS-Erneuerung | Operator-Konto ausserhalb Repo, konkreten Registrar im Account pruefen | Registrar-Zugang, 2FA-Recovery und Zahlungsweg analog/off-system sichern |
| Cloudflare DNS | Authoritative DNS, ACME DNS-Challenge, DDNS | hoch | Neue Zertifikate/DNS-Aenderungen blockiert | Cloudflare-Konto; API-Token liegt als Host-Secret | API-Token rotierbar halten, Account-Recovery und Zone-Besitz pruefen |
| Hetzner Storage Box | Off-site Borg Backup | kritisch | Restore aus Off-site ggf. nicht moeglich | Hetzner-Konto / Storage-Box-Zugang ausserhalb Repo | Borg-Passphrase ist offline gesichert; Hetzner 2FA/Recovery/Zahlung sind bestaetigt; Storage Box ist SSH-only, Maintenance-Key liegt in Vaultwarden; Borg `append-only` wird per Operator-Entscheidung nicht umgesetzt |
| GitHub Mirror | Externer Repo-Mirror `michaelkaleschke-spec/homelab-infra` (privat) | mittel/hoch | Gitea-Verlust abfederbar, aber Bare-Metal-Bootstrap braucht Read-Zugang (PAT oder SSH-Deploy-Key); ohne diesen ist der Mirror im DR nicht klonbar | GitHub-Konto; Push-PAT liegt in Gitea-Mirror-Settings; **Read-PAT/Deploy-Key fuer DR muss zusaetzlich offline im DR-Kit liegen** | Mirror-Status regelmaessig pruefen; lokalen Clone als zweite Kopie behalten; Read-PAT mit Scope `repo:read` separat erzeugen und im DR-Kit ablegen |
| GitHub Mirror | Externer Repo-Mirror `michaelkaleschke-spec/homelab-infra` | mittel/hoch | Gitea-Verlust abfederbar, Repo-Bootstrap bleibt moeglich | GitHub-Konto; PAT liegt in Gitea-Mirror-Settings, nicht im Repo | Mirror-Status regelmaessig pruefen; lokalen Clone als zweite Kopie behalten |
| Tailscale | Remote-/Operator-Zugang | hoch | Remote-Zugriff erschwert, lokale Bedienung bleibt | Tailnet-Konto; Node `Kallilabcore`, IPv4 `100.80.98.33` | Break-glass per LAN und physischem Zugriff; Tailnet-Recovery-Codes sichern |
| GMX SMTP | Authelia Notifier, Vaultwarden-Einladungen, Ops-Report-Mail | mittel | Mail-Notifier und Vaultwarden-Einladungen fallen aus; Login selbst nicht zwingend | GMX-Konto; SMTP-Secrets liegen hostseitig | ntfy/zweiter SMTP als Fallback pruefen |
| OpenAI API | Paperless-GPT LLM und Vision-OCR | mittel | Automatische Dokument-Titel, Tags, Korrespondenten und LLM-OCR fallen aus; Paperless selbst laeuft weiter | OpenAI-Projekt/API-Key ausserhalb Repo | Key in Vaultwarden/Komodo sichern, bei Offenlegung rotieren; Kosten/Usage im OpenAI-Projekt beobachten |
| Let's Encrypt | TLS-Zertifikate | hoch | Cert-Erneuerung faellt aus | automatisch via Traefik und Cloudflare DNS-Challenge | Cert-Expiry Alert einrichten; Cloudflare-Token und Traefik-Storage pruefen |
| Container Registries | Image Pulls von Docker Hub, GHCR, LSCR, Gitea Registry u. a. | mittel | Redeploy/Update blockiert | ueberwiegend oeffentlich; keine produktiven Registry-Tokens im Repo | Gepinnte Digests und lokale Runtime helfen kurzfristig; Updates geplant und einzeln deployen |
| Plex Konto | Plex native Auth, Claim und Client-Zugriff ueber `plex.kaleschke.info` | mittel | Plex-Web/App-Login und Clients koennen ausfallen; LAN-Medienpfade bleiben lokal | Plex-Konto ausserhalb Repo; `PLEX_CLAIM` nur fuer Setup | Plex Remote Access bleibt aus; externer Zugriff laeuft ueber Traefik/443. Konto-Recovery separat sichern |
| Plex Konto/Remote Access | Plex native Auth, ggf. Remote Access und Claim | mittel | Plex-Clients/Remote-Funktionen koennen ausfallen | Plex-Konto ausserhalb Repo; `PLEX_CLAIM` nur fuer Setup | LAN-Medienpfade bleiben lokal; Konto-Recovery separat sichern |
| Mobile Push | ntfy und ggf. mobile Plattform-Pushes | niedrig/mittel | Alerts erreichen Mobilgeraete ggf. nicht | App-/Device-seitig | Kritische Alerts zusaetzlich in Grafana/Glance sichtbar halten |
| Operator-DR-Workstation | Bare-Metal-Recovery-Arbeitsplatz (Gaming-PC Windows, lokaler Repo-Clone `G:\Gitea_Clone\homelab-infra`) | kritisch | Ohne Workstation kein Borg-Extract, kein Hetzner-Zugriff, kein Repo-Bootstrap; der Unraid-Host ist im Bare-Metal-Fall gerade weg | Operator-PC, WSL2 + Borg-Client, SSH-Key fuer Hetzner Storage Box, Offline-Kopie der Borg-Passphrase | Setup als bewusste DR-Vorbedingung pflegen (siehe Abschnitt "DR-Workstation Bare-Metal-Kit") |
## Kritische Secrets ausserhalb des Repos
@@ -39,24 +38,6 @@ Authoritativ ist `docs/SECRETS_MAP.md`. Diese Liste markiert nur externe Abhaeng
| Domain-Registrar Recovery | Domain-Besitz und Zahlung | Account, 2FA und Zahlungsweg ausserhalb des Homelabs sichern |
| Hetzner Storage Box Zugang | Off-site Backup-Ziel | Account 2FA aktiv, Recovery Key offline gedruckt, Zahlungsweg ok; Maintenance-Key und Storage-Box-Passwort in Vaultwarden |
| OpenAI API Key | Paperless-GPT GPT-Zugriff | Als Stack ENV / Vaultwarden-Eintrag sichern; bei Verdacht auf Leak rotieren |
| KOMODO_* Stack-ENV-Notiz | Offline-Sicherung der 5 Komodo-Werte (`KOMODO_SECRET_KEY`, `KOMODO_WEBHOOK_SECRET`, `KOMODO_JWT_SECRET`, `KOMODO_MONGO_PASSWORD`, `KOMODO_PERIPHERY_PASSKEY`) | **Status 2026-06-03: offline gesichert (Operator-Bestaetigung)**. Quelle der Werte ist die host-seitige Self-Stack-`.env` (`/mnt/user/services/stacks/komodo/.env`) bzw. die Drift-Recovery-Kopie unter `/mnt/user/appdata/secrets/_komodo_stack_env_recovery_2026-05-04.env`. Nicht im Repo, nicht in ntfy, nicht in Logs |
| GitHub-Mirror Read-Only Deploy-Key | DR-Read-Zugang zum privaten Mirror `michaelkaleschke-spec/homelab-infra` | **Status 2026-06-03: offline gesichert (Operator-Bestaetigung).** SSH-Deploy-Key `dr-readonly-2026-06-03` (ed25519, Passphrase-frei), Title in GitHub Repo Settings -> Deploy Keys: `DR Read-Only 2026-06-03`, Write-Access bewusst deaktiviert. Private Key liegt offline neben der KOMODO_*-Notiz. Smoke `git ls-remote` am 2026-06-03 erfolgreich. |
## DR-Workstation Bare-Metal-Kit
Der Operator-Gaming-PC ist im Bare-Metal-Fall die einzige Stelle, von der aus Recovery starten kann. Folgende Bestandteile gehoeren zum minimalen DR-Kit auf diesem Rechner:
| Bestandteil | Zweck | Pruefen |
|---|---|---|
| Repo-Clone `G:\Gitea_Clone\homelab-infra` (master, gefetcht) | Recovery-Anker fuer `ops/komodo/docker-compose.yml`, Restore-Skripte | `git -C G:\Gitea_Clone\homelab-infra log --oneline -1` plausibel aktuell |
| Read-Zugang zum privaten GitHub-Mirror | Fallback, falls lokaler Clone defekt | SSH-Deploy-Key `dr-readonly-2026-06-03` (ed25519, Passphrase-frei) offline im DR-Kit, ein Test-Clone pro Quartal mit `GIT_SSH_COMMAND="ssh -i <pfad-zum-key> -o IdentitiesOnly=yes" git ls-remote git@github.com:michaelkaleschke-spec/homelab-infra.git` |
| WSL2 mit Borg-Client (`apt install borgbackup`) | Borg-Extract von Hetzner Storage Box ohne laufenden Unraid-Host | `borg --version` antwortet; ein `borg list` gegen Hetzner-Repo laeuft |
| SSH-Key fuer Hetzner Storage Box | Login auf `u565255.your-storagebox.de:23` | **Status 2026-06-03: ed25519-DR-Key `dr-hetzner-2026-06-03` offline gesichert.** Pubkey via `install-ssh-key` auf der Storage Box autorisiert, passwortloser Login erfolgreich, `ls` zeigt vier Borg-Repos (`backup`, `backup2`, `hetzner_borg_appdata`, `hetzner_borg_appdata_critical`). Private Key liegt offline neben KOMODO_*-Notiz und GitHub-Deploy-Key |
| Offline-Kopie Borg-Passphrase | Entschluesselung des Borg-Repos | Operator-Bestaetigung 2026-05-26; bei Reviews nur Auffindbarkeit pruefen |
| Offline-Kopie KOMODO_* Stack-ENV | Komodo-Bootstrap ohne Vaultwarden | **Status 2026-06-03: offline gesichert (Operator-Bestaetigung)** |
| Vaultwarden Master-Passwort offline | Zugriff auf Vaultwarden-Export im DR | Operator-Wissen, ggf. analog gesichert |
Operative Regel: Die DR-Workstation wird nicht als Test-/Spiel-PC betrachtet. WSL und das DR-Kit duerfen nicht unbemerkt unbrauchbar werden. Quartalsweise minimaler Trockenlauf: `borg list <hetzner-repo>` muss antworten und der Repo-Clone muss fetchbar bleiben.
## Ausfall-Szenarien
@@ -102,9 +83,3 @@ Operative Regel: Die DR-Workstation wird nicht als Test-/Spiel-PC betrachtet. WS
| 2026-06-01 | Externer Betreibercheck vorbereitet: `docs/EXTERNAL_OPERATOR_RUNBOOK.md` und `ops/maintenance/check-external-operator.sh`; FRITZ!Box meldet per TR-064 FRITZ!OS `154.08.25`, Public DNS hat keine AAAA-Records, Host hat keine globale Provider-IPv6 | Account-Hygiene am 2026-06-01 nachgezogen |
| 2026-06-01 | FRITZ!Box-UI gegengeprueft und Konfig-Backup extern/off-system in Vaultwarden abgelegt; Remote-HTTPS auf FRITZ!Box-UI aus, FTP/FTPS auf Speichermedien aus, nur `443/tcp -> 192.168.178.58`, keine aktive IPv6-Freigabe sichtbar, UPnP-Selbstfreigaben aus | Bei naechstem Router-Update erneut exportieren |
| 2026-06-01 | Hetzner-Account-Hygiene erledigt: externe Mail ok, Zahlung ok, 2FA aktiv, Recovery Key offline gedruckt. Storage Box: SSH aktiv, SMB/WebDAV aus, Maintenance-Key in Vaultwarden, Borg-Repo-Zugriff nach Recovery geprueft. Borg `append-only` wird bewusst nicht umgesetzt. | Keine Folgeaktion |
| 2026-06-03 | Hetzner Storage Box Maintenance-Key zusaetzlich offline gesichert bestaetigt (Operator-Antwort im DR-Tabletop 2026-06-03). Damit ist der Hetzner-Zugang im Bare-Metal-Fall ohne Vaultwarden moeglich. | Keine Folgeaktion |
| 2026-06-03 | DR-Tabletop ergibt drei offene Bootstrap-Bloecke: KOMODO_*-Notiz nicht offline, GitHub-Mirror-Read-PAT/Deploy-Key nicht angelegt, DR-Workstation nicht als DR-Kit konfiguriert. Details in `docs/DR_DRILL_2026-06-03.md` und Folge-Tasks in `docs/AUDIT_2026-05-25_TODO.md`. | KOMODO_*-Notiz erzeugen, Read-PAT erzeugen, WSL2+Borg auf Gaming-PC einrichten |
| 2026-06-03 | KOMODO_*-Notiz offline gesichert (Operator-Bestaetigung im DR-Tabletop-Followup). Quelle bleibt host-seitige `.env` (`/mnt/user/services/stacks/komodo/.env`) bzw. Drift-Recovery-Kopie vom 2026-05-04. Bare-Metal-Komodo-Bootstrap ist damit ohne Vaultwarden moeglich. | Restliche P1-Operator-Aufgaben: GitHub-Read-PAT, DR-Workstation-Setup, Nextcloud-Restore-Test |
| 2026-06-03 | GitHub-Mirror Read-Only Deploy-Key `DR Read-Only 2026-06-03` (ed25519, Passphrase-frei) erzeugt, in GitHub Repo Settings ohne Write-Access hinterlegt, Smoke `git ls-remote` erfolgreich (`d947c7f` matched master HEAD), Private-Key offline neben KOMODO_*-Notiz abgelegt, Arbeitsplatz-Kopie geloescht. | Restliche P1-Operator-Aufgaben: DR-Workstation-Setup, Nextcloud-Restore-Test |
| 2026-06-03 | Hetzner Storage Box DR-SSH-Key `dr-hetzner-2026-06-03` (ed25519, Passphrase-frei) erzeugt, via `install-ssh-key` auf Storage Box `u565255.your-storagebox.de:23` autorisiert, passwortloser Login erfolgreich (Borg-Repos sichtbar), Private-Key offline neben KOMODO_*-Notiz und GitHub-Deploy-Key abgelegt, Arbeitsplatz-Kopie geloescht. Bare-Metal-Borg-Restore von der DR-Workstation ist damit moeglich, sobald WSL2 + Borg-Client installiert sind. | Restliche P1-Operator-Aufgaben: WSL2 + Borg-Client auf DR-Workstation installieren, Nextcloud-Restore-Test |
| 2026-06-06 | DR-Workstation produktiv: WSL2 Ubuntu 24.04 vorhanden, SSH/Git und Borg 1.2.8 in WSL vorhanden, DR-Key-Arbeitskopien unter `~/.ssh/dr-readonly` und `~/.ssh/dr-hetzner`, GitHub-Read-Smoke und Hetzner-SSH-Smoke erfolgreich, `ops/maintenance/dr-workstation-smoke.sh` nach `~/dr-smoke.sh` kopiert. Finaler Operator-Smoke erfolgreich: GitHub HEAD `3a263a4...`, Hetzner Storage Box Repos sichtbar, Borg-Repo `hetzner_borg_appdata_critical` gelesen, Repository ID `5dd9b949...`, encrypted `Yes (repokey)`, `DR-Smoke OK (2026-06-06 10:05:30)`. | Quartalsweise `bash ~/dr-smoke.sh`; Borg-Passphrase weiterhin nur interaktiv eingeben und nicht speichern |
docs/FAMILY_ONBOARDING.md
+13 -59
View File
@@ -25,7 +25,7 @@ Nachteile, ehrlich gesagt: Wenn der Server zuhause aus ist, sind die Apps weg, b
| **Vaultwarden** | Passwoerter sicher speichern und auf jedem Geraet nachschauen | Bitwarden-App (kostenlos), beim ersten Start Server-URL auf `vault.kaleschke.info` aendern lassen |
| **Mealie** | Rezepte sammeln, Wochenplan, Einkaufsliste | Web `mealie.kaleschke.info` oder Mealie-App |
| **Paperless** | Briefe und wichtige Dokumente scannen, durchsuchen, ablegen | Web `paperless.kaleschke.info`; Scan-Workflow erklaert Michi |
| **Plex** | Filme und Musik auf Fernseher, Handy und Tablet | Web `https://plex.kaleschke.info` oder Plex-App auf dem Geraet, mit Konto anmelden |
| **Plex** | Filme und Musik auf Fernseher, Handy und Tablet | Plex-App auf dem Geraet, mit Konto anmelden |
> Wenn du eine App auf dem Handy installierst und sie fragt nach einer Server-URL, ist das immer eine `...kaleschke.info`-Adresse. Wenn du dir nicht sicher bist, frag bevor du etwas eintippst.
@@ -193,66 +193,20 @@ Michi laesst es dich wissen, wenn ein Wartungsfenster geplant ist.
---
## Erster Onboarding-Termin - Ablauf fuer Michi
## Onboarding-Checkliste fuer Michi
Diese Sektion ist die konkrete Checkliste fuer den **ersten echten
Familien-Onboarding-Termin**. Sie ist als ein zusammenhaengender Termin von
ca. 30-45 Minuten pro Person gedacht. Keine Secret-Werte in diese Datei
schreiben.
Diese Punkte gehoeren in das erste echte Familien-Onboarding. Keine Secret-Werte
in diese Datei schreiben.
> Operator-Eingabe vor dem Termin: festlegen, **wer** beim ersten Termin dabei
> ist und **welche Geraete** real vorliegen. Die Checkliste funktioniert pro
> Person identisch.
### Vorher bereitlegen (Operator-Vorbereitung)
Diese Dinge muessen **vor** dem Termin fertig sein, sonst stockt der Ablauf:
- [ ] Pro Teilnehmer ist in **Vaultwarden** ein Benutzerkonto angelegt (Benutzername = Vorname klein).
- [ ] Pro Teilnehmer ist in **Immich** ein Benutzerkonto angelegt.
- [ ] Pro Teilnehmer ist in **Mealie** ein Benutzerkonto angelegt.
- [ ] Start-Passwoerter sind erzeugt und liegen so bereit, dass sie persoenlich uebergeben werden koennen (nicht per Chat, nicht in diese Datei).
- [ ] Die Apps `cloud`, `immich`, `vault`, `mealie` sind erreichbar (kurzer eigener Smoke-Test ueber `https://...kaleschke.info`).
- [ ] Das Familien-Handy/Geraet jedes Teilnehmers ist da, entsperrt und im **Haus-WLAN**.
- [ ] App-Store-/Play-Store-Login auf dem Geraet funktioniert (zum Installieren der Apps).
### Reihenfolge beim Termin (pro Person)
Die Reihenfolge ist bewusst gewaehlt: erst der Passwort-Speicher, dann das, was
am meisten bringt (Fotos), dann das Gemeinsame (Rezepte).
1. **Konto-Uebergabe**: Benutzername + Start-Passwort persoenlich uebergeben, Person aendert das Passwort beim ersten Login.
2. **Vaultwarden / Bitwarden** (Abschnitt "Vaultwarden zuerst"):
- Bitwarden-App installieren, Server-URL `https://vault.kaleschke.info` setzen, anmelden.
- Master-Passwort gemeinsam festlegen (wird **nicht** bei Michi gespeichert).
- Testeintrag "Test KalliLab" anlegen und wiederfinden.
3. **Immich** (Abschnitt "Foto-Backup vom Handy einrichten"):
- Immich-App installieren, Server `https://immich.kaleschke.info`, anmelden.
- Hintergrund-Backup nur ueber WLAN aktivieren, Kamera-Album auswaehlen.
- App offen lassen, bis erste Fotos hochgeladen sind; in der Weboberflaeche sichtbar pruefen.
4. **Mealie** (Abschnitt "Rezepte und Einkaufsliste einrichten"):
- `https://mealie.kaleschke.info` anmelden.
- Gemeinsam ein erstes echtes Rezept anlegen, kategorisieren, Zutaten auf die Einkaufsliste setzen.
- Einkaufsliste auf dem Handy oeffnen und einen Eintrag abhaken.
5. **Abschluss**: kurz zeigen, was bei Problemen zu tun ist (Abschnitt "Was tun, wenn etwas nicht geht"), besonders Passwort-vergessen und 2FA-verloren.
### Erfolgskriterium des ersten Termins
Der Termin gilt als erfolgreich, wenn pro Person **diese drei** Dinge real laufen:
- [ ] Vaultwarden ist eingerichtet und ein Testeintrag wurde gefunden.
- [ ] Immich sichert Handy-Fotos und die ersten Fotos sind in der Weboberflaeche sichtbar.
- [ ] In Mealie existiert ein erstes Rezept mit einer Einkaufslisten-Position.
### Bewusst spaeter (nicht im ersten Termin)
Damit der erste Termin nicht ueberladen wird, kommen diese Punkte bewusst erst
in einem Folgetermin:
- **Nextcloud** (Dateien/Kalender/Adressbuch) - erst wenn die drei Kern-Apps sitzen.
- **Paperless** (Dokumente scannen) - braucht eigenen Scan-Workflow, separater Termin.
- **Plex** (Filme/Musik) - reines Komfort-Thema, kein Onboarding-Kern.
- **App-uebergreifendes Einheits-Login (SSO/OIDC)** - nicht eingerichtet, nur als Idee notiert (siehe "Bewusst nicht versprochen").
| Status | Aufgabe |
|---|---|
| offen | Pro Familienmitglied Konto/Start-Passwort persoenlich uebergeben |
| offen | Vaultwarden/Bitwarden-App auf Handy einrichten |
| offen | Testeintrag in Vaultwarden anlegen |
| offen | Immich-App auf jedem Familien-Handy einrichten |
| offen | Immich-Backup mit ersten Fotos sichtbar pruefen |
| offen | Mealie mit erstem Rezept und Einkaufsliste praktisch ausprobieren |
| offen | Danach entscheiden, ob Nextcloud/Paperless/Plex direkt mitkommen oder spaeter |
## Bewusst nicht versprochen
docs/GUEST_IOT_NETWORK.md
-117
View File
@@ -1,117 +0,0 @@
# Guest / IoT Network Runbook
Stand: 2026-06-06
Dieses Runbook beschreibt den sicheren Weg, das FRITZ!Box-Gastnetz zu aktivieren,
ohne versehentlich Homelab-Admin-Ports aus dem Gastsegment erreichbar zu machen.
## Zielbild
- Normales LAN bleibt `192.168.178.0/24`.
- Kallilabcore bleibt im normalen LAN unter `192.168.178.58`.
- FRITZ!Box-Gast-WLAN darf Internetzugang haben, aber keinen Zugriff auf
`192.168.178.0/24`.
- Homelab-Admin-Pfade bleiben Operator-only:
- Tailscale fuer Admin-Zugriff
- Authelia/2FA fuer geschuetzte Web-UIs
- keine LAN-Admin-Ports aus dem Gastnetz
## Vorbedingungen
Vor dem Einschalten des Gast-WLANs muessen diese Preflights gruen sein:
```powershell
G:\Gitea_Clone\homelab-infra\ops\maintenance\check-guest-iot-isolation.ps1 -Mode LanPreflight
```
Erwartung im normalen LAN:
- `192.168.178.58:8082` ist blockiert (AdGuard Admin nur Tailscale).
- `192.168.178.58:8181` ist blockiert (InfluxDB nicht LAN-exponiert).
- `192.168.178.58:80`, `443`, `222` koennen im normalen LAN erreichbar sein.
Auf Unraid zusaetzlich:
```bash
/mnt/user/services/homelab-infra/ops/maintenance/check-guest-iot-preflight.sh
```
Validierung 2026-06-06: Host-Preflight erfolgreich, Report
`/mnt/user/backups/restore-reports/guest-iot-preflight-2026-06-06-131316.md`.
Ergebnis: FRITZ!Box 7590 per TR-064 erreichbar, `192.168.178.58:8082`
blockiert, `100.80.98.33:8082` erreichbar, `192.168.178.58:8181` blockiert.
Gast-WLAN-Smoke 2026-06-06: Operator hat ein iPhone mit `Fritzi Gastzugang`
verbunden und folgende Ziele getestet; alle waren aus dem Gast-WLAN nicht
erreichbar:
- `http://192.168.178.58:8082`
- `http://192.168.178.58:8181`
- `http://192.168.178.58:222`
- `https://192.168.178.58`
- `http://192.168.178.1`
Damit ist die Gastnetz-Isolation fuer die getesteten Homelab-/Router-Adminpfade
validiert.
## FRITZ!Box Schritte
In der FRITZ!Box UI:
1. `WLAN -> Gastzugang` oeffnen.
2. `Gastzugang aktiv` einschalten.
3. WPA2/WPA3-Verschluesselung aktiv lassen.
4. Eigenen Gast-SSID-Namen setzen, z. B. `Fritzi-Gast`.
5. Starkes Passwort setzen und in Vaultwarden ablegen.
6. Option `Geraete im Gastnetz duerfen miteinander kommunizieren` deaktiviert
lassen, sofern nicht bewusst gebraucht.
7. Option fuer Zugriff auf das Heimnetz / private Netzwerk deaktiviert lassen.
8. Gastzugang speichern.
Wichtig: Die genaue FRITZ!OS-8.25-UI-Beschriftung kann leicht variieren. Der
entscheidende Punkt ist: Gastgeraete duerfen keinen Zugriff auf das Heimnetz
haben.
## Verifikation
Ein Handy oder Laptop mit dem Gast-WLAN verbinden, dann auf diesem Geraet testen:
```powershell
G:\Gitea_Clone\homelab-infra\ops\maintenance\check-guest-iot-isolation.ps1 -Mode Guest
```
Erwartung aus dem Gast-WLAN:
- `192.168.178.58:80` blockiert
- `192.168.178.58:443` blockiert
- `192.168.178.58:222` blockiert
- `192.168.178.58:8082` blockiert
- `192.168.178.58:8181` blockiert
- `192.168.178.1:80` blockiert oder nur Gast-Gateway-Ansicht
Wenn der Test `Risk count: 0` meldet, ist die Isolation fuer die getesteten
Homelab-Admin-Pfade ausreichend.
## Betrieb
- Familien-/Gaestegeraete kommen ins Gast-WLAN, wenn sie keinen direkten Zugriff
auf LAN-Geraete brauchen.
- Homelab-Apps fuer Familie laufen perspektivisch ueber HTTPS/OIDC, nicht ueber
direkten LAN-Zugriff.
- Geraete, die lokale Discovery brauchen (z. B. manche Smart-TV/Plex-Szenarien),
bleiben im normalen LAN oder bekommen eine separate bewusste Entscheidung.
## Rollback
Wenn nach Aktivierung etwas Unerwartetes passiert:
1. FRITZ!Box: `WLAN -> Gastzugang` oeffnen.
2. Gastzugang deaktivieren.
3. Speichern.
4. Normalen LAN-Zugriff pruefen:
```powershell
G:\Gitea_Clone\homelab-infra\ops\maintenance\check-guest-iot-isolation.ps1 -Mode LanPreflight
```
Es werden durch dieses Runbook keine Docker-Stacks, Secrets oder produktiven
Appdaten veraendert.
docs/HARDWARE_INVENTORY.md
+8 -29
View File
@@ -3,20 +3,8 @@
Status: Hardware-Baseline erfasst; USV/Power-Loss ist als bewusst akzeptiertes Betreiber-Risiko dokumentiert.
Host: `Kallilabcore`
Letzte Pruefung: 2026-05-26
Doku-Stand Betreiberentscheidungen: 2026-06-05
Naechster Review: 2026-08-26
## Betreiber-Entscheidungen (Stand 2026-06-05)
Diese drei Punkte waren bisher diffuse TBDs und sind jetzt als bewusste
Entscheidungen festgehalten. Details in den jeweiligen Abschnitten unten.
| Thema | Entscheidung | Review-Trigger |
|---|---|---|
| USV / Power Loss | **Bewusst auf Q3/2026 geparkt.** Keine Anschaffung dieses Quartal; Power-Loss bleibt akzeptiertes Risiko. | Naechstes Hardware-Upgrade, erneuter realer Stromausfall mit Datenfolge, oder Q3-Review (ab 2026-07-01) |
| Cold-Backup-Rotation | **Bewusst Hetzner-only.** Off-site bleibt allein das Hetzner-Borg-Repo; keine zweite rotierende Cold-Kopie. | Stark wachsender Datenwert, wiederholte Hetzner-Probleme, oder geaenderte Betreiber-Praeferenz |
| Stromverbrauch messen | **Bewusst ohne Messung (Entscheidung 2026-06-06).** Kein Messgeraet; Werte bleiben dauerhaft offen, kein Beschaffungs-Todo. | Nur falls spaeter doch ein Messgeraet angeschafft wird oder Strom-/Kostenfrage relevant wird |
## Zweck
Dieses Dokument beschreibt die physische Basis des Homelabs. Es ist die Grundlage fuer Capacity Planning, Restore-Zeit, Ersatzteilplanung, USV-Verhalten und Entscheidungen wie Immich-ML, Plex-Transcoding oder Storage-Erweiterung.
@@ -108,7 +96,7 @@ tailscale ip -4
| Disk1 | `md1p1` / physisch `sdc` | WDC WD60EFAX-68JH4N1 | `WD-WX32D90PC0V0` | 5.5T | XFS auf md1p1 | Array-Daten | SMART passed |
| Parity | physisch `sdb` | TOSHIBA HDWG480 | `2460A03VFA3H` | 7.3T | n/a | Parity | SMART passed |
| Boot | `sda1` | Samsung Flash Drive | `0375125090000587` | 59.8G | FAT32 | Unraid Boot | aktiv |
| Cold Backup | bewusst keiner | n/a | n/a | n/a | n/a | Externe Rotation | **bewusst Hetzner-only** (Entscheidung 2026-06-05); off-site allein via Hetzner-Borg |
| Cold Backup | TBD | TBD | TBD | TBD | TBD | Externe Rotation | offen |
Pruefkommando:
@@ -150,27 +138,18 @@ Bewertung:
- Aktueller Befund 2026-05-26: keine funktionierende USV-Absicherung nachgewiesen.
- `apcupsd` ist zwar auf dem System vorhanden, aber nicht aktiv.
- **Operator-Entscheidung 2026-06-05: USV-Anschaffung bewusst auf Q3/2026 geparkt.** Keine Beschaffung in diesem Quartal.
- Operator-Entscheidung 2026-05-26: aktuell keine USV-Anschaffung.
- Power-Loss bleibt damit ein bewusst akzeptiertes Risiko fuer Docker-/DB-State und laufende Writes.
- Review-Trigger (einer reicht): naechstes Hardware-Upgrade, ein erneuter realer Stromausfall mit Datenfolge, oder der Q3-Review ab 2026-07-01.
- Wenn die Entscheidung in Q3 zugunsten einer USV kippt, ist das Mindestkriterium ein USB-HID-faehiges Geraet (~600-900 VA), das von `apcupsd` erkannt wird, damit der bereits vorkonfigurierte Shutdown-Pfad ohne Zusatzsoftware greift.
- Review-Ausloeser: Hardware-Erweiterung, wiederholte Stromausfaelle, Datenkorruption oder Veraenderung der Betreiber-Prioritaet.
## Stromverbrauch
**Bewusst ohne Messung (Operator-Entscheidung 2026-06-06).** Es wird kein
Messgeraet beschafft; Idle/Normal/Backup/Last bleiben dauerhaft offen. Kein
offener Todo. Falls spaeter doch eine Mess-Steckdose angeschafft wird, reicht
ein einziger Messdurchlauf, um die Tabelle zu fuellen.
| Zustand | Verbrauch | Messmethode | Datum |
|---|---:|---|---|
| Idle | offen | schaltbare Mess-Steckdose, 10 min Mittelwert ohne aktive Jobs | nach Beschaffung |
| Normalbetrieb | offen | Mess-Steckdose, typischer Tagbetrieb mit laufenden Apps | nach Beschaffung |
| Backup-Lauf | offen | Mess-Steckdose, waehrend naechtlichem Borg-Lauf | nach Beschaffung |
| Last | offen | Mess-Steckdose, unter CPU-Last (z. B. Immich-ML/Parity-Check) | nach Beschaffung |
Beschaffungs-Trigger: einfache schaltbare Energiemess-Steckdose; danach ein
einziger Messdurchlauf reicht, um diese Tabelle dauerhaft zu fuellen.
| Idle | TBD | externes Messgeraet erforderlich | TBD |
| Normalbetrieb | TBD | externes Messgeraet erforderlich | TBD |
| Backup-Lauf | TBD | externes Messgeraet erforderlich | TBD |
| Last | TBD | externes Messgeraet erforderlich | TBD |
## Ersatzteil- und Lifecycle-Plan
@@ -181,7 +160,7 @@ einziger Messdurchlauf reicht, um diese Tabelle dauerhaft zu fuellen.
| Parity | Kleiner als neue groesste Datenplatte | Parity-Upgrade vor Datenplatten-Upgrade |
| Boot-USB | Lesefehler oder Alter TBD | Flash-Backup verifizieren, Ersatzstick vorbereiten |
| RAM | Swap/OOM oder Immich/Nextcloud-Druck | Ausbau planen |
| USV | keine funktionierende USV-Abschaltung | Anschaffung 2026-06-05 bewusst auf Q3/2026 geparkt; Trigger: Hardware-Upgrade, realer Stromausfall mit Datenfolge, oder Q3-Review |
| USV | keine funktionierende USV-Abschaltung | Risiko am 2026-05-26 bewusst akzeptiert; bei Review erneut bewerten |
## Audit-Kommandos
docs/HOME_ASSISTANT_INFLUXDB_ECOWITT.md
+1 -8
View File
@@ -1,15 +1,8 @@
# Home Assistant -> InfluxDB 3 -> Grafana
**Status 2026-06-06: archiviert / nicht aktiv.** Home Assistant existiert seit
dem Crash aktuell nicht mehr. Dieses Dokument ist nur noch ein historischer
Zielbild-Entwurf fuer einen spaeteren Neuaufbau. Das fruehere TODO
`influxdb3_homeassistant_token` wurde aus der aktiven Master-Liste gestrichen;
vor Token-, InfluxDB-Writer- oder Ecowitt-Arbeiten muss Home Assistant zuerst
neu aufgesetzt und neu inventarisiert werden.
Ziel: Home Assistant schreibt ausgewaehlte Ecowitt- und Energiesensoren nach InfluxDB 3 Core. Grafana bleibt das Langzeit-Dashboard, Home Assistant bleibt die Automationszentrale.
## Historischer Live-Stand 2026-05-04
## Live-Stand 2026-05-04
- Home Assistant ist per SSH unter `192.168.178.50:22222` erreichbar.
- `ha core check` ist erfolgreich.
docs/MASTER_TODO.md
-112
View File
@@ -1,112 +0,0 @@
# Master To-do - KalliLab CORE
Stand: 2026-06-06 (Wochenend-Sprint, nach Status-Kategorien sortiert)
Diese Liste ist die zentrale Arbeitsliste fuer offene operative Punkte im
Homelab. Detailentscheidungen bleiben in den verlinkten Runbooks; diese Datei
haelt Status, naechsten konkreten Schritt und Quelle zusammen.
## Status-Kategorien
- **Aktiv dieses Wochenende** - soll jetzt vorankommen (Claude, Codex oder Operator); konkreter naechster Schritt steht.
- **Operator-Entscheidung** - wartet auf eine bewusste Entscheidung des Betreibers (ja/nein/welche Option).
- **Geparkt** - bewusst nicht jetzt, mit klarem Review-Trigger.
- **Extern blockiert** - wartet auf ein externes Ereignis oder eine Abhaengigkeit (Nachtlauf, zweite Hardware, Geraetebeschaffung).
Owner-Aufteilung fuer das Wochenende: `baerchen`/Veeam/Backup-Verifikation liegt
bei **Codex**; Doku-/Inventar-/Onboarding-Arbeit liegt bei **Claude**;
Host-/Entscheidungsaufgaben beim **Operator**.
---
## Aktiv dieses Wochenende
| Thema | Owner | Naechster konkreter Schritt | Quelle |
|---|---|---|---|
| Family-Onboarding erster Termin | Operator | Checkliste ist fertig (`docs/FAMILY_ONBOARDING.md` Abschnitt "Erster Onboarding-Termin"). Operator legt fest, welche Personen/Geraete real verfuegbar sind, und arbeitet die Reihenfolge Vaultwarden -> Immich -> Mealie pro Person ab | `docs/FAMILY_ONBOARDING.md`, `docs/AUDIT_2026-05-25_TODO.md` |
| Restore-Test Unraid OS Flash (Stick-Boot) | Operator | Artefakt-Validierung am 2026-06-05 erledigt (`ops/maintenance/check-unraid-flash-backup.sh`, sha256 OK, 8 Kern-Configs). **Verbleibt:** physischer Ersatzstick-Boot-Test, wenn ein Wegwerf-Stick bereitliegt | `docs/RESTORE_MATRIX.md` Abschnitt "Unraid OS Flash" |
| Restore-Test Tailscale | Operator | Runbook-Stub abarbeiten: State-Validierung + Reconnect nur auf Wegwerf-Host/VM, danach Geraet in Tailscale-Admin entfernen | `docs/RESTORE_MATRIX.md` Abschnitt "Tailscale" |
| Authelia OIDC fuer Apps | Operator/Claude | **Aktive Phase abgeschlossen 2026-06-06.** Live: Grafana (admin, Login verifiziert) + Mealie (family, verifiziert) + Paperless (family, deployed; Login-Test offen). Muster + Gotchas in `docs/AUTHELIA_OIDC_PLAN.md`. **Immich + Nextcloud bewusst GEPARKT bis Onboarding** (Entscheidung 2026-06-06): nur `micha` hat Authelia-Account, Familien-SSO-Nutzen + UI/occ-Aufwand lohnen erst mit Familien-Accounts. Runbook bereit | `docs/AUTHELIA_OIDC_PLAN.md`, `security/authelia/configuration.yml` |
---
## Operator-Entscheidung
**Stand 2026-06-06: keine offenen Operator-Entscheidungen.** Alle am 2026-06-06
entschieden — Ergebnisse in "Aktiv", "Geparkt" bzw. "Entschieden 2026-06-06".
---
## Geparkt
Bewusst nicht jetzt - mit Review-Trigger.
| Thema | Entscheidung / Trigger | Quelle |
|---|---|---|
| USV-Anschaffung | **Auf Q3/2026 geparkt** (2026-06-05). Power-Loss bleibt akzeptiertes Risiko. Trigger: Hardware-Upgrade, realer Stromausfall mit Datenfolge, oder Q3-Review ab 2026-07-01 | `docs/HARDWARE_INVENTORY.md` |
| Cold-Backup-Rotation | **Bewusst Hetzner-only** (2026-06-05). Keine zweite rotierende Cold-Kopie. Trigger: stark wachsender Datenwert, wiederholte Hetzner-Probleme, geaenderte Praeferenz | `docs/HARDWARE_INVENTORY.md` |
| WAN-Ausfallschutz | **Spaeter evaluieren** (2026-06-05). Mobilfunk-Failover inaktiv; lokale Apps laufen bei WAN-Ausfall weiter. Trigger: haeufigere/laengere DSL-Ausfaelle oder kritischer Remote-Zugang | `docs/NETWORK_INVENTORY.md` |
| Docker Critical Events Watcher | **Aktiviert 2026-06-05:** Unraid User Script `docker-critical-events-at-start` nutzt den Supervisor und steht in `schedule.json` auf `frequency: start`; Watcher manuell gestartet, Status `running`. Optionaler ntfy-Smoke wurde nachts bewusst nicht gesendet und kann spaeter mit `docker-critical-events-supervisor.sh smoke` nachgeholt werden | `docs/SERVICE_CATALOG.md`, `services/posture-check/docker-critical-events.sh`, `services/posture-check/unraid-user-scripts.md` |
| Negativ-Test Backup-Frische | **Validiert 2026-06-06:** `ops/restore-tests/negative-freshness-alert-test.sh` simuliert fehlende Dumps nur in einem synthetischen Restore-Lab-Pfad und sendet einen Test-Alert nach `homelab-alerts`; Host-Lauf schrieb Report `/mnt/user/backups/restore-reports/freshness-negative-2026-06-06-130320.md` (10 Criticals, produktive Dumps unangetastet). Quartalsweise wiederholen: `ops/restore-tests/run-restore-checks.sh freshness-negative` | `ops/restore-tests/README.md`, `docs/AUDIT_2026-05-25_TODO.md` |
| End-to-end-DR-Drill | Komplett-Bootstrap Phase 1-5 auf Wegwerf-Host; realistisch erst mit zweiter Hardware (siehe auch Extern blockiert) | `docs/AUDIT_2026-05-25_TODO.md`, `docs/DISASTER_RECOVERY.md` |
| Wiederkehrende Restore-Drills | Vaultwarden, Gitea, Authelia, Komodo, Paperless, Immich, Traefik, PostgreSQL, Mongo, Nextcloud, Mealie, Mail-Archiver nach Matrix-Intervallen rotieren | `docs/RESTORE_MATRIX.md`, `docs/RESTORE_HANDBOOK.md` |
| Dedizierter SMB-User `veeam-baerchen` | Optional spaeter, nur wenn Unraid-User-/Share-Rechte bewusst angefasst werden | `ops/windows-reinstall/docs/windows-image-backup-baseline.md` |
| Nextcloud 2FA (Operator-TOTP) | **Geparkt (Entscheidung 2026-06-06):** Operator-TOTP fuer Nextcloud erst zusammen mit der app-weiten Familien-/OIDC-Policy entscheiden. Trigger: OIDC-/SSO-Block (jetzt aktiv) erreicht die App-Login-Ebene | `docs/AUDIT_2026-05-25_TODO.md` |
| Tailnet-Konsole aufraeumen (Rest) | Nach Docker-Stack-Abbau (2026-06-06) nur noch tote Node-Eintraege: `kallilab-core` (down) und alter Offline-`baerchen` in der Tailscale-Admin-Konsole entfernen. Optional State-Pfad `/mnt/user/appdata/tailscale` nach `_archive/`. Trivial, kein Risiko | `docs/NETWORK_INVENTORY.md` |
| CrowdSec vor Traefik | Bewusst nicht umgesetzt; einzige WAN-Tuer ist `443/tcp`, Authelia `regulation:` deckt Brute-Force ab. Neu bewerten bei breiterer Attack Surface | `docs/AUDIT_2026-05-25_TODO.md` |
| Hermes-Agent | NAS-Stack bleibt deaktiviert; Review-Deadline 2026-07-25 | `docs/AUDIT_2026-05-25_TODO.md`, `docs/SERVICE_CATALOG.md` |
| Filebrowser-Mounts | Bei zukuenftigem Hardening-Sprint Mount-Scope reduzieren | `docs/SERVICE_CATALOG.md` |
| Scrutiny Privileged-Ausnahme | Nur mit klarer Begruendung aendern; sonst dokumentierte Ausnahme beibehalten | `docs/SERVICE_CATALOG.md` |
| Immich Redis named volume | Anonymes Volume bei passender Wartung auf named volume umstellen oder Ausnahme dokumentieren | `docs/SERVICE_CATALOG.md` |
| Storage-Wachstum | Zweite NVMe, ZFS/BTRFS-Optionen, zweite Array-Disk nur bei Triggern aus Capacity-Doku | `docs/STORAGE_LAYOUT.md`, `docs/CAPACITY_AND_LIFECYCLE.md` |
| Zweites Off-site-Ziel | Bewusst nicht umgesetzt; neu bewerten bei Hetzner-Problemen oder wachsendem Datenwert | `docs/AUDIT_2026-05-25_TODO.md` |
| Borg `append-only` auf Hetzner | Operator-Entscheidung 2026-06-01: nicht umgesetzt (forced-command brach Key-Auth, Nutzen/Risiko unguenstig) | `docs/AUDIT_2026-05-25_TODO.md` |
---
## Extern blockiert
Wartet auf ein externes Ereignis oder eine Abhaengigkeit.
| Thema | Blockiert durch | Naechster Schritt sobald entblockt | Quelle |
|---|---|---|---|
| End-to-end-DR-Drill (Hardware-Teil) | Keine zweite Wegwerf-Hardware verfuegbar | Sobald zweite Hardware da ist: Komplett-Bootstrap Phase 1-5 fahren | `docs/DISASTER_RECOVERY.md` |
---
## Erledigt im Wochenend-Sprint (2026-06-05)
- Restore-Matrix "Naechste Restore-Test-Kandidaten" bereinigt: 5 am 2026-06-03 abgeschlossene Kandidaten entfernt, durch die 4 real offenen Pfade ersetzt; Stand-Datum aktualisiert.
- Restore-Test-Runbook-Stubs fuer Unraid Flash / AdGuard / Tailscale / Redis 8 in `docs/RESTORE_MATRIX.md` ergaenzt.
- Alte Windows-Doku bereinigt: WinRE-/Admin-Check-To-dos in `boot-cleanup-plan-2026-06-04.md` und `laufwerks-neustruktur-2026-06-04.md` als erledigt markiert.
- `docs/HARDWARE_INVENTORY.md`: USV (Q3-Park), Cold-Backup (Hetzner-only) und Stromverbrauch von diffusen TBDs auf bewusste Entscheidungen mit Review-Triggern gehoben.
- `docs/NETWORK_INVENTORY.md`: Tailscale-Inventar am 2026-06-05 **real per read-only SSH gemessen** und eingetragen: IPv6 `fd7a:115c:a1e0::2c01:62b2`, Exit Node `nein`, **Subnet-Router fuer `192.168.178.0/24` aktiv** (widerlegt fruehere Vermutung), Tailnet `taild9fcf2.ts.net`, Geraete-Snapshot + Dubletten-Hinweis. WAN-Failover und Gast-/IoT geschaerft. `zu messen`-Platzhalter entfernt. **`Tailscale-Inventar messen` damit geschlossen.**
- `ops/maintenance/check-unraid-flash-backup.sh` neu: read-only Validierung des Flash-Artefakts (sha256, Frische, Kern-Configs, keine Extraktion). Am 2026-06-05 gegen den Host getestet: Exit 0, sha256 OK, 390 Eintraege, 8/8 Kern-Configs. `docs/RESTORE_MATRIX.md` mit Testdatum/Ergebnis aktualisiert. **Artefakt-Validierung des Unraid-Flash-Backups damit erledigt; nur Stick-Boot-Test offen.**
- `docs/FAMILY_ONBOARDING.md`: Michi-Checkliste in eine echte Erste-Termin-Checkliste (Vorbereitung, Reihenfolge, Erfolgskriterium, bewusst spaeter) umgebaut.
- `docs/MASTER_TODO.md` in vier Status-Kategorien (Aktiv / Operator-Entscheidung / Geparkt / Extern blockiert) umstrukturiert.
- `baerchen` Veeam-Erstbackup: erster Full-Lauf 2026-06-05 erfolgreich geschrieben (Veeam-GUI 53,8 GB, Dauer 0:11:31, MetaCheck 0 Fehler/0 Warnungen, VSS `job: success`). Beleg in `ops/windows-reinstall/docs/windows-image-backup-baseline.md`; Veeam Storage Encryption war im ersten Lauf nicht aktiv und ist als Operator-Entscheidung nachgezogen.
- Docker Critical Events Watcher auf Unraid aktiviert: Host-Clone auf Commit `2f3d184` aktualisiert, User Script `/boot/config/plugins/user.scripts/scripts/docker-critical-events-at-start/script` auf den Supervisor umgestellt, altes Script als `script.bak-20260605-232621` gesichert, `schedule.json` zeigt `frequency: start`, Watcher laeuft mit PID `1681168`. ntfy-Smoke am 2026-06-06 erfolgreich beim Operator angekommen.
- Restore-Test AdGuard Home: automatisierter Test `ops/restore-tests/adguard-restore-test.sh` erstellt und am 2026-06-06 auf Unraid erfolgreich ausgefuehrt. Ergebnis: Borg-Config-Restore aus Archiv `Taegliche-Sicherung-2026-06-06T04:30:05.910`, isolierter Container `restoretest-adguard`, HTTP `/control/status` = `401`, DNS-Smoke `git.kaleschke.info -> 192.168.178.58`, 7 Filterlisten-Eintraege, Report `/mnt/user/backups/restore-reports/adguard-2026-06-06.md`.
- Restore-Test Redis 8: automatisierter Test `ops/restore-tests/redis-restore-test.sh` erstellt und am 2026-06-06 auf Unraid erfolgreich ausgefuehrt. Ergebnis: Restore aus `/mnt/user/backups/borg/dumps/latest/shared-redis-pre-redis8-20260531-185011`, isolierter Container `restoretest-redis`, `PING` = `PONG`, Redis `8.8.0`, AOF `1`, `DBSIZE` = `1`, Report `/mnt/user/backups/restore-reports/redis-2026-06-06.md`.
- **Tailscale ACL-Policy restriktiv ausgerollt (2026-06-06):** Von Default-Allow auf Tag-basierte `grants`-Policy umgestellt, gemeinsam mit dem Operator in lockout-sicherer Reihenfolge (additiv -> taggen -> Allow-all entfernen), jeder Schritt read-only per SSH verifiziert. Live: `kallilabcore`=`tag:server`, `baerchen-1`+`iphone-14`=`tag:operator`, `tag:family` vorbereitet/schlafend. Subnet-Route `192.168.178.0/24` bleibt via `autoApprovers` approved. Smoke-Tests gruen (Operator-SSH, AdGuard-Admin `HTTP 302` ueber Tailnet, Ping 0%); untagged Nodes (`kallilab-core` Docker-Sidecar, alter `baerchen`) isoliert. Beleg: `docs/NETWORK_INVENTORY.md` Abschnitt "ACL-Policy — ANGEWENDET 2026-06-06". Familien-Dienste konkretisieren bei erstem realem Familiengeraet.
- **Redundanten Docker-Tailscale-Stack entfernt (2026-06-06):** Befund: Host hatte zwei `tailscaled` — die funktionale native Plugin-Instanz `kallilabcore` (echtes TUN `tailscale1`, Subnet-Router, State im Flash-Backup) und den redundanten userspace-only Docker-Stack `kallilab-core` (`host-services/tailscale/`, routet nichts, nichts haengt dran). Sauber per GitOps abgebaut: Operator hat Komodo-Stack `tailscale` gestoppt+destroyed; danach `git rm host-services/tailscale/`, Glance-Widget entfernt, Architektur-/Service-Catalog-/DR-Bootstrap-/CLAUDE-/Restore-Matrix-/Netzwerk-Doku auf "natives Plugin" nachgezogen. Read-only verifiziert: Container weg, nur noch der native `tailscaled`, Subnet-Route + Operator-Zugriff intakt. Rest: tote Node-Eintraege in der Admin-Konsole entfernen (eigener Todo).
- DR-Workstation Bare-Metal-Kit abgeschlossen: WSL2 Ubuntu 24.04 auf `baerchen`, Borg 1.2.8, GitHub-Read-DR-Key und Hetzner-DR-Key in WSL, `~/dr-smoke.sh` vorhanden. Finaler Smoke 2026-06-06 erfolgreich: GitHub HEAD `3a263a4...`, Hetzner Storage Box Repos sichtbar, Borg-Repo `hetzner_borg_appdata_critical` gelesen, Repository ID `5dd9b949...`, encrypted `Yes (repokey)`, `DR-Smoke OK (2026-06-06 10:05:30)`. Passphrase wurde nur interaktiv eingegeben und nicht gespeichert.
- Restore-Frische-Negativtest validiert: `ops/restore-tests/negative-freshness-alert-test.sh` erstellt und am 2026-06-06 auf Unraid erfolgreich ausgefuehrt. Ergebnis: synthetischer leerer Dump-Pfad erzeugte erwartungsgemaess 10 Criticals, Test-Alert nach `homelab-alerts` gesendet, Report `/mnt/user/backups/restore-reports/freshness-negative-2026-06-06-130320.md`, produktive Dumps unangetastet.
- Gast-/IoT-Netz aktiviert und validiert: FRITZ!Box-Gastzugang `Fritzi Gastzugang` aktiv, Heimnetz-Zugriff aus dem Gastnetz blockiert. LAN- und Host-Preflight gruen; iPhone-Smoke aus dem Gast-WLAN bestaetigt, dass `192.168.178.58:8082`, `:8181`, `:222`, `https://192.168.178.58` und `192.168.178.1` nicht erreichbar sind. Runbook: `docs/GUEST_IOT_NETWORK.md`.
- `baerchen` Veeam-Recovery-Test ohne echten Restore abgeschlossen: Recovery-USB `VEEAMRE` bootet, SMB-Ziel `\\kallilabcore\backups\windows-images\baerchen` ist in der Recovery Environment erreichbar, Restore Point wird angezeigt, Test vor echtem Restore abgebrochen. Runbook: `ops/windows-reinstall/docs/windows-image-backup-baseline.md`.
- **Operator-Entscheidungen 2026-06-06 abgeschlossen** (Liste damit ohne offene Entscheidungen):
- **BitLocker `baerchen`: bewusst deaktiviert.** Recovery laeuft ueber Veeam-Image; kein BitLocker-Key-Management. Restrisiko physischer Diebstahl bewusst akzeptiert.
- **Veeam Storage Encryption: bewusst unverschluesselt.** Erster Full-Lauf bleibt; Image liegt auf dem lokalen SMB-Share `\\kallilabcore\backups`. Neu bewerten bei Off-host-Auslagerung des Images.
- **Stromverbrauch: bewusst ohne Messung.** Kein Messgeraet; Werte bleiben dauerhaft offen, kein Beschaffungs-Todo mehr.
- **Authelia Rest-2FA: KOMPLETT erledigt 2026-06-06.** Catch-all `*.kaleschke.info` -> `two_factor` in Repo **und** Host-Config (chirurgische Einzelzeilen-Aenderung mit Backup, OIDC-Beszel-Client + Secret unangetastet), `docker restart authelia` -> healthy + "Startup complete", Operator-2FA-Login auf einer vorher-1FA-Domain verifiziert. Nebenbei vorbestehenden Drift gefunden+bereinigt (Host-Config war vom 25. Mai, borg/code nie gemerged); Repo-Baseline an Host-Endzustand angeglichen, damit `authelia-diff.sh` clean wird sobald der Host-Mirror nachzieht. Rollback-`.bak` auf dem Host vorhanden.
- **Authelia OIDC: angehen** (neuer aktiver Block) — **Gast-/IoT-Netz: einrichten/planen** (neuer aktiver Block) — **Nextcloud 2FA: geparkt** bis OIDC die App-Login-Ebene erreicht.
---
## Pflege-Regel
- Neue operative To-dos zuerst hier eintragen oder aus Detaildokumenten hierher uebernehmen, immer mit Status-Kategorie.
- Wenn ein Punkt erledigt ist, in der Detaildoku den Beleg/Report eintragen und diese Liste aktualisieren.
- Keine vagen "pruefen"-Eintraege ohne Kommando oder Entscheidung.
- Historische Drill-Reports bleiben Belegmaterial, aber nicht die fuehrende Arbeitsliste.
docs/NETWORK_INVENTORY.md
+12 -275
View File
@@ -1,7 +1,7 @@
# Network Inventory - KalliLab CORE
Status: Host-Audit erfasst; Router-Baseline und Portfreigaben-UI bereinigt; FRITZ!Box-Remote-Dienste aus; IPv6-Exposure technisch und per UI entschaerft; Tailscale-Inventar am 2026-06-05 real gemessen.
Letzte Pruefung: 2026-06-05 (Tailscale-Inventar), 2026-06-01 (Router/Ports)
Status: Host-Audit erfasst; Router-Baseline und Portfreigaben-UI bereinigt; FRITZ!Box-Remote-Dienste aus; IPv6-Exposure technisch und per UI entschaerft.
Letzte Pruefung: 2026-06-01
## Zweck
@@ -44,163 +44,23 @@ Dieses Dokument beschreibt Router, DNS, Tailscale, Portfreigaben und Netztrennun
## Tailscale
Gemessen am 2026-06-05 per read-only SSH auf den Host (`tailscale status`,
`tailscale status --json`, `tailscale ip -4/-6`).
| Feld | Wert / Status |
| Feld | Wert |
|---|---|
| Node-Name | Kallilabcore |
| Tailnet / MagicDNS | `taild9fcf2.ts.net`; DNSName `kallilabcore.taild9fcf2.ts.net` |
| Tailscale IPv4 | `100.80.98.33` |
| Tailscale IPv6 | `fd7a:115c:a1e0::2c01:62b2` (gemessen 2026-06-05) |
| Exit Node | **Nein.** `Self.ExitNodeOption: false` und `Self.ExitNode: false` — Host bietet keinen Exit Node an und nutzt keinen. Entspricht dem Ziel (Operator-Zugang ist eingehend, nicht als Internet-Ausgang). |
| Subnet Router | **Ja, aktiv.** Host advertised und ist Primary fuer `192.168.178.0/24` (`Self.PrimaryRoutes: ["192.168.178.0/24"]`, ebenfalls in `AllowedIPs`). Das LAN ist also fuer das gesamte Tailnet ueber diesen Subnet-Router erreichbar — bewusst gemessener Ist-Zustand, **kein** "keine Route" wie zuvor vermutet. |
| ACL-Policy extern dokumentiert | **Angewendet 2026-06-06** — restriktive Tag-basierte `grants`-Policy live (`tag:server`/`tag:operator`, `tag:family` schlafend). Default-Allow entfernt, verifiziert. Details im Block unten. |
| Tailscale IPv4 | 100.80.98.33 |
| Tailscale IPv6 | TBD |
| Exit Node | TBD |
| Subnet Router | TBD |
| ACL-Policy extern dokumentiert | TBD |
### Tailnet-Geraete (Snapshot 2026-06-05)
| Tailscale-IP | Node | OS | Status |
|---|---|---|---|
| `100.80.98.33` | kallilabcore | linux | aktiv (Host, Subnet-Router) |
| `100.78.133.37` | baerchen-1 | windows | aktiv (aktuelle Operator-Workstation, direct) |
| `100.105.203.21` | baerchen | windows | offline, zuletzt vor ~1 Tag gesehen (Alt-Node) |
| `100.73.83.55` | iphone-14 | iOS | bekannt |
| `100.112.0.90` | kallilab-core | linux | **am 2026-06-06 entfernt.** War der redundante userspace-only `Tailscale-Docker`-Stack (`host-services/tailscale/`). Komodo-Stack gestoppt+destroyed, Repo-Pfad per `git rm` entfernt, Container weg (read-only verifiziert). Node-Eintrag in der Admin-Konsole noch zu entfernen. |
> **Befund 2026-06-06 (read-only auf dem Host ermittelt):** Der Host hat **zwei**
> `tailscaled`-Prozesse:
>
> 1. **Native Unraid-Plugin** = `kallilabcore` (100.80.98.33). Prozess
> `/usr/local/sbin/tailscaled -statedir /boot/config/plugins/tailscale/state
> -tun tailscale1`. **Echtes TUN-Interface `tailscale1`, ist der Subnet-Router
> fuer `192.168.178.0/24`**, laeuft seit 24. Mai, installiert via
> `tailscale.plg` + `unraid-tailscale-utils`. State unter
> `/boot/config/plugins/tailscale/state` → ueber das **Flash-Backup** gesichert.
> Im ACL-Rollout `tag:server`. **Das ist die funktionale, kanonische Instanz.**
> 2. **Docker-Stack** = `kallilab-core` (100.112.0.90), `host-services/tailscale/`.
> Prozess `tailscaled --tun=userspace-networking` → **nur Userspace, kann
> technisch nicht routen / kein Subnet-Router/Exit-Node sein**, advertised
> nichts, kein Container teilt seinen Namespace, seit 31. Mai. State unter
> `/mnt/user/appdata/tailscale`. Im ACL-Rollout untagged → isoliert.
> **Hochwahrscheinlich redundant.**
>
> **Umgesetzt 2026-06-06:** Der redundante Docker-Stack `host-services/tailscale/`
> wurde sauber per GitOps abgebaut — Komodo-Stack `tailscale` gestoppt+destroyed
> (Operator), `git rm host-services/tailscale/`, Glance-Widget entfernt, und
> Architektur-/Service-Catalog-/DR-/CLAUDE-Doku auf "natives Plugin" nachgezogen.
> Read-only verifiziert: Container weg, nur noch der native `tailscaled` mit
> `tailscale1`, Subnet-Route + Operator-Zugriff intakt. Offen: Node-Eintraege
> `kallilab-core` und alter `baerchen` in der Admin-Konsole entfernen; State-Pfad
> `/mnt/user/appdata/tailscale` bei Gelegenheit nach `_archive/` (kein Sofort-Loeschen).
>
> **Doku-Korrektur erledigt:** `docs/RESTORE_MATRIX.md` zeigt jetzt auf den
> funktionalen State `/boot/config/plugins/tailscale/state` (im Flash-Backup)
> statt auf den entfernten userspace-Docker-Pfad.
### Subnet-Router-Konsequenz
Weil `Kallilabcore` das LAN `192.168.178.0/24` als Subnet-Route anbietet, kann
**jedes** Tailnet-Geraet mit Zugriff auf diese Route potenziell LAN-Dienste auf
`192.168.178.0/24` erreichen — auch die Admin-Ports, die im LAN bewusst nur auf
die Tailscale-IP gebunden sind, sind ueber die Subnet-Route adressierbar. Genau
deshalb ist die ACL-Policy (unten) der eigentliche Schutzmechanismus und nicht
nur der LAN-Bind.
Pruefkommando (auf dem Unraid-Host, read-only):
Pruefkommando:
```bash
tailscale status
tailscale status --json | jq '{exitNode: .Self.ExitNodeOption, primaryRoutes: .Self.PrimaryRoutes, allowedIPs: .Self.AllowedIPs}'
tailscale ip -4
tailscale ip -6
```
### ACL-Policy — ANGEWENDET 2026-06-06 (restriktive Tag-basierte grants)
**Status: live und verifiziert.** Die restriktive Policy wurde am 2026-06-06
gemeinsam mit dem Operator in der lockout-sicheren Reihenfolge ausgerollt und
read-only verifiziert (siehe "Rollout-Protokoll" unten). Ausgangspunkt war die
**unveraenderte Default-Policy** im **`grants`-Schema** (eine Allow-all-Regel,
keine Groups/Tags/`autoApprovers`); es gab also keinen eigenen Bestand zu
erhalten.
> **Schema-Hinweis:** Dieses Tailnet nutzt das `grants`-Modell
> (`{"src","dst","ip"}`), nicht das aeltere `acls`/`action:accept`-Modell.
> Normaler SSH-Zugriff (`ssh kallilabcore` ueber OpenSSH Port 22) wird ueber
> `grants` geregelt, nicht ueber den `ssh`-Block; letzterer betrifft nur die
> Tailscale-SSH-Funktion.
**Angewendete Policy (live, kein Secret):**
```json
{
"tagOwners": {
"tag:server": ["autogroup:admin"],
"tag:operator": ["autogroup:admin"],
"tag:family": ["autogroup:admin"]
},
"autoApprovers": {
"routes": { "192.168.178.0/24": ["tag:server"] }
},
"grants": [
{"src": ["tag:operator"], "dst": ["*"], "ip": ["*"]},
{"src": ["tag:server"], "dst": ["tag:operator"], "ip": ["*"]},
{"src": ["tag:family"], "dst": ["tag:server"], "ip": ["tcp:443"]}
],
"ssh": [
{"action": "check", "src": ["autogroup:member"], "dst": ["autogroup:self"],
"users": ["autogroup:nonroot", "root"]}
]
}
```
**Geraete-Tags (live):** `kallilabcore` = `tag:server`; `baerchen-1` + `iphone-14`
= `tag:operator`; `kallilab-core` (Docker) + alter `baerchen` bewusst untagged ->
isoliert.
**Rollout-Protokoll 2026-06-06 (lockout-sicher, je Schritt read-only verifiziert):**
1. Policy additiv erweitert (Tags/grants definiert, Allow-all noch drin) -> alle Peers unveraendert verbunden, Route approved.
2. `baerchen-1` getaggt `tag:operator` -> online, verifiziert.
3. `iphone-14` getaggt `tag:operator` -> verifiziert.
4. `kallilab-core` faktisch geprueft (Docker-Sidecar, keine Abhaengigen) -> bewusst untagged gelassen.
5. Host `kallilabcore` getaggt `tag:server` -> Route blieb via `autoApprovers` automatisch approved, SSH ok.
6. Allow-all entfernt -> restriktiv. Smoke-Tests gruen: Operator-SSH ok, AdGuard-Admin ueber Tailnet `HTTP 302`, Ping 0% Verlust, Route weiter approved; Host sieht nur noch die zwei Operator-Peers (untagged Nodes isoliert). LAN-Rueckweg durchgehend verfuegbar.
**Schema-/Erhaltungs-Hinweis fuer spaeter:** Die LAN-Subnet-Route
`192.168.178.0/24` wird jetzt ueber `autoApprovers`/`tag:server` approved
(vorher manuell). Es gibt keinen eigenen Bestand zu erhalten; die Policy oben
ist die vollstaendige Wahrheit.
**Hintergrund / Designentscheidungen (2026-06-05/06):**
- Single-User-Realitaet: alle Nodes gehoeren demselben User `michaelkaleschke@`.
Eine Differenzierung Operator/Familie ist nur ueber **Tags** moeglich, deshalb
der Tag-Ansatz statt user-/gruppenbasiert.
- Erster Rollout bewusst klein: nur `tag:server` + `tag:operator`.
- **`tag:family` ist vorbereitet, aber schlafend:** Tag und eine konservative
Minimal-Regel (`dst: tag:server`, `ip: tcp:443`) sind definiert, aber **kein
Geraet traegt den Tag**, daher null Wirkung. Sobald ein echtes Familiengeraet
dazukommt, wird es einmal mit `tag:family` getaggt und die Regel greift sofort
— ohne Policy-Umbau. Vor dem ersten realen Familiengeraet die Regel auf die
dann benoetigten Dienste/Ports pruefen.
- Der `ssh`-Block bleibt der Default (Tailscale-SSH Check-Modus); normaler
OpenSSH-Zugriff laeuft ueber die `grants` (Port 22, fuer `tag:operator` ueber
`ip: ["*"]` abgedeckt).
**Offene Folgepunkte (kein Risiko, Hygiene/spaeter):**
- Familien-Dienste/Ports konkretisieren — erst wenn ein reales Familiengeraet dazukommt.
- **Zwei-Tailscale-Konsolidierung: ERLEDIGT 2026-06-06** — redundanter Docker-Stack
abgebaut, nur noch die native Plugin-Instanz `kallilabcore` (Subnet-Router) aktiv.
- **Tailnet-Konsole aufraeumen: ERLEDIGT 2026-06-06** — Node-Eintraege `kallilab-core`
und alter Offline-`baerchen` aus der Admin-Konsole entfernt.
- State-Pfad `/mnt/user/appdata/tailscale` (vom entfernten Docker-Stack) bei
Gelegenheit nach `_archive/tailscale-removed-2026-06-06/` (kein Sofort-Loeschen).
- Optionaler Off-LAN-Routentest: von einem Operator-Geraet im Mobilfunk
(nicht im Heim-LAN) ein LAN-Ziel ueber `192.168.178.0/24` erreichen, um die
Subnet-Route end-to-end zu bestaetigen (im Heim-LAN nicht sauber isolierbar).
## Portfreigaben und Exposure
### FRITZ!Box (WAN -> Host)
@@ -217,7 +77,6 @@ Bewusst **nicht** freigegeben:
|---|---|
| `80/tcp` | Cloudflare-DNS-Challenge ersetzt HTTP-01; Traefik macht HTTP->HTTPS-Redirect nur LAN-seitig; WAN-`80` waere zusaetzliche Angriffsflaeche ohne Funktionsnutzen. **2026-05-28 in FRITZ!Box-UI entfernt**, Validierung: Mobilfunk-Test ergibt Timeout auf `http://vault.kaleschke.info`, `https://...` weiter erreichbar. |
| `222/tcp` (Gitea SSH) | bewusst Tailscale-only: Operator-Pfad ist Tailscale, GitHub-Mirror deckt DR-Bootstrap ab, Gitea-Bundles sind off-host. Externe SSH-Brute-Force-Vektoren vermeiden. |
| `32400/tcp` (Plex) | Plex wird extern ausschliesslich ueber `https://plex.kaleschke.info` via Traefik/443 erreicht. Kein direkter WAN-Port fuer Plex, Plex Remote Access bleibt aus. |
### UPnP / Selbstständige Portfreigaben
@@ -246,7 +105,6 @@ Historischer UI-Befund vor Bereinigung vom 2026-05-27 (`Internet -> Freigaben ->
| 443/tcp | Traefik | HTTPS | WAN-Freigabe in FRITZ!Box erwartet |
| 222/tcp | Gitea SSH | Git SSH | nur LAN/Tailscale; keine WAN-Freigabe |
| 53/tcp+udp | AdGuard | DNS | LAN-only, dokumentierte Ausnahme |
| 32400/tcp | Plex | Medienserver / Plex Web lokal | LAN/Tailscale direkt; extern nur via Traefik `https://plex.kaleschke.info`, keine WAN-Freigabe fuer 32400 |
| 8082/tcp | AdGuard Admin | Admin UI | Bind nur `100.80.98.33:8082` (Tailscale), nicht im LAN exponiert |
| 8181/tcp | InfluxDB 3 Core | Home Assistant / Ecowitt Writer | 2026-05-31 effektiv nur `127.0.0.1:8181`, nicht LAN-exponiert |
@@ -263,7 +121,7 @@ docker ps --format "{{.Names}}: {{.Ports}}" | sort
|---|---|---|
| LAN | 192.168.178.0/24 | Hauptnetz, Host `192.168.178.58`, FRITZ!Box meldet 35 aktive Geraete |
| WLAN 2,4 / 5 GHz | aktiv, SSID `Fritzi` | Standard-WLAN, im LAN-Adressbereich, kein eigener Adressraum |
| Gast-WLAN | aktiv, SSID `Fritzi Gastzugang` | FRITZ!Box-Gastnetz ist vom Heimnetz getrennt; Smoke 2026-06-06 vom iPhone bestaetigt keine Erreichbarkeit der getesteten LAN-/Admin-Ziele |
| Gast-WLAN | **inaktiv** (FRITZ!Box-UI) | Solange inaktiv: kein Gast-Pfad zu LAN-Diensten; AdGuard-Admin-Trennung primaer ueber Tailscale-Bind statt Netzsegmentierung |
| IoT-Netz | nicht existent | Keine VLAN-Trennung dokumentiert |
| Tailscale | aktiv | Operator-Zugang, Host-IP `100.80.98.33` |
| VLANs | nicht in Nutzung | FRITZ!Box 7590 kann VLAN-Tagging an einzelnen LAN-Ports; aktuell nicht konfiguriert |
@@ -288,126 +146,6 @@ docker network inspect frontend_net | jq '.[0].Containers | keys'
docker network inspect backend_net | jq '.[0].Internal'
```
## SSH-Konfiguration Host
Geprueft 2026-06-06 (read-only), **gehaertet 2026-06-07** via `ssh root@192.168.178.58`.
| Parameter | Ist-Wert (effektiv via `sshd -T`, Stand 2026-06-07) | Soll | Status |
|---|---|---|---|
| `Port` | `22` | 22 | ok |
| `PermitRootLogin` | `prohibit-password` | `prohibit-password` | **gehaertet 2026-06-07** |
| `PasswordAuthentication` | `no` | `no` | **gehaertet 2026-06-07** |
| `KbdInteractiveAuthentication` | `no` | `no` | **gehaertet 2026-06-07** (noetig wegen `UsePAM yes`) |
| `PubkeyAuthentication` | `yes` | `yes` | ok |
| `PermitEmptyPasswords` | `no` | `no` | ok |
| `AuthorizedKeysFile` | `.ssh/authorized_keys` | `.ssh/authorized_keys` | ok |
**Hinterlegte SSH-Keys (root):** 3 Keys vorhanden (persistiert unter `/boot/config/ssh/root/authorized_keys`):
- `root@Kallilabcore` (Host-eigener Key)
- `michi@Baerchen` (Operator-Workstation)
- `hetzner-storagebox-maintenance-2026-06-01` (Hetzner-Maintenance-Key)
**Durchgefuehrte Haertung (2026-06-07):** Root-Login ist jetzt key-only,
Passwort- und Keyboard-Interactive-Auth sind serverseitig abgeschaltet.
Verifiziert: frischer Key-Login `OK`; `ssh -o PreferredAuthentications=none`
meldet `Authentications that can continue: publickey`; reiner Passwort-Versuch
`Permission denied (publickey)`.
**Wichtig — Unraid-Persistenz:** `/etc/ssh/sshd_config` wird beim Boot aus dem
OS-Image regeneriert (`rc.sshd`: `cp -f /boot/config/ssh/* /etc/ssh/`, danach
`sshd_build`, das nur `Port`/`ListenAddress`/`AddressFamily` setzt). Die
Unraid-GUI (**Settings → Management Access → SSH**) bietet nur `Use SSH`/`SSH port`
an — **`PermitRootLogin`/`PasswordAuthentication` sind dort nicht einstellbar.**
Persistiert wird daher **upgrade-sicher** ueber einen idempotenten Hook:
- `/boot/config/ssh-harden.sh` — setzt die drei Direktiven idempotent (bestehende
aktive Zeile entfernen, genau einmal global vor dem ersten `Match`-Block einfuegen),
`sshd -t`-Validierung, Reload nur per `kill -HUP` des Host-`sshd` bei valider Config.
Idempotenz belegt: nach mehreren Laeufen je Direktive exakt 1 aktive Zeile, alte
`PermitRootLogin yes` entfernt.
- `/boot/config/go` — ruft `/bin/bash /boot/config/ssh-harden.sh` bei jedem Boot auf.
**Selbst-Verifikation (Syslog, rein informativ, keine Reparatur):** Das Skript
schreibt nach jedem Lauf die effektiven Auth-Werte (`sshd -T`) nach syslog, z. B.
`ssh-harden: VERIFY permitrootlogin prohibit-password pubkeyauthentication yes
passwordauthentication no kbdinteractiveauthentication no`. Damit ist nach jedem
Boot/Upgrade nachweisbar, ob die Haertung gegriffen hat.
**Post-Upgrade-/Reboot-Check** (manuell, einmal nach jedem Unraid-Upgrade):
```bash
# A) Effektive Werte direkt abfragen (Soll: prohibit-password / no / no / yes)
ssh root@192.168.178.58 "sshd -T | grep -Ei 'permitroot|passwordauth|kbdinteractive|pubkey'"
# B) Oder die automatische VERIFY-Zeile im Syslog lesen (Unraid nutzt rsyslog -> /var/log/syslog, nicht logread)
ssh root@192.168.178.58 "grep 'ssh-harden' /var/log/syslog | tail -3"
```
Dieser Weg editiert die **jeweils aktuelle** von Unraid generierte Config nach und
ueberlebt damit Unraid-Upgrades; findet er die Stock-Zeile nicht (z. B. weil eine
neue Version schon `prohibit-password` ausliefert), macht der `sed` nichts und
bricht den Boot nicht (fail-safe Richtung offen, nicht ausgesperrt). Bewusst
**nicht** der oft empfohlene Weg einer kompletten `/boot/config/ssh/sshd_config`
auf Flash — der wuerde die Stock-Config einfrieren und beim Upgrade neue Defaults
verschlucken.
**Rollback:** `go`-Block + `/boot/config/ssh-harden.sh` entfernen, dann
`cp /boot/config/ssh-harden.sshd_config.bak-20260607 /etc/ssh/sshd_config` und
`kill -HUP $(cat /var/run/sshd.pid)`. Notzugang ueber Unraid-Konsole/GUI bleibt.
**Abgrenzung:** Ein zweiter `sshd` (`-D -e`) laeuft in einem Docker-Container
(s6-overlay, moby-Namespace) und bindet **nicht** den Host-`:22`; eigene Config
im Container, von dieser Haertung unberuehrt.
---
## Post-Upgrade Posture-Recheck — Unraid 7.3.1 (2026-06-07)
Nach dem Major-Upgrade **7.2.4 → 7.3.1** read-only die Host-Listener-Landschaft
(`ss -tlnp`) gegen die dokumentierten Annahmen geprueft.
**Dokumentierte Ausnahmen verifiziert (alle weiterhin gueltig):**
| Dienst | Soll | Ist nach 7.3.1 | Status |
|---|---|---|---|
| InfluxDB 3 | nur `127.0.0.1:8181` | `127.0.0.1:8181` | ✅ |
| AdGuard-Admin | nur Tailscale `100.80.98.33:8082` | `100.80.98.33:8082` | ✅ |
| Gitea-SSH `222` | LAN/Tailscale, keine WAN-Freigabe | `0.0.0.0:222` (LAN/TS), WAN am Router zu | ✅ |
| Traefik `80/443` | einziger Owner | docker-proxy (Traefik) allein | ✅ |
| libvirt `:53` | darf nicht existieren | **weg** (Fix vom 2026-06-07 haelt) | ✅ |
**Docker-Socket (`/var/run/docker.sock`) — C-3-Kontext:**
| Container | Mount | Bewertung |
|---|---|---|
| komodo-periphery | **RW** | dokumentierte Ausnahme (Periphery startet/stoppt Container) |
| traefik | ro | C-3: Direkt-Mount (ro), nicht ueber Socket-Proxy — offener Audit-Punkt, kein Regress |
| glances / monitoring-promtail / glance-docker-socket-proxy | ro | unkritisch |
Keine neue RW-Socket-Exposure durch das Upgrade.
**Vorfall-Notiz AdGuard/DNS (Boot-Race, behoben 2026-06-07):** Das Upgrade hatte das
ungenutzte **libvirt-Default-Netz** auf Autostart gebracht; dessen `dnsmasq` belegte
beim Boot Port `53` **vor** AdGuard → AdGuards erster Start scheiterte am Bind und
liess den Container ohne Netz-Anbindung (`Networks={}`, keine Ports) zurueck. Fix:
`virsh net-autostart default --disable` + `virsh net-destroy default` (kein VM
betroffen, Liste leer) + AdGuard-Container aus der Compose `--force-recreate`
(re-attach `dns_net`, `:53` neu veroeffentlicht). DNS danach verifiziert aufloesend.
`libvirtd` laeuft weiter nur auf `127.0.0.1:16509`.
**Empfehlung (Dauerfix):** Da keine VMs genutzt werden, **Unraid VM Manager → Enable
VMs = No** — dann startet `libvirtd` gar nicht und der `:53`-Konflikt kann prinzipiell
nicht wiederkehren. Bis dahin verhindert der abgeschaltete Autostart die Wiederkehr.
**Beobachtungen (kein Regress, Inventar):** SMB (`:445/:139`) und Plex (`*:32400`)
lauschen auch auf der Tailscale-IP; durch die seit 2026-06-06 tag-restriktive
Tailnet-ACL akzeptabel.
**SSH-Haertung nach Upgrade:** key-only root unveraendert aktiv und verifiziert
(`prohibit-password`/`password no`/`kbd no`), go-Hook genau 1× gefeuert — siehe
Abschnitt „SSH-Konfiguration Host".
---
## Offene Entscheidungen
| Thema | Status | Naechster Schritt |
@@ -416,8 +154,7 @@ Abschnitt „SSH-Konfiguration Host".
| FRITZ!Box-Portfreigaben mit Repo-Soll abgleichen | **erledigt 2026-06-01** | Bereinigt: `80/tcp` entfernt (Cloudflare-DNS-Challenge ersetzt HTTP-01; Mobilfunk-Test bestaetigt Timeout auf `http://`, `https://` weiter ok). `222/tcp` bleibt bewusst nicht eingerichtet (Tailscale-only-Linie). UPnP-Selbstfreigaben sind aus. Aktiver Soll-Stand: ausschliesslich `443/tcp -> 192.168.178.58`. |
| FRITZ!Box-Dienste aus dem Internet | **erledigt 2026-06-01** | `Internet -> Freigaben -> FRITZ!Box-Dienste`: HTTPS-Zugriff auf die FRITZ!Box aus dem Internet aus; FTP/FTPS auf Speichermedien aus. |
| FRITZ!OS Update und Konfig-Backup | **erledigt 2026-06-01** | TR-064 meldet `154.08.25`; Konfig-Export liegt extern/off-system in Vaultwarden, Kennwort und Datei bleiben ausserhalb des Repos. |
| Gast-/IoT-Zugriff auf Admin-Ports | **validiert 2026-06-06** | Runbook `docs/GUEST_IOT_NETWORK.md` und Checks `ops/maintenance/check-guest-iot-isolation.ps1` sowie `ops/maintenance/check-guest-iot-preflight.sh` vorhanden. LAN-Preflight von `baerchen` gruen: `192.168.178.58:8082` und `:8181` blockiert. Host-Preflight auf Unraid gruen, Report `/mnt/user/backups/restore-reports/guest-iot-preflight-2026-06-06-131316.md`. Gast-WLAN-Smoke per iPhone: `192.168.178.58:8082`, `:8181`, `:222`, `https://192.168.178.58` und `192.168.178.1` nicht erreichbar. |
| Gast-/IoT-Zugriff auf Admin-Ports | aktuell entschaerft | Gast-WLAN ist inaktiv; bei Aktivierung muessen `192.168.178.58:8082`, `192.168.178.58:8181` und ggf. weitere LAN-Ports per FRITZ!Box-Kindersicherung/Netzwerk-Filter abgesichert werden |
| IPv6 Exposure | technisch und per UI entschaerft | Public DNS liefert keine AAAA-Records fuer `*.kaleschke.info`; Host hat keine globale Provider-IPv6. TR-064 meldet IPv6-Firewall aktiv und Pinholes grundsaetzlich erlaubt; FRITZ!Box-UI zeigt keine aktiven IPv6-Freigaben, keine Admin-/SSH-Freigaben. |
| WAN-Ausfallschutz | **geparkt: spaeter evaluieren** (Operator-Entscheidung 2026-06-05) | Mobilfunk-Stick-Failover an FRITZ!Box bleibt vorerst inaktiv. Folgen sind bewusst akzeptiert: Internet-Ausfall = ACME/DDNS pausieren, lokale Apps laufen weiter. Review-Trigger: haeufigere oder laengere DSL-Ausfaelle, oder wenn externer Remote-Zugang (statt nur lokalem Betrieb) geschaeftskritisch wird. Erst dann Mobilfunk-Failover technisch bewerten. |
| WAN-Ausfallschutz | bewusst nicht eingerichtet | Mobilfunk-Stick-Failover an FRITZ!Box ist nicht aktiv; Internet-Ausfall = ACME/DDNS pausieren, lokale Apps laufen weiter |
| Home Assistant InfluxDB Bind | validiert 2026-05-31 | `docker-proxy` bindet `127.0.0.1:8181`; keine LAN-Exposure. Wenn Home Assistant nicht lokal auf dem Host schreibt, braucht das eine bewusste Bind-Aenderung. |
| SSH-Haertung Host | **erledigt 2026-06-07** | Root-Login key-only: `PermitRootLogin prohibit-password`, `PasswordAuthentication no`, `KbdInteractiveAuthentication no`. Live gesetzt + verifiziert (Key-Login ok, Passwort-Auth abgelehnt). Persistenz upgrade-sicher ueber `/boot/config/ssh-harden.sh` (idempotent, `sshd -t` vor Reload) aufgerufen aus `/boot/config/go`. GUI bietet diese Optionen nicht. Details im Abschnitt „SSH-Konfiguration Host". |
docs/README.md
+2 -7
View File
@@ -1,6 +1,6 @@
# Documentation Index
Stand: 2026-06-05
Stand: 2026-06-01
Diese Datei trennt aktive Betriebsdokumentation von historischer Arbeitsdoku. Neue operative Dokumente duerfen nur in `docs/` liegen, wenn sie heute als Einstieg, Runbook, Inventar oder offene Arbeitsliste gebraucht werden. Erledigte Audits, Chat-Handoffs, Prompt-Dateien und abgeschlossene Plaene bleiben in der Git-Historie, aber nicht als dauerhafte Arbeitskopie.
@@ -31,10 +31,8 @@ Diese Datei trennt aktive Betriebsdokumentation von historischer Arbeitsdoku. Ne
|---|---|
| `STORAGE_LAYOUT.md` | verbindliche Storage-/Share-/Pfad-Regeln |
| `SECRETS_MAP.md` | Secret-Namen, Speicherorte und Einbindungsarten ohne Werte |
| `AUTHELIA_OIDC_PLAN.md` | Plan & Runbook fuer app-uebergreifendes SSO via Authelia OIDC |
| `HARDWARE_INVENTORY.md` | Host-, Disk-, SMART-, USV- und Power-Baseline |
| `NETWORK_INVENTORY.md` | Router, DNS, Tailscale, Portfreigaben und Netzthemen |
| `GUEST_IOT_NETWORK.md` | Sicherer Ablauf fuer FRITZ!Box-Gastnetz / IoT-Isolation |
| `EXTERNAL_DEPENDENCIES.md` | Provider, Konten und externe Abhaengigkeiten |
| `EXTERNAL_OPERATOR_RUNBOOK.md` | Hetzner-/Borg-/FRITZ!Box-Betreibercheck |
| `CAPACITY_AND_LIFECYCLE.md` | Kapazitaet, Wachstum und Upgrade-Trigger |
@@ -45,7 +43,7 @@ Diese Datei trennt aktive Betriebsdokumentation von historischer Arbeitsdoku. Ne
|---|---|
| `ALERT_RULES.md` | Prometheus-/ntfy-Regeln und Handlungslogik |
| `RENOVATE.md` | Self-hosted Renovate gegen Gitea |
| `HOME_ASSISTANT_INFLUXDB_ECOWITT.md` | Archivierter Entwurf: Home Assistant -> InfluxDB 3 -> Grafana; nicht aktiv seit Crash |
| `HOME_ASSISTANT_INFLUXDB_ECOWITT.md` | Home Assistant -> InfluxDB 3 -> Grafana |
| `H_DRIVE_NEARLINE_PULL.md` | Windows-H:/ Nearline-Pull fuer kritische Restore-Artefakte |
## Nutzer- und Planungsdoku
@@ -54,9 +52,6 @@ Diese Datei trennt aktive Betriebsdokumentation von historischer Arbeitsdoku. Ne
|---|---|
| `FAMILY_ONBOARDING.md` | familienverstaendliche Nutzungsdoku |
| `AUDIT_2026-05-25_TODO.md` | kompakte Restliste aus dem Audit-Zyklus |
| `MASTER_TODO.md` | zentrale operative Master-To-do-Liste ueber alle Bereiche |
| `WEEKEND_EXECUTION_PLAN_2026-06-05.md` | Owner-Aufteilung und Wochenendplan fuer Todo-Abschluss |
| `WEEKEND_STATUS_2026-06-05.md` | kurzlebiges Arbeitsboard fuer den laufenden Wochenend-Sprint |
| `AI_CONTEXT.md` | kompakter Kontext fuer KI-Agenten |
Windows-Neuaufsetzen-Dokumente liegen nicht mehr in `docs/`, sondern im fachlich passenden Ordner `../ops/windows-reinstall/docs/`.
docs/RENOVATE.md
+1 -9
View File
@@ -93,15 +93,7 @@ Script: bash /mnt/user/services/homelab-infra/ops/renovate/run-renovate.sh
| Schedule | `extends ["schedule:weekly"]` | Renovate-Engine prueft, aber PRs/Updates folgen Wochen-Profilen wo sinnvoll |
| Dependency Dashboard | aktiv | Gitea-Issue, die alle ausstehenden Updates auflistet |
| Onboarding-PR | `onboarding: false` | Keine `Configure Renovate`-Onboarding-PR; wir nutzen die Repo-`renovate.json` direkt |
| Ignore-Pfade | `_archive`, `ops/grafana-influxdb`, `ops/loki`, `ops/komodo` | Renovate scant alte/abgeloeste Stacks nicht; `ops/komodo` ist bewusst raus (siehe unten) |
## Ausnahme: komodo-Stack ist inline-verwaltet, nicht git-deployed
Der `komodo`-Stack (Komodo-Core/Mongo/Periphery, Datei `ops/komodo/docker-compose.yml`) wird **nicht aus diesem Repo deployed**. In Komodo ist der Stack als **inline `file_contents`** (UI-defined) gespeichert (`repo` leer, `files_on_host=false`, `has_inline_file_contents=true`) und hat bewusst `webhook_enabled=false`, damit Komodo sich nicht selbst per Webhook recreated (Bootstrap-/Henne-Ei-Fall).
Konsequenz: Ein Renovate-PR auf `ops/komodo/docker-compose.yml` wirkt zur Laufzeit **nicht** (Komodo deployt aus seiner Inline-Definition) und erzeugt nur Git↔Komodo-Scheinsicherheit. Deshalb steht `ops/komodo/**` in `ignorePaths`. Die Repo-Datei bleibt als Doku/Spiegel und traegt den aktuell real laufenden Digest.
Befund-Datum 2026-06-10: Renovate-PR #13 (mongo-8.0.23 Digest-Refresh) wurde gemergt, wirkte aber nicht; der Digest wurde im Repo auf den laufenden Stand zurueckgesetzt und der Pfad ausgenommen. Echte Updates des komodo-Stacks laufen bis auf Weiteres manuell ueber Komodo (Inline-Compose anpassen) bzw. spaeter via Migration auf git-backed (eigener Aenderungsblock).
| Ignore-Pfade | `_archive`, `ops/grafana-influxdb`, `ops/loki` | Renovate scant alte/abgeloeste Stacks nicht |
## Aktueller Betriebsstand
docs/REPO_MAP.md
-2
View File
@@ -34,8 +34,6 @@ Details gilt immer die betroffene Compose-Datei oder das jeweilige Runbook.
| `docs/SECRETS_MAP.md` | Secret-Namen und Pfade ohne Werte |
| `docs/GITOPS_DRIFT_RUNBOOK.md` | Git/Gitea/Komodo/Docker/Host-Drift |
| `docs/AUDIT_2026-05-25_TODO.md` | aktuelle Restliste |
| `docs/DR_WORKSTATION_SETUP.md` | Schritt-fuer-Schritt-Runbook fuer den DR-Gaming-PC (WSL2 + Borg-Client + SSH-Keys) |
| `docs/runbooks/komodo-bulk-deploy-dns.md` | Bulk-Deploy-Pulls scheitern an DNS, wenn AdGuard im selben Batch recreated wird |
## Wichtige Skripte
docs/RESTORE_HANDBOOK.md
+46 -90
View File
@@ -1,6 +1,6 @@
# Restore Handbook - KalliLab CORE
Stand: 2026-06-03
Stand: 2026-05-07
Dieses Handbuch ist die praktische Betriebsanleitung fuer Restore-Checks und Restore-Lab in KalliLab CORE.
@@ -41,36 +41,28 @@ Alle validierten Restore-Tests folgen demselben Muster:
### Vaultwarden
- Erstlauf: 2026-05-07
- Nachweis: Borg-Restore, Testcontainer, Login-Seite erreichbar
- Report: `/mnt/user/backups/restore-reports/vaultwarden-2026-05-07.md`
- Nachweis:
- Borg-Restore erfolgreich
- Testcontainer startete
- Login-Seite war erreichbar
### Gitea
- Erstlauf: 2026-05-07
- Nachweis: Borg-Restore, Web-UI, SSH-TCP-Port
- Report: `/mnt/user/backups/restore-reports/gitea-2026-05-07.md`
- Nachweis:
- Borg-Restore erfolgreich
- Web-UI antwortete
- SSH-Port reagierte
### Paperless
- Erstlauf: 2026-05-07, Folgelauf: 2026-05-31
- Nachweis: Borg-Datei-Restore, Dump-Import in Test-Postgres, Login-Seite, Doc-Count
### Immich
- Erstlauf: 2026-05-27
- Nachweis: DB-Dump-Restore in VectorChord-Test-Postgres, HTTP-Smoke, Asset-Count
- Hinweis: Foto-Dateien-Restore ist bewusst nicht Teil des Smokes
### Authelia
- Erstlauf: 2026-06-03
- Nachweis: Config-Borg-Restore, `authelia config validate`, HTTP-Health `/api/health`
- Hinweis: Daten-Restore des produktiven Dumps ist bewusst nicht Teil des Smokes (Storage-Encryption-Key-Kopplung)
### Komodo Bootstrap
- Erstlauf: 2026-05-30
- Nachweis: Compose-Validierung, Mongo healthy, Core HTTP, Periphery running
- Hinweis: Daten-Restore aus `komodo-mongo.archive.gz` ist noch nicht getestet
- Report: `/mnt/user/backups/restore-reports/paperless-2026-05-07.md`
- Nachweis:
- Borg-Datei-Restore erfolgreich
- Paperless-Dump aus Borg importiert
- Login-Seite war erreichbar
- Test-DB enthielt `25` Dokumente
---
@@ -88,10 +80,6 @@ Alle validierten Restore-Tests folgen demselben Muster:
- `/mnt/user/backups/restore-lab/vaultwarden`
- `/mnt/user/backups/restore-lab/gitea`
- `/mnt/user/backups/restore-lab/paperless`
- `/mnt/user/backups/restore-lab/immich`
- `/mnt/user/backups/restore-lab/authelia`
- `/mnt/user/backups/restore-lab/komodo`
- `/mnt/user/backups/restore-lab/_failed` (Diagnose-Material bei Fehllaeufen)
### Reports
@@ -101,33 +89,31 @@ Alle validierten Restore-Tests folgen demselben Muster:
## 5. Restore-Frequenz
- jeden Montag, 06:30: Frische-Check fuer Dumps und Reports
- 1. Samstag im Monat, 07:00: Vaultwarden
- 3. Samstag im Monat, 07:15: Gitea
- 2. Samstag in ungeraden Monaten, 08:00: Paperless
- 2. Sonntag in Feb/Mai/Aug/Nov, 08:30: Immich
- 2. Samstag in geraden Monaten, 07:30: Authelia
- 1. Kalendertag im Monat, 09:00: Zufaelliger Restore aus Pool
Vollstaendiger Kalender mit Cron-Ausdruecken und Shell-Guards steht in `ops/restore-tests/schedule.md`.
- jeden Montag, 06:30:
- Frische-Check fuer Dumps und Reports
- 1. Samstag im Monat, 07:00:
- Vaultwarden
- 3. Samstag im Monat, 07:00:
- Gitea
- jeder 2. Monat, 2. Samstag, 08:00:
- Paperless
---
## 6. Betriebsmodus
## 6. Betriebsmodi
Stand 2026-06-03 ist der Betrieb auf V1+ (V1 mit ntfy):
### V1
- validierte Bash-Host-Jobs fuer Vaultwarden, Gitea, Paperless, Immich, Authelia, Komodo-Bootstrap
- Host-Job-Definitionen und Cron-Vorlagen liegen im Repo (`ops/restore-tests/unraid-user-scripts.md`)
- `ntfy`-Wrapper sendet Erfolg an `homelab-info`, Fehler an `homelab-alerts`
- Frische-Check prueft zusaetzlich pg-Custom-Format-Dumps per `pg_restore --list` Header-Validierung
- bei Fehlschlag wird das Restore-Lab nach `_failed/` verschoben statt geloescht
- validierte Bash-Host-Jobs
- Host-Job-Definitionen liegen im Repo
- Scheduler kann bereits echte Frische- und Restore-Checks fahren
- `ntfy` und Hermes-Auswertung folgen danach
Noch geplant fuer V2:
### V2
- Hermes-Zusammenfassung ueber vorhandene Reports
- Sammelreports und Report-Rotation
- weitere Dienste (Nextcloud, Mailarchiver, Mealie)
- `ntfy` bei Erfolg/Fehler
- Hermes liest Reports und baut Uebersichten
- zusaetzliche Rotation, Sammelreports und weitere Dienste
---
@@ -140,18 +126,15 @@ Die Vorlagen stehen in:
Host-Repo-Pfad:
```text
/mnt/user/services/homelab-infra
/mnt/user/services/homelab
```
Jobs:
V1-Jobs:
1. `restore-freshness-weekly`
2. `restore-vaultwarden-monthly`
3. `restore-gitea-monthly`
4. `restore-paperless-bimonthly`
5. `restore-immich-quarterly`
6. `restore-authelia-bimonthly`
7. `monthly-random-restore`
---
@@ -186,65 +169,38 @@ Nur `Container laeuft` reicht nicht.
Auf dem Unraid-Host:
```bash
bash /mnt/user/services/homelab-infra/ops/restore-tests/run-restore-checks.sh freshness
bash /mnt/user/services/homelab/ops/restore-tests/run-restore-checks.sh freshness
```
### Vaultwarden Restore-Check
```bash
bash /mnt/user/services/homelab-infra/ops/restore-tests/run-restore-checks.sh vaultwarden
bash /mnt/user/services/homelab/ops/restore-tests/run-restore-checks.sh vaultwarden
```
### Gitea Restore-Check
```bash
bash /mnt/user/services/homelab-infra/ops/restore-tests/run-restore-checks.sh gitea
bash /mnt/user/services/homelab/ops/restore-tests/run-restore-checks.sh gitea
```
### Paperless Restore-Check
```bash
bash /mnt/user/services/homelab-infra/ops/restore-tests/run-restore-checks.sh paperless
```
### Immich Restore-Check
```bash
bash /mnt/user/services/homelab-infra/ops/restore-tests/run-restore-checks.sh immich
```
### Authelia Restore-Check
```bash
bash /mnt/user/services/homelab-infra/ops/restore-tests/run-restore-checks.sh authelia
```
### Komodo Bootstrap Trockenlauf
```bash
bash /mnt/user/services/homelab-infra/ops/restore-tests/run-restore-checks.sh komodo-bootstrap
bash /mnt/user/services/homelab/ops/restore-tests/run-restore-checks.sh paperless
```
### Optional mit `ntfy`
```bash
bash /mnt/user/services/homelab-infra/ops/restore-tests/run-restore-job-with-ntfy.sh freshness homelab-info
bash /mnt/user/services/homelab/ops/restore-tests/run-restore-job-with-ntfy.sh freshness homelab-info
```
---
## 11. Naechste Ausbaustufen
1. Nextcloud-Restore-Test (mit `occ maintenance:mode`-Choreographie)
2. Mailarchiver-Restore-Test
3. Mealie-Restore-Test
4. Komodo-Mongo-Daten-Restore (echtes `mongorestore` statt reinem Bootstrap)
5. Shared-PostgreSQL-18-Cluster-Restore-Drill (globals + per-DB-Dumps)
6. Traefik-Restore-Test (mit `dynamic/` und LE-State)
7. Hermes-Zusammenfassung ueber vorhandene Reports
8. Report-Rotation (archivieren nach 12 Monaten)
9. Negativ-Test: bewusst kaputten Dump in den Frische-Check einfuettern
## 12. Report-Aufbewahrung
Reports unter `/mnt/user/backups/restore-reports` werden dauerhaft aufbewahrt. Bei wachsender Anzahl (ca. 50-60 pro Jahr) empfiehlt sich eine jaehrliche Archivierung alter Reports in einen Unterordner `_archive/YYYY/`. Der Frische-Check warnt bei `MAX_REPORT_AGE_DAYS=45`, loescht aber bewusst nicht automatisch.
1. Vollautomatik fuer Vaultwarden, Gitea und Paperless
2. `ntfy`-Meldungen fuer Erfolg/Fehler
3. Hermes-Zusammenfassung ueber vorhandene Reports
4. naechster Referenz-Restore fuer `mail-archiver` oder `mealie`
docs/RESTORE_MATRIX.md
+18 -223
View File
@@ -28,23 +28,15 @@ Sie ist die fachliche Ergaenzung zu `docs/DISASTER_RECOVERY.md`.
|---|---|---|---|---|---|---|
| Unraid OS Flash | Borg-Artefakt + optional Unraid Connect | `/boot/config` aus `unraid-flash-config.tar.gz` | `unraid-flash-config.tar.gz`, `.sha256`, Manifest | enthaelt sensible Host-Konfiguration, wie Secret-Material behandeln | Unraid USB Flash Creator / neuer Boot-Stick | Unraid bootet, Array-Zuordnung und Shares sind sichtbar |
| Traefik | Share / Borg | `/mnt/user/appdata/traefik`, besonders `dynamic/`, `letsencrypt`, `secrets` | keine eigene DB | `cloudflare_dns_api_token` | `frontend_net`, `backend_net` | `https://traefik.kaleschke.info` erreichbar, Dashboard ueber Authelia |
| AdGuard Home | Share / Borg | `/mnt/user/appdata/adguard/conf` | keine | keine zusaetzlichen Repo-Secrets dokumentiert | `dns_net`, `frontend_net` | DNS-Aufloesung funktioniert; Restore-Smoke am 2026-06-06 erfolgreich |
| Tailscale | Flash-Backup (funktional) / Share | **Funktional: `/boot/config/plugins/tailscale/state`** (native Unraid-Plugin-Instanz `kallilabcore`, Subnet-Router, im Flash-Backup gesichert). Der frueher hier genannte Pfad `/mnt/user/appdata/tailscale` gehoert zum **userspace-only Docker-Stack** `kallilab-core` (redundant, Abbau geplant — siehe `docs/NETWORK_INVENTORY.md`) | keine | Tailscale-State im jeweiligen State-Pfad | Host-Netz | Tailscale verbunden, Subnet-Route `192.168.178.0/24` aktiv |
| PostgreSQL 18 | Share + Dumps | `/mnt/user/appdata/postgresql18` (archivierter Rollback-Altstand: `/mnt/user/appdata/_archive/pg18-immich-rollback-volumes-20260602/postgresql17`) | `postgresql17-globals.sql`, `postgresql17-mailarchiver.dump`, `postgresql17-paperless.dump`, optional `postgresql17-authelia.dump` | `postgres_password.txt`, App-Rollen-Passwoerter aus den jeweiligen Stack-ENV/Secret-Dateien | `backend_net` | DB startet, Ziel-Datenbanken vorhanden; `SHOW data_checksums` ist `on` |
| Redis 8 | Share / Host | `/mnt/user/appdata/redis`; Rollback-Backup unter `/mnt/user/backups/borg/dumps/latest/shared-redis-pre-redis8-<ts>` | RDB/AOF-Dateien im Datenpfad | `redis_password.txt` | `backend_net` | Redis startet, `redis_version` ist 8.x, Apps verbinden sich; Restore-Smoke am 2026-06-06 erfolgreich |
| Authelia | Borg | `/mnt/user/appdata/authelia/config`, `/mnt/user/appdata/secrets/*authelia*` | Shared PostgreSQL 18, optional Dump `postgresql17-authelia.dump` | JWT/Session/Storage/Postgres-/SMTP-Secret-Dateien | PostgreSQL 18, Traefik, GMX SMTP | Login-Seite und ForwardAuth funktionieren; SMTP-Notifier startet; aktive Sessions werden nach Restart neu aufgebaut; Restore-Smoke am 2026-06-03 erfolgreich: Config aus Borg, minimale Test-Config, frisches Test-Postgres, HTTP `/api/health` 200, Report `/mnt/user/backups/restore-reports/authelia-2026-06-03.md` |
| AdGuard Home | Share / Borg | `/mnt/user/appdata/adguard/conf` | keine | keine zusaetzlichen Repo-Secrets dokumentiert | `dns_net`, `frontend_net` | DNS-Aufloesung funktioniert |
| Tailscale | Share / Borg | `/mnt/user/appdata/tailscale` | keine | Tailscale-State im Pfad | Host-Netz | Tailscale verbunden |
| PostgreSQL 18 | Share + Dumps | `/mnt/user/appdata/postgresql18` (Rollback-Altstand: `/mnt/user/appdata/postgresql17`) | `postgresql17-globals.sql`, `postgresql17-mailarchiver.dump`, `postgresql17-paperless.dump`, optional `postgresql17-authelia.dump` | `postgres_password.txt`, App-Rollen-Passwoerter aus den jeweiligen Stack-ENV/Secret-Dateien | `backend_net` | DB startet, Ziel-Datenbanken vorhanden; `SHOW data_checksums` ist `on` |
| Redis 8 | Share / Host | `/mnt/user/appdata/redis`; Rollback-Backup unter `/mnt/user/backups/borg/dumps/latest/shared-redis-pre-redis8-<ts>` | RDB/AOF-Dateien im Datenpfad | `redis_password.txt` | `backend_net` | Redis startet, `redis_version` ist 8.x, Apps verbinden sich |
| Authelia | Borg | `/mnt/user/appdata/authelia/config`, `/mnt/user/appdata/secrets/*authelia*` | Shared PostgreSQL 18, optional Dump `postgresql17-authelia.dump` | JWT/Session/Storage/Postgres-/SMTP-Secret-Dateien | PostgreSQL 18, Traefik, GMX SMTP | Login-Seite und ForwardAuth funktionieren; SMTP-Notifier startet; aktive Sessions werden nach Restart neu aufgebaut |
| Gitea | GitHub-Mirror + Gitea-Bundles fuer Repo-Bootstrap, Borg + Dump fuer Gitea-Appstate | `/mnt/user/services/gitea/data`, `/mnt/user/backups/git-bundles/gitea` | `gitea.sqlite.dump`, Bundle-Report `latest-report.md` | `borg_repo_passphrase.txt` fuer Restore-Tests; GitHub-Push-Mirror-PAT liegt nur in Gitea-Mirror-Settings | Traefik | Web-UI erreichbar, Repo sichtbar, SSH-Port reagiert; Bundle laesst sich klonen und `git fsck` ist sauber; GitHub-Push-Mirror synchronisiert ohne `last_error`; Mini-Restore nach `/mnt/user/backups/restore-lab/gitea` am 2026-05-07 erfolgreich validiert |
| Komodo | Borg / Share | `/mnt/user/appdata/komodo/core`, `/mnt/user/appdata/komodo/periphery`, `/mnt/user/services/stacks` | `komodo-mongo.archive.gz` falls verifiziert | `komodo_mongo_password.txt`, `KOMODO_*` Stack ENV | Traefik, Mongo, Gitea | UI erreichbar, Periphery verbunden |
| GitOps Host Automation | Borg / Git | `/mnt/user/services/homelab-infra`, `/mnt/user/services/posture-check` | keine eigene DB | keine | Gitea, Komodo, Unraid User Scripts | `posture-check` laeuft vom Host-Pfad und liefert `warning_count: 0` im bekannten Uebergangszustand |
| Vaultwarden | Borg + Dump | `/mnt/user/appdata/vaultwarden` | `vaultwarden.sqlite.dump` | `vaultwarden_admin_token.txt` fuer Produktion; Restore-Test nutzt Wegwerf-Admin-Token und `borg_repo_passphrase.txt` | Traefik | Login-Seite erreichbar, Tresor-Daten sichtbar; Mini-Restore nach `/mnt/user/backups/restore-lab/vaultwarden` am 2026-05-07 erfolgreich validiert |
---
## Workstations
| System | Fuehrende Quelle | Datei-Restore | Dump / DB | Secrets / ENV | Abhaengigkeiten | Smoke-Test |
|---|---|---|---|---|---|---|
| `baerchen` Windows 11 | Veeam Agent Image auf Unraid-SMB | `/mnt/user/backups/windows-images/baerchen/` bzw. `\\kallilabcore\backups\windows-images\baerchen` | Veeam Restore Points im Zielordner; erster Full-Lauf 2026-06-05, GUI-Groesse 53,8 GB, Dauer 0:11:31, MetaCheck 0 Fehler/0 Warnungen | SMB-User `micha`; Veeam Job Encryption Password nur noetig, falls Storage Encryption spaeter aktiviert wird; BitLocker-Recovery-Key erst noetig, wenn BitLocker spaeter aktiviert wird | Veeam Recovery USB `VEEAMRE`, SMB auf `kallilabcore`, AdGuard/DNS oder direkte IP | Recovery-Test am 2026-06-06 erfolgreich: USB-Boot, SMB-Ziel erreichbar, Restore Point sichtbar, vor echtem Restore abgebrochen; Runbook `ops/windows-reinstall/docs/windows-image-backup-baseline.md` |
| Vaultwarden | Borg + Dump | `/mnt/user/appdata/vaultwarden` | `vaultwarden.sqlite.dump` | `vaultwarden_admin_token.txt`, `borg_repo_passphrase.txt` fuer Restore-Tests | Traefik | Login-Seite erreichbar, Tresor-Daten sichtbar; Mini-Restore nach `/mnt/user/backups/restore-lab/vaultwarden` am 2026-05-07 erfolgreich validiert |
---
@@ -53,10 +45,10 @@ Sie ist die fachliche Ergaenzung zu `docs/DISASTER_RECOVERY.md`.
| Dienst | Fuehrende Quelle | Datei-Restore | Dump / DB | Secrets / ENV | Abhaengigkeiten | Smoke-Test |
|---|---|---|---|---|---|---|
| Paperless-ngx | Borg + Dumps | `/mnt/user/appdata/paperless-ngx/data`, `/mnt/user/documents/paperless`, `/mnt/user/documents/paperless/export`, `/mnt/user/documents/scans_inbox` | `postgresql17-paperless.dump` | `PAPERLESS_DBPASS`, `PAPERLESS_REDIS`, `borg_repo_passphrase.txt` fuer Restore-Tests | PostgreSQL 18, Redis, Traefik | Web-UI startet, Dokumente vorhanden; Restore-Test am 2026-05-31 erfolgreich: Borg-Archiv `Tägliche-Sicherung-2026-05-31T04:30:13.181`, isolierter PostgreSQL-18-/Redis-8-Testpfad, HTTP `200`, `32` Dokumente im Test-DB-Check, Report `/mnt/user/backups/restore-reports/paperless-2026-05-31.md` |
| Mealie | Borg + Dump | `/mnt/user/appdata/mealie/data`, `/mnt/user/appdata/mealie/postgres18` (archivierter Rollback-Altstand: `/mnt/user/appdata/_archive/pg18-immich-rollback-volumes-20260602/mealie-postgres17`) | `mealie.dump` | `mealie_postgres_password.txt` | `mealie-postgres`, Traefik | UI startet, Rezepte vorhanden |
| Immich | Borg + Dump | `/mnt/user/photos/immich`, `/mnt/user/photos/family_archive`, `/mnt/user/appdata/immich_postgres_vectorchord`; archivierter Rollback-Altstand: `/mnt/user/appdata/_archive/pg18-immich-rollback-volumes-20260602/immich-postgres-pgvecto-rs` | `immich.dump`; nach VectorChord braucht ein Restore ein Postgres-Image mit VectorChord | `IMMICH_DB_PASSWORD`, `immich_postgres_password.txt`, `borg_repo_passphrase.txt` fuer Restore-Tests | `immich_postgres`, `immich_redis`, Traefik | DB- und UI-Smoke gegen produktives Borg-Archiv am 2026-05-27 erfolgreich validiert; VectorChord-Migration am 2026-05-31: `11977` Assets, `11107` Smart-Search-Zeilen, `7092` Face-Search-Zeilen, `vchord 0.4.3`, `vector 0.8.1`, HTTP/API-Smoke 200. Voll-Restore der Foto-Dateien bleibt separater DR-Drill |
| Mealie | Borg + Dump | `/mnt/user/appdata/mealie/data`, `/mnt/user/appdata/mealie/postgres18` (Rollback-Altstand: `/mnt/user/appdata/mealie/postgres`) | `mealie.dump` | `mealie_postgres_password.txt` | `mealie-postgres`, Traefik | UI startet, Rezepte vorhanden |
| Immich | Borg + Dump | `/mnt/user/photos/immich`, `/mnt/user/photos/family_archive`, `/mnt/user/appdata/immich_postgres_vectorchord`; Rollback-Altstand: `/mnt/user/appdata/immich_postgres` | `immich.dump`; nach VectorChord braucht ein Restore ein Postgres-Image mit VectorChord | `IMMICH_DB_PASSWORD`, `immich_postgres_password.txt`, `borg_repo_passphrase.txt` fuer Restore-Tests | `immich_postgres`, `immich_redis`, Traefik | DB- und UI-Smoke gegen produktives Borg-Archiv am 2026-05-27 erfolgreich validiert; VectorChord-Migration am 2026-05-31: `11977` Assets, `11107` Smart-Search-Zeilen, `7092` Face-Search-Zeilen, `vchord 0.4.3`, `vector 0.8.1`, HTTP/API-Smoke 200. Voll-Restore der Foto-Dateien bleibt separater DR-Drill |
| Mail-Archiver | Borg + Shared Dump | `/mnt/user/appdata/mailarchiver/data-protection-keys` | `postgresql17-mailarchiver.dump` | `MAILARCHIVER_DB_CONNECTION`, `MAILARCHIVER_AUTH_PASSWORD` | PostgreSQL 18, Traefik, Authelia | Authelia-Weiterleitung greift; nach Login startet die Web-UI und das Archiv laesst sich oeffnen |
| Nextcloud | Borg + Dump | `/mnt/user/appdata/nextcloud/html`, `/mnt/user/documents/nextcloud-data`, `/mnt/user/appdata/nextcloud/postgres18` (archivierter Rollback-Altstand: `/mnt/user/appdata/_archive/pg18-immich-rollback-volumes-20260602/nextcloud-postgres17`), `/mnt/user/appdata/nextcloud/redis` | `nextcloud.dump`; Redis-Backup vor Redis-8-Cutover unter `/mnt/user/backups/borg/dumps/latest/nextcloud-redis-pre-redis8-<ts>` | `nextcloud_admin_user.txt`, `nextcloud_admin_password.txt`, `nextcloud_postgres_password.txt`; produktive DB-Rolle laut `config.php` ist `oc_admin` | `nextcloud-postgres`, `nextcloud-redis`, Traefik | Web-UI startet, Login funktioniert, Dateien sichtbar; `occ status` zeigt `maintenance: false` |
| Nextcloud | Borg + Dump | `/mnt/user/appdata/nextcloud/html`, `/mnt/user/documents/nextcloud-data`, `/mnt/user/appdata/nextcloud/postgres18` (Rollback-Altstand: `/mnt/user/appdata/nextcloud/postgres`), `/mnt/user/appdata/nextcloud/redis` | `nextcloud.dump`; Redis-Backup vor Redis-8-Cutover unter `/mnt/user/backups/borg/dumps/latest/nextcloud-redis-pre-redis8-<ts>` | `nextcloud_admin_user.txt`, `nextcloud_admin_password.txt`, `nextcloud_postgres_password.txt`; produktive DB-Rolle laut `config.php` ist `oc_admin` | `nextcloud-postgres`, `nextcloud-redis`, Traefik | Web-UI startet, Login funktioniert, Dateien sichtbar; `occ status` zeigt `maintenance: false` |
| Glance | Git / Borg-Repo | Repo-Konfiguration unter `ops/glance/config/glance.yml`; keine kritische Datenpersistenz | keine | `GLANCE_IMMICH_API_KEY`, `GLANCE_ADGUARD_USERNAME`, `GLANCE_ADGUARD_PASSWORD`, `GLANCE_SPEEDTEST_API_KEY` | Traefik, Authelia, optional interne API-Ziele | Dashboard startet, Widgets laden, Docker-Status laeuft nur ueber `glance-docker-socket-proxy` |
| ntfy | Borg / Share | `/mnt/user/appdata/ntfy` | keine | keine besonderen Secret-Dateien dokumentiert | Traefik | UI und Push-Endpunkt erreichbar |
| Paperless-GPT | Borg / Share | `/mnt/user/appdata/paperless-gpt` | keine eigene DB | `PAPERLESS_API_TOKEN`, `OPENAI_API_KEY` | Traefik, Paperless, OpenAI API | UI startet, Konfiguration vorhanden; LLM-Provider zeigt `openai` / `gpt-5.4-mini` |
@@ -108,10 +100,10 @@ Die Dump-Erzeugung ist host-seitig ueber `ops/borg-ui/scripts/pre-backup-dumps.s
### PostgreSQL 18 Restore- und Rollback-Regeln
- PostgreSQL-18-Container verwenden das Docker-Image-Layout mit Mount auf `/var/lib/postgresql` und `PGDATA=/var/lib/postgresql/18/docker`.
- Die alten PostgreSQL-17-Datenpfade wurden nach Burn-in am 2026-06-02 aus den aktiven Appdata-Pfaden entfernt und unter `/mnt/user/appdata/_archive/pg18-immich-rollback-volumes-20260602` archiviert.
- Die alten PostgreSQL-17-Datenpfade bleiben nach dem Major-Upgrade als Rollback-Altstand erhalten und duerfen erst nach separater Freigabe geloescht werden.
- Shared-Cluster-Restore: zuerst `pg_dumpall --globals-only` einspielen, dann die einzelnen Custom-Format-Dumps per `pg_restore`. Der Bootstrap-Rollenkonflikt fuer `mailarchiver` ist benign, solange `CREATE ROLE mailarchiver;` gezielt ausgelassen und das folgende `ALTER ROLE mailarchiver ...` eingespielt wird.
- Nextcloud-Restore: vor dem Dump `occ maintenance:mode --on`, nach erfolgreichem Restore und `occ status` wieder `occ maintenance:mode --off`. Die Rolle `oc_admin` muss mit dem in `config.php` hinterlegten DB-Passwort existieren.
- Rollback: betroffene App(s) und DB stoppen, archivierten Altstand zurueck an den frueheren Datenpfad verschieben, Compose auf das vorherige PostgreSQL-17-Image und den alten Datenpfad zuruecksetzen, dann DB und App wieder starten.
- Rollback: betroffene App(s) und DB stoppen, Compose auf das vorherige PostgreSQL-17-Image und den alten Datenpfad zuruecksetzen, dann DB und App wieder starten.
---
@@ -133,210 +125,13 @@ Die Dump-Erzeugung ist host-seitig ueber `ops/borg-ui/scripts/pre-backup-dumps.s
---
## Restore-Test-Reifegrad
## Erste sinnvolle Referenz-Restores
Stand 2026-06-06. Pro Dienst auf einen Blick: Wurde der Restore schon einmal real getestet?
Wenn weitere Restore-Uebungen dokumentiert werden sollen, sind diese Dienste besonders geeignet:
| Dienst | Tier | Letzter Restore-Test | Typ | Naechster Lauf |
|---|---|---|---|---|
| Vaultwarden | 1 | 2026-05-07 | File + Container + HTTP | monatlich (1. Sa) |
| Gitea | 1 | 2026-05-07 | File + Container + HTTP + TCP | monatlich (3. Sa) |
| Authelia | 1 | 2026-06-03 | Config + Validate + HTTP Health | zweimonatlich (2. Sa gerade Mon.) |
| Komodo Bootstrap | 1 | 2026-05-30 | Compose + Mongo + HTTP | quartalsweise |
| Paperless | 2 | 2026-05-31 | File + Dump + Container + HTTP + Doc-Count | zweimonatlich (2. Sa ungerade Mon.) |
| Immich | 2 | 2026-05-27 | Dump + Container + HTTP + Asset-Count | quartalsweise (2. So Feb/Mai/Aug/Nov) |
| Unraid OS Flash | 1 | 2026-06-05 (Artefakt-Validierung) | sha256 OK + 390 Eintraege + 8 Kern-Configs vorhanden (`ops/maintenance/check-unraid-flash-backup.sh`); **physischer Ersatzstick-Boot-Test weiter offen** | Stick-Boot-Test nach Bedarf |
| Traefik | 1 | 2026-06-03 | Config + LE-State + File-Provider + Ping 200 | quartalsweise |
| AdGuard Home | 1 | 2026-06-06 | Config + Container + HTTP 401 + DNS + Filter-Count | quartalsweise oder nach DNS-Aenderungen |
| Tailscale | 1 | - | noch kein Test | - |
| PostgreSQL 18 Cluster | 1 | 2026-06-03 | globals + 5 per-DB dumps, 290 Tabellen gesamt | quartalsweise |
| Redis 8 | 1 | 2026-06-06 | Pre-Cutover-Artefakt + Container + PING + INFO + DBSIZE | quartalsweise oder vor/nach Redis-Major-Aenderungen |
| Komodo Mongo Daten | 1 | 2026-06-03 | mongorestore --archive --gzip, 86904 docs | quartalsweise |
| Nextcloud | 2 | 2026-06-03 | File + Dump + Container + HTTP 200 + occ status + Table-Count (126) | quartalsweise |
| Mealie | 2 | 2026-06-03 | File + Dump + Container + HTTP + Recipe-Count (3) | quartalsweise |
| Mail-Archiver | 2 | 2026-06-03 | Keys + 645M Dump + Container + HTTP 200 | quartalsweise |
| Glance | 2 | - | rebuildbar, kein Test noetig | - |
| ntfy | 2 | - | rebuildbar, kein Test noetig | - |
| Borg UI | 3 | - | rebuildbar | - |
| Filebrowser | 3 | - | rebuildbar | - |
| baerchen Windows Image | Workstation | 2026-06-06 | Full-Backup geschrieben; Recovery-USB-Boot, SMB-Mount und Restore-Point-Sichtpruefung erfolgreich; vor echtem Restore abgebrochen | nach Image-Aenderungen oder quartalsweise |
1. `mail-archiver`
2. `paperless-ngx`
3. `gitea`
4. `vaultwarden`
---
## Naechste Restore-Test-Kandidaten (priorisiert)
Stand 2026-06-06. Die frueheren Kandidaten (Shared PG18, Komodo Mongo, Mailarchiver, Mealie, Traefik)
wurden alle am 2026-06-03 abgeschlossen und sind in der Reifegrad-Tabelle belegt.
Verbleibende offene Restore-Pfade ohne vollstaendigen Test:
1. **Unraid OS Flash** - Artefakt-Validierung am 2026-06-05 erfolgreich (siehe Reifegrad-Tabelle und Runbook unten); offen bleibt nur der **physische Ersatzstick-Boot-Test**.
2. **Tailscale** - State-/Reconnect-Pfad dokumentiert testen
---
## Restore-Test-Runbooks (Entwurf)
Diese Abschnitte sind vorbereitete Checklisten fuer die noch untesteten Restore-Pfade.
Sie sind **nicht** als produktive Anleitungen zu verwenden, bevor ein erster Testlauf
die konkreten Artefaktnamen und Pfade bestaetigt hat.
### Unraid OS Flash
**Voraussetzungen:**
- Borg-Artefakt `unraid-flash-config.tar.gz` und `unraid-flash-config.tar.gz.sha256` unter `/mnt/user/backups/borg/dumps/latest` oder im Hetzner-Borg-Repo verfuegbar
- Neuer leerer USB-Stick (Empfehlung: 16 GB, USB 2.0 kompatibel)
- Unraid USB Flash Creator oder manueller Restore-Pfad
- Offline-gesicherte Borg-Passphrase verfuegbar
**Checkliste Artefakt-Validierung (ohne produktiven Stick):**
Automatisiert via Repo-Skript `ops/maintenance/check-unraid-flash-backup.sh`
(read-only, keine Extraktion). Manuelle Einzelschritte:
1. SHA256-Pruefung: `sha256sum -c unraid-flash-config.tar.gz.sha256`
2. Artefakt-Inhalt pruefen: `tar -tzf unraid-flash-config.tar.gz | head -40` — erwartet `config/` als Prefix
3. Kern-Configs vorhanden: `super.dat`, `disk.cfg`, `ident.cfg`, `share.cfg`, `network.cfg`, `docker.cfg`, `go`, `domain.cfg`
4. Keine produktiven Konfigurationspfade (z. B. `config/ssh/`) ausserhalb des Test-Environments extrahieren
5. Manifest-Datei auf Vollstaendigkeit pruefen
**Validierungsergebnis 2026-06-05 (read-only per SSH):** Artefakt frisch
(2026-06-05 04:00, ~16 h alt beim Test), `sha256sum -c` = OK, 390 Eintraege,
alle 8 Kern-Configs vorhanden. Das Archiv enthaelt erwartungsgemaess
Secret-Material (SSH-Host-Keys, Tailscale-State, `passwd`/`shadow`/`smbpasswd`,
`Trial.key`) und ist wie Secret-Backup zu behandeln. Es wurde nichts extrahiert,
nur Eintragsnamen gelistet. Offen bleibt der physische Ersatzstick-Boot-Test.
**Checkliste vollstaendiger Restore-Test (auf Wegwerf-Stick):**
1. Neuen USB-Stick mit Unraid USB Flash Creator formatieren und Basis-Unraid draufspielen
2. `config/`-Verzeichnis aus `unraid-flash-config.tar.gz` in den `/boot/config`-Pfad des neuen Sticks extrahieren
3. Im Testrahmen booten (kein Array starten, keine Shares mounten)
4. Pruefen: Unraid-Grundkonfiguration (Shares, Hostname, Netzwerk) ist sichtbar
5. Array-Zuordnung lesbar, ohne Drive-Assigns zu bestaetigen
**Smoke-Test-Kriterium:** Unraid bootet, Hostname ist `Kallilabcore`, Share-Konfiguration ist sichtbar, kein Array gestartet.
**Sonderregel:** Das Artefakt enthaelt Host-Konfiguration und SSH-Keys und ist wie Secret-Material zu behandeln. Nicht auf oeffentlichen oder unverschluesselten Testzielen extrahieren.
---
### AdGuard Home
**Validierungsergebnis 2026-06-06:** Automatisierter Test
`ops/restore-tests/adguard-restore-test.sh` auf Unraid erfolgreich ausgefuehrt.
Report: `/mnt/user/backups/restore-reports/adguard-2026-06-06.md`.
Getestet wurden Borg-Extract der Config, `AdGuardHome.yaml`-Struktur,
isolierter Testcontainer `restoretest-adguard` auf localhost-Ports,
HTTP `/control/status` = `401`, DNS-Smoke `git.kaleschke.info -> 192.168.178.58`,
7 Filterlisten-Eintraege. Testdaten wurden nach Erfolg bereinigt.
**Voraussetzungen:**
- Borg-Archiv mit `/mnt/user/appdata/adguard/conf` zugaenglich (produktives Repo oder Teststand)
- Testpfad unter `/mnt/user/backups/restore-lab/adguard` vorbereitet
- Docker-Faehigkeit auf dem Testhost oder in der Restore-Lab-Umgebung
**Automatisierter Test:**
```bash
/mnt/user/services/homelab-infra/ops/restore-tests/run-restore-checks.sh adguard
```
**Manuelle Checkliste:**
1. Borg-Extract des letzten Archivs nach `/mnt/user/backups/restore-lab/adguard/conf`:
```
borg extract ::ARCHIV /mnt/user/appdata/adguard/conf
```
2. Konfigurationsdatei `AdGuardHome.yaml` auf Vollstaendigkeit pruefen (YAML-Syntax valide)
3. Testcontainer starten (kein produktiver DNS-Port 53, stattdessen z. B. `15353`):
```yaml
ports:
- "127.0.0.1:15353:53/udp"
- "127.0.0.1:13001:80/tcp"
volumes:
- /mnt/user/backups/restore-lab/adguard/conf:/opt/adguardhome/conf
```
4. `http://127.0.0.1:13001/control/status` erreichbar (`200`, `401` oder `403` sind fuer den Smoke ausreichend)
5. DNS-Aufloesung: `dig @127.0.0.1 -p 15353 git.kaleschke.info` gibt plausible Antwort
6. Testcontainer stoppen und Testpfad aufraeumen
**Smoke-Test-Kriterium:** AdGuard-Web-UI laeuft, DNS-Aufloesung antwortet, Filterlisten sind geladen.
**Keine Secrets:** AdGuard Home verwendet keine dokumentierten Repo-Secrets; Login-Credentials liegen in der `AdGuardHome.yaml` im Borg-Archiv.
---
### Tailscale
**Voraussetzungen:**
- Borg-Archiv mit `/mnt/user/appdata/tailscale` zugaenglich
- Testpfad unter `/mnt/user/backups/restore-lab/tailscale` vorbereitet
- Achtung: Der Tailscale-State ist maschinenspezifisch. Ein Restore auf denselben produktiven Host wuerde die laufende Verbindung verdraengen. Nur auf einem Wegwerf- oder Offline-Host testen.
**Checkliste Artefakt-Validierung (ohne produktiven Host):**
1. Borg-Extract nach `/mnt/user/backups/restore-lab/tailscale`
2. State-Verzeichnis auf erwartete Dateien pruefen: `tailscaled.state` vorhanden
3. Dateisystem-Rechte pruefen: `tailscaled.state` muss fuer `root` zugaenglich sein
**Checkliste Reconnect-Test (auf Wegwerf-Host oder VM):**
1. Tailscale-Container mit dem gemounteten State-Pfad starten
2. `tailscale status` zeigt `Connected` oder den erwarteten Hostnamen
3. Tailscale-Admin-Konsole (`login.tailscale.com`) zeigt Geraet als `Online`
4. SSH ueber Tailscale-IP auf den Testhost moeglich
5. Testcontainer stoppen; Wegwerf-Geraet in der Tailscale-Admin-Konsole entfernen
**Smoke-Test-Kriterium:** Container verbindet sich mit bestehendem Tailscale-Account (kein neues Re-Auth noetig), Tailscale-IP ist erreichbar.
**Hinweis:** Falls der State veraltet ist (Key expired), wird Tailscale einen Re-Auth anfordern. Das ist ein valides Testergebnis und belegt, wie lang der Reconnect-Pfad bei abgelaufenem Key ist.
---
### Redis 8 (Shared)
**Validierungsergebnis 2026-06-06:** Automatisierter Test
`ops/restore-tests/redis-restore-test.sh` auf Unraid erfolgreich ausgefuehrt.
Report: `/mnt/user/backups/restore-reports/redis-2026-06-06.md`.
Getestet wurde das Pre-Cutover-Artefakt
`/mnt/user/backups/borg/dumps/latest/shared-redis-pre-redis8-20260531-185011`
in einer isolierten Redis-8.8-Testinstanz auf `127.0.0.1:16379`.
Ergebnis: `PING` = `PONG`, `redis_version` = `8.8.0`, AOF aktiv (`1`),
`DBSIZE` = `1`. Produktiver Port und produktiver Datenpfad wurden nicht genutzt.
**Voraussetzungen:**
- Pre-Cutover-Backup unter `/mnt/user/backups/borg/dumps/latest/shared-redis-pre-redis8-<ts>` vorhanden, oder Borg-Archiv mit `/mnt/user/appdata/redis`
- Secret-Datei `redis_password.txt` fuer Testinstanz verfuegbar (aus Borg, nicht als Wert dokumentieren)
- Testpfad unter `/mnt/user/backups/restore-lab/redis` vorbereitet
**Automatisierter Test:**
```bash
/mnt/user/services/homelab-infra/ops/restore-tests/run-restore-checks.sh redis
```
**Manuelle Checkliste:**
1. RDB/AOF-Datei aus dem Backup in den Testpfad kopieren:
```
cp /mnt/user/backups/borg/dumps/latest/shared-redis-pre-redis8-<ts>/dump.rdb \
/mnt/user/backups/restore-lab/redis/
```
(oder Borg-Extract aus dem Appdata-Archiv)
2. Testcontainer starten (kein produktiver Port 6379, stattdessen z. B. `16379`):
```yaml
ports:
- "127.0.0.1:16379:6379"
volumes:
- /mnt/user/backups/restore-lab/redis:/data
command: redis-server --requirepass <aus Secret> --appendonly yes
```
3. Verbindungstest: `redis-cli -p 16379 -a <pass> PING` antwortet `PONG`
4. Redis-Version pruefen: `redis-cli -p 16379 -a <pass> INFO server | grep redis_version` zeigt `8.x`
5. Stichprobe Key-Bestand: `redis-cli -p 16379 -a <pass> DBSIZE` zeigt plausible Zahl (nicht 0)
6. Testcontainer stoppen und Testpfad aufraeumen
**Smoke-Test-Kriterium:** Redis 8 startet mit dem Restore-Datenpfad, `PING` antwortet, `DBSIZE` ist nicht 0.
**Shared Redis Besonderheit:** Shared Redis wird produktiv nur von Paperless genutzt (AOF aktiv). Bei einem echten Restore nach App-Absturz: Erst Redis aus Backup hochziehen, dann Paperless. Nextcloud hat eigene Redis-Instanz ohne Passwort.
Sie liefern hohen Erkenntnisgewinn ohne den kompletten Homelab-Neuaufbau zu brauchen.
docs/SECRETS_MAP.md
+1 -11
View File
@@ -53,16 +53,12 @@ Dieses Dokument listet sensible Daten, deren Ablageorte und die vorgesehene Einb
| InfluxDB 3 Core | Admin Token JSON | `/mnt/user/appdata/secrets/influxdb3_admin_token.json` -> Docker Secret `/run/secrets/influxdb3_admin_token` | aktiv |
| Monitoring Grafana | Admin Password | `/mnt/user/appdata/secrets/monitoring_grafana_admin_password.txt` -> Docker Secret `/run/secrets/monitoring_grafana_admin_password` -> `GF_SECURITY_ADMIN_PASSWORD__FILE` | aktiv |
| Monitoring Grafana -> InfluxDB | Datasource Token | `/mnt/user/appdata/secrets/monitoring_grafana_influxdb_token.txt` -> Docker Secret `/run/secrets/monitoring_grafana_influxdb_token` | aktiv |
| Grafana OIDC (Authelia) | Client Secret | `/mnt/user/appdata/secrets/grafana_oidc_client_secret` (Klartext, chmod 600) -> Docker Secret `/run/secrets/grafana_oidc_client_secret` -> `GF_AUTH_GENERIC_OAUTH_CLIENT_SECRET__FILE`. Zugehoeriger pbkdf2-Hash liegt im Authelia-Host-Config-Client `grafana` (kein Wert im Repo) | aktiv (2026-06-06) |
| Mealie OIDC (Authelia) | Client Secret | Stack-ENV `${MEALIE_OIDC_CLIENT_SECRET}` in `/mnt/user/services/stacks/mealie/apps/mealie/.env` (Komodo-Stack-ENV); pbkdf2-Hash im Authelia-Host-Config-Client `mealie` (kein Wert im Repo) | aktiv (2026-06-06) |
| Home Assistant -> InfluxDB | HA InfluxDB Token | `/homeassistant/secrets.yaml` -> `influxdb3_homeassistant_token` | geplant |
| Renovate Bot | Gitea Service-Account PAT | `/mnt/user/appdata/secrets/renovate_token.txt` -> Host-Datei (chmod 600), gelesen von `ops/renovate/run-renovate.sh` und an Renovate-Container als `RENOVATE_TOKEN` weitergegeben | aktiv nach Operator-Setup (siehe `docs/RENOVATE.md`) |
| n8n | Encryption Key fuer interne Credential-Verschluesselung | `/mnt/user/appdata/secrets/n8n_encryption_key.txt` (chmod 600) -> Komodo Stack ENV `${N8N_ENCRYPTION_KEY}`; kein `_FILE`-Support im Upstream-Image | aktiv |
| n8n | GMX IMAP Login (Mail-Trigger Workflow) | n8n Credentials Store (Typ `imap`), nur in `/mnt/user/appdata/n8n/data` mit `N8N_ENCRYPTION_KEY` verschluesselt | aktiv |
| n8n | OpenAI API Key (LLM-Extraktion Workflow) | n8n Credentials Store (Typ `httpHeaderAuth`, Header `Authorization: Bearer ...`) | aktiv |
| n8n | Gitea PAT fuer `n8n-bot` (Issue-Erstellung Workflow) | n8n Credentials Store (Typ `httpHeaderAuth`, Header `Authorization: token ...`); separater Bot-User mit Scope `write:issue` auf `Micha/mails` | aktiv |
| baerchen Veeam | Veeam Job Encryption Password | Vaultwarden Secure Note `Veeam baerchen backup encryption password`; kein Datei-Secret im Repo | geplant, nur noetig falls Veeam Storage Encryption aktiviert wird |
| baerchen SMB Backup Target | SMB Credential fuer User `micha` | bestehender Unraid-/Vaultwarden-Zugang fuer Share `backups`; wird im Veeam-Job gespeichert, Wert nie dokumentieren | aktiv |
| baerchen BitLocker | BitLocker Recovery Key C: | **bewusst deaktiviert (Entscheidung 2026-06-06):** kein BitLocker, kein Recovery-Key noetig. Falls spaeter aktiviert: Key nach `D:\30_Finanzen\BitLocker-RecoveryKey-baerchen-<DATUM>.txt` + Vaultwarden Secure Note + physischer Ausdruck | nicht aktiv (bewusst) |
---
@@ -112,12 +108,6 @@ Weitere dokumentierte Secret-Pfade:
- Die Borg-Repo-Passphrase liegt zusaetzlich als Host-Secret-Datei fuer Restore-Tests und Notfallzugriff vor. Der Wert ist laut Operator-Bestaetigung vom 2026-05-26 offline gesichert; Ablageort und Wert werden nicht im Repo dokumentiert.
- Gitea verwaltet den GitHub-Push-Mirror-PAT in den Repository-Mirror-Settings. Der Wert wird nicht dokumentiert und nicht in Dateien unter `docs/` oder `core/gitea/` geschrieben.
- `paperless-ngx` ist eine bewusste Ausnahme: DB-Passwort und Redis-URL bleiben aktuell als Komodo Stack Environment Variables hinterlegt, um den stabil laufenden Produktionsstand nicht fuer eine reine Secret-Mechanik-Migration zu riskieren.
- `baerchen` nutzt fuer das Veeam-Backup aktuell den bestehenden SMB-User
`micha`. Ein dedizierter SMB-User `veeam-baerchen` ist nur ein spaeteres
Hardening-Ziel, solange keine Unraid-User-/Share-Aenderungen gewuenscht sind.
- Das Veeam-Job-Encryption-Passwort ist restore-kritisch. Ohne diesen Wert ist
das Image unter `\\kallilabcore\backups\windows-images\baerchen` nicht
brauchbar.
---
docs/SERVICE_CATALOG.md
+7 -7
View File
@@ -13,7 +13,7 @@ Secret-Werte sind nicht enthalten. Es werden nur Secret-Namen, Env-Key-Namen und
| `traefik` | zentraler Reverse Proxy, TLS, Docker-Label-Routing | `traefik/docker-compose.yml`, `traefik/dynamic/*` | `https://traefik.kaleschke.info` | Docker socket, Cloudflare DNS API, `frontend_net`, `backend_net` | `/mnt/user/appdata/traefik/dynamic`, `/mnt/user/appdata/traefik/letsencrypt` | Tier 1, Share/Borg | ja, eigene Dashboard-Route mit Authelia | Host-Ports 80/443 sind zentrale Ausnahme; dynamic configs werden nicht automatisch von Komodo deployed |
| `adguard` | DNS-Server / LAN DNS | `host-services/Adguard/docker-compose.yml` | LAN-Port `53`, Admin `100.80.98.33:8082` | `dns_net`, `frontend_net`, Unbound | `/mnt/user/appdata/adguard/conf`, `/mnt/user/appdata/adguard/work` | Tier 1, config relevant | nein | Direkter DNS-Port 53 bleibt; Admin-Port ist bewusst ohne Traefik/2FA, aber auf Tailscale-IP begrenzt (Operator-Entscheidung 2026-05-26) |
| `unbound` | Upstream DNS Resolver fuer AdGuard | `apps/unbound/docker-compose.yml` | intern | `dns_net` | `/mnt/user/appdata/unbound/config` | rebuildbar / config relevant | nein | intern isoliert |
| `tailscale` | VPN/Remote-Zugang, Subnet-Router | **Natives Unraid-Plugin** `tailscale.plg` (nicht repo-/Komodo-verwaltet) | Tailscale | Host-Netz (`tailscale1`) | `/boot/config/plugins/tailscale/state` (im Flash-Backup) | Tier 1, State relevant | nein | Subnet-Router `192.168.178.0/24`; redundanter Docker-Stack `host-services/tailscale/` am 2026-06-06 entfernt |
| `tailscale` | VPN/Remote-Zugang | `host-services/tailscale/docker-compose.yml` | Tailscale | Host-Netz | `/mnt/user/appdata/tailscale` | Tier 1, State relevant | nein | `network_mode: host`, `NET_ADMIN`, `NET_RAW` und `/dev/net/tun` sind dokumentierte VPN-Ausnahmen |
| `gitea` | Git-Server / origin fuer GitOps | `core/gitea/docker-compose.yml` | `https://git.kaleschke.info`, SSH `222` | Traefik, `frontend_net`, externe DNS-Resolver fuer GitHub-Push-Mirror | `/mnt/user/services/gitea/data` | Tier 1, `gitea.sqlite.dump` + Share; privater GitHub-Push-Mirror fuer Repo-Bootstrap | ja | SSH-Port 222 direkte Host-Port-Ausnahme; Push-Mirror nach `michaelkaleschke-spec/homelab-infra` reduziert das DR-Bootstrap-Risiko |
## Security / Identity
@@ -27,7 +27,7 @@ Secret-Werte sind nicht enthalten. Es werden nur Secret-Namen, Env-Key-Namen und
| Service | Zweck | Autoritativer Pfad | URL / Zugang | Abhaengigkeiten | Datenpfade | Backup / Restore | Traefik | Besonderheiten / TODOs |
|---|---|---|---|---|---|---|---|---|
| `postgresql17` | shared PostgreSQL 18 Cluster (historischer Service-Name bleibt fuer DNS/Clients stabil) | `infra/postgresql17/docker-compose.yml` | intern | `backend_net` | `/mnt/user/appdata/postgresql18`, archivierter Rollback-Altstand `/mnt/user/appdata/_archive/pg18-immich-rollback-volumes-20260602/postgresql17`, `postgres_password.txt` | Tier 1; Dumps unter `/mnt/user/backups/borg/dumps/latest` | nein | keine Host-Ports; raw DB nicht primaerer Restore-Weg |
| `postgresql17` | shared PostgreSQL 18 Cluster (historischer Service-Name bleibt fuer DNS/Clients stabil) | `infra/postgresql17/docker-compose.yml` | intern | `backend_net` | `/mnt/user/appdata/postgresql18`, Rollback-Altstand `/mnt/user/appdata/postgresql17`, `postgres_password.txt` | Tier 1; Dumps unter `/mnt/user/backups/borg/dumps/latest` | nein | keine Host-Ports; raw DB nicht primaerer Restore-Weg |
| `Redis` | primaer Paperless-Redis (App-Cache); historisch als "shared" angelegt, faktisch nur von Paperless genutzt | `infra/redis/docker-compose.yml` | intern | `backend_net` | `/mnt/user/appdata/redis`, `redis_password.txt` | transiente Daten, bewusst nicht kritisch | nein | Redis 8.8; Passwort-Datei; optional named volume offen. Immich, Nextcloud und Mealie nutzen jeweils eigene Redis-Instanzen; Authelia laeuft bewusst ohne Redis-Session-Backend. Bei Wegfall ist Paperless der einzige betroffene Stack. |
| `ddns-updater` | Cloudflare/DDNS Aktualisierung | `infra/ddns-updater/docker-compose.yml` | intern | Internetzugang, `frontend_net` | `/mnt/user/appdata/ddns-updater` | rebuildbar | nein | bleibt bewusst in `frontend_net`, weil `backend_net` internal ist |
@@ -38,16 +38,16 @@ Secret-Werte sind nicht enthalten. Es werden nur Secret-Namen, Env-Key-Namen und
| `paperless-ngx` | Dokumentenmanagement | `apps/paperless/docker-compose.yml` | `https://paperless.kaleschke.info` | PostgreSQL 18, Redis 8, Traefik | `/mnt/user/appdata/paperless-ngx/data`, `/mnt/user/documents/paperless`, `/mnt/user/documents/scans_inbox` | Tier 2, Borg + `postgresql17-paperless.dump` | ja | DB/Redis Secrets bleiben bewusst Stack ENV; Dump-Dateiname behaelt den historischen Cluster-Namen |
| `paperless-gpt` | KI-Ergaenzung fuer Paperless | `apps/paperless-gpt/docker-compose.yml` | `https://paperless-gpt.kaleschke.info` | Paperless API, OpenAI API, Traefik | `/mnt/user/appdata/paperless-gpt/data`, `/mnt/user/appdata/paperless-gpt/prompts` | Tier 2 | ja + Authelia | `PAPERLESS_API_TOKEN` und `OPENAI_API_KEY` als Stack ENV; LLM und Vision-OCR laufen ueber `gpt-5.4-mini`, kein Zugriff mehr auf lokale Ollama-VM. **Behalten-Entscheidung 2026-05-28:** Container bleibt aktiv, auch wenn aktuell keine Traefik-Zugriffe in der Woche; Ablouseplanung erst mit Paperless-NGX 3.0 (eigene KI-Features erwartet) - dann neu bewerten. |
| `immich_server` | Foto-/Video-App | `apps/immich/docker-compose.yml` | `https://immich.kaleschke.info` | Immich Postgres, Immich Redis, ML, Traefik | `/mnt/user/photos/immich`, `/mnt/user/photos/family_archive` | Tier 2, Borg + `immich.dump` | ja | native App-Auth; externes Fotoarchiv gemountet |
| `immich_postgres` | Immich-Datenbank | `apps/immich/docker-compose.yml` | intern | `immich_default` | `/mnt/user/appdata/immich_postgres_vectorchord`, archivierter Rollback-Altstand `/mnt/user/appdata/_archive/pg18-immich-rollback-volumes-20260602/immich-postgres-pgvecto-rs`, `immich_postgres_password.txt` | Dump `immich.dump`; Restore braucht ein Image mit VectorChord/pgvector | nein | PG14 bleibt bewusst; Immich-DB-Image `ghcr.io/immich-app/postgres:14-vectorchord0.4.3-pgvectors0.2.0`; nie ins `frontend_net` |
| `immich_postgres` | Immich-Datenbank | `apps/immich/docker-compose.yml` | intern | `immich_default` | `/mnt/user/appdata/immich_postgres_vectorchord`, Rollback-Altstand `/mnt/user/appdata/immich_postgres`, `immich_postgres_password.txt` | Dump `immich.dump`; Restore braucht ein Image mit VectorChord/pgvector | nein | PG14 bleibt bewusst; Immich-DB-Image `ghcr.io/immich-app/postgres:14-vectorchord0.4.3-pgvectors0.2.0`; nie ins `frontend_net` |
| `immich_redis` | Immich Cache | `apps/immich/docker-compose.yml` | intern | `immich_default` | kein kritischer Pfad dokumentiert | rebuildbar | nein | Redis 8.8; Architektur nennt anonymes Volume -> named volume als offenes Thema |
| `immich_machine_learning` | Immich ML | `apps/immich/docker-compose.yml` | intern | `immich_default` | `model-cache` | rebuildbar | nein | intern-only |
| `mealie` | Rezeptverwaltung | `apps/mealie/docker-compose.yml` | `https://mealie.kaleschke.info` | `mealie-postgres`, Traefik | `/mnt/user/appdata/mealie/data` | Tier 2, Borg + `mealie.dump` | ja | App + DB in internem Netz getrennt |
| `mealie-postgres` | Mealie-Datenbank | `apps/mealie/docker-compose.yml` | intern | `mealie_internal` | `/mnt/user/appdata/mealie/postgres18`, archivierter Rollback-Altstand `/mnt/user/appdata/_archive/pg18-immich-rollback-volumes-20260602/mealie-postgres17`, `mealie_postgres_password.txt` | Dump `mealie.dump` | nein | interne DB; PostgreSQL 18 |
| `mealie-postgres` | Mealie-Datenbank | `apps/mealie/docker-compose.yml` | intern | `mealie_internal` | `/mnt/user/appdata/mealie/postgres18`, Rollback-Altstand `/mnt/user/appdata/mealie/postgres`, `mealie_postgres_password.txt` | Dump `mealie.dump` | nein | interne DB; PostgreSQL 18 |
| `mail-archiver` | Mail-Archivierung | `apps/mail-archiver/docker-compose.yml` | `https://mail.kaleschke.info` | PostgreSQL 18, Internet/IMAP, Traefik, Authelia | `/mnt/user/appdata/mailarchiver/data-protection-keys` | Tier 2, `postgresql17-mailarchiver.dump` | ja + Authelia | Hybrid-Dienst: `frontend_net` fuer Internet, `backend_net` fuer DB; App-eigene Auth bleibt zusaetzliche Schutzschicht; Dump-Dateiname behaelt den historischen Cluster-Namen |
| `nextcloud` | Datei-/Cloud-Dienst | `apps/nextcloud/docker-compose.yml` | `https://cloud.kaleschke.info` | eigene PostgreSQL, eigene Redis, Traefik | `/mnt/user/appdata/nextcloud/html`, `/mnt/user/documents/nextcloud-data` | Tier 2, `nextcloud.dump` + Share | ja | native App-Auth ohne zentrale ForwardAuth; WebDAV/CardDAV beachten |
| `nextcloud-postgres` | Nextcloud-Datenbank | `apps/nextcloud/docker-compose.yml` | intern | `nextcloud_internal` | `/mnt/user/appdata/nextcloud/postgres18`, archivierter Rollback-Altstand `/mnt/user/appdata/_archive/pg18-immich-rollback-volumes-20260602/nextcloud-postgres17`, `nextcloud_postgres_password.txt` | `nextcloud.dump`, raw DB nicht primaerer Restore-Weg | nein | interne DB; PostgreSQL 18 |
| `nextcloud-postgres` | Nextcloud-Datenbank | `apps/nextcloud/docker-compose.yml` | intern | `nextcloud_internal` | `/mnt/user/appdata/nextcloud/postgres18`, Rollback-Altstand `/mnt/user/appdata/nextcloud/postgres`, `nextcloud_postgres_password.txt` | `nextcloud.dump`, raw DB nicht primaerer Restore-Weg | nein | interne DB; PostgreSQL 18 |
| `nextcloud-redis` | Nextcloud Cache/Locking | `apps/nextcloud/docker-compose.yml` | intern | `nextcloud_internal` | `/mnt/user/appdata/nextcloud/redis` | Teil von Nextcloud-Restore | nein | interne Redis 8.8 |
| `plex` | Medienserver mit LAN-/Client-Discovery | `host-services/plex/docker-compose.yml`, `traefik/dynamic/plex.yml` | `https://plex.kaleschke.info`, LAN `http://192.168.178.58:32400/web`, Remote Access deaktiviert | Host-Netz, Traefik File provider | `/mnt/user/appdata/plex/config`, `/mnt/user/appdata/plex/transcode`, `/mnt/user/media`, `/mnt/user/photos` | Tier 2, Appdata + Medienpfade im Borg-/Share-Scope | ja, native Plex-Auth | Repo-Compose-Stack; `network_mode: host` bleibt dokumentierte Discovery-Ausnahme. Traefik routet via File-Provider-Ausnahme auf `http://192.168.178.58:32400`, weil Docker-Labels Host-Netz-Container aus Traefik heraus auf `127.0.0.1` routen wuerden. Keine FRITZ!Box-Freigabe fuer `32400`. Keine Authelia-ForwardAuth, weil Plex Web/App-Clients native Plex-Auth und eigene Flows nutzen. Server geclaimt von `Xeridos`; Smart-TVs greifen weiter ueber WLAN-LAN per mDNS/Plex-GDM direkt zu. `PublishServerOnPlexOnlineKey=0` (Plex Remote Access aus), `RelayEnabled` ebenfalls aus. |
| `plex` | Medienserver mit LAN-/Client-Discovery | `host-services/plex/docker-compose.yml` | Plex native, **LAN/Tailscale-only**, Remote Access deaktiviert | Host-Netz | `/mnt/user/appdata/plex/config`, `/mnt/user/appdata/plex/transcode`, `/mnt/user/media`, `/mnt/user/photos` | Tier 2, Appdata + Medienpfade im Borg-/Share-Scope | nein | Repo-Compose-Stack; `network_mode: host` bleibt dokumentierte Discovery-Ausnahme. Server geclaimt von `Xeridos` (Reclaim 2026-05-28 nach Preferences-Reset vom 18.05.). Smart-TVs greifen ueber WLAN-LAN per mDNS/Plex-GDM direkt zu. `PublishServerOnPlexOnlineKey=0` (Remote Access aus), `RelayEnabled` ebenfalls aus. |
| `ntfy` | Push-Benachrichtigungen | `apps/ntfy/docker-compose.yml` | `https://ntfy.kaleschke.info` | Traefik, upstream mobile push | `/mnt/user/appdata/ntfy` | Tier 2 | ja | `NTFY_BEHIND_PROXY=true`; Problem-Alerts gehen gebuendelt an `homelab-alerts`, optionale Erfolgsmeldungen an `homelab-info` |
| `bentopdf` | PDF-Tooling / Ersatz fuer Stirling-PDF | `apps/bentopdf/docker-compose.yml` | `https://pdf.kaleschke.info` | Traefik + Authelia | keine kritische Persistenz im Compose | Tier 3, rebuildbar | ja + Authelia | COOP/COEP per Middleware. **Behalten-Entscheidung 2026-05-28:** Container bleibt aktiv als situatives Tool, auch wenn aktuell keine Traefik-Zugriffe in der Woche. Resource-Footprint vernachlaessigbar (~4 MB RAM). |
| `super-productivity` | Persoenliche Produktivitaets-/Task-PWA (Operator), konsumiert Gitea-Issues aus `Micha/mails` | `apps/super-productivity/docker-compose.yml` | `https://sp.kaleschke.info` | Traefik + Authelia, Gitea `Micha/mails` (Polling vom Client) | statisches Frontend, kein Server-State; Browser-IndexedDB plus optionaler WebDAV-Sync gegen Nextcloud | Tier 3, rebuildbar | ja + Authelia | Reine Static-PWA; SP synchronisiert client-seitig ueber Gitea-API (Scope `assigned`, Repo `Micha/mails`, User `Micha`). |
@@ -85,7 +85,7 @@ Secret-Werte sind nicht enthalten. Es werden nur Secret-Namen, Env-Key-Namen und
| Service | Zweck | Autoritativer Pfad | URL / Zugang | Abhaengigkeiten | Datenpfade | Backup / Restore | Traefik | Besonderheiten / TODOs |
|---|---|---|---|---|---|---|---|---|
| `posture-check` | Host-Posture-Audit fuer Filesystem, Mover-Drift, NVMe-SMART, Fuellstand und Authelia-Repo<->Host-Drift | `services/posture-check/posture-check.sh` | Unraid User-Script / Cron / Borg Pre-Hook | `findmnt`, `df`, `nvme`, optional `curl` fuer ntfy; ruft `services/authelia-diff.sh` fuer `authelia_config_drift` auf | `/mnt/user/services/posture-check/last.json` | Repo-Skript + letzter JSON-Status | nein | Muss auf dem Unraid-Host bei Boot, stuendlich und vor Borg laufen; Disk1-NTFS ist nach Disk1 Phase 2 nicht mehr erlaubt (`ALLOW_DISK1_NTFS=0` Standard); Warning/Critical alarmieren via ntfy nur bei neuer Ursache oder nach `ALERT_REPEAT_SECONDS`. Authelia-Drift-Check braucht einen Repo-Spiegel unter `/mnt/user/services/homelab-infra/` (siehe `docs/WORKFLOW.md` Sektion "Ausnahme: Authelia configuration.yml") |
| `docker-critical-events` | Live-Alarmierung fuer Docker `die`/`oom`/`kill` Events | `services/posture-check/docker-critical-events.sh`, Supervisor `services/posture-check/docker-critical-events-supervisor.sh` | Unraid User-Script / Hintergrundprozess | Docker CLI, ntfy | `/mnt/user/services/posture-check/docker-critical-events-last.log`, PID/Outfile unter `/mnt/user/services/posture-check/` | Repo-Skript + letzter Event-Log | nein | Optional als Unraid User-Script `at array start` starten; Supervisor kann `start`, `stop`, `status`, `smoke`; sendet nach `homelab-alerts` |
| `docker-critical-events` | Live-Alarmierung fuer Docker `die`/`oom`/`kill` Events | `services/posture-check/docker-critical-events.sh` | Unraid User-Script / Hintergrundprozess | Docker CLI, ntfy | `/mnt/user/services/posture-check/docker-critical-events-last.log` | Repo-Skript + letzter Event-Log | nein | Optional als Unraid User-Script `at array start` starten; sendet nach `homelab-alerts` |
## Backup- und Restore-Hinweise
docs/WEEKEND_EXECUTION_PLAN_2026-06-05.md
-151
View File
@@ -1,151 +0,0 @@
# Weekend Execution Plan - 2026-06-05 bis 2026-06-07
Ziel: Bis Ende des Wochenendes alle offenen To-dos aus `docs/MASTER_TODO.md`
entweder erledigen, verifiziert schliessen, oder bewusst als geparkt/extern
blockiert markieren. Nicht jeder Punkt ist realistisch "fertig" im Sinne von
technisch umgesetzt: Family-Onboarding, zweite Hardware, USV und WAN-Failover
brauchen Operator- oder Hardware-Entscheidungen.
## Arbeitsregeln
- Secrets niemals in Chat, Logs oder Repo schreiben.
- Homelab-Aenderungen nur via GitOps, keine direkten Komodo-/Docker-Hotfixes.
- Destruktive Windows- oder Host-Schritte nur nach expliziter Freigabe.
- Ergebnis jedes abgeschlossenen Punkts in der Detaildoku und in
`docs/MASTER_TODO.md` nachziehen.
- Am Ende: ein sauberer Commit-Block; Push erst nach Freigabe.
## Owner-Aufteilung
| Owner | Fokus | Ergebnis |
|---|---|---|
| Codex | `baerchen` Veeam, Doku-Konsolidierung, lokale Checks, Commit-Vorbereitung | Veeam-Erstbackup geprueft, Recovery-Test dokumentiert, Masterliste aktualisiert |
| Claude | Family-Onboarding-Paket, Network-/Tailscale-Entscheidungen, Hardware-/Todo-Konsolidierung, nicht-destruktive Runbooks | Konkrete Doku-Patches, ausfuehrbare Checklisten, klare Operator-Fragen statt diffuser TBDs |
| Operator | Physische/GUI-Schritte, Secrets, Familie, Hardwareentscheidungen | Recovery-USB booten, Passwoerter/Keys bereitstellen, Family-Onboarding starten/entscheiden |
## Codex-Aufgaben
| Prioritaet | Aufgabe | Abschlusskriterium |
|---|---|---|
| P1 | Veeam-Erstbackup `baerchen-c-image` pruefen | **erledigt 2026-06-05:** Full-Lauf geschrieben, Veeam-GUI 53,8 GB, Dauer 0:11:31, MetaCheck 0 Fehler/0 Warnungen; Storage Encryption war nicht aktiv und ist als Operator-Entscheidung dokumentiert |
| P1 | Recovery-USB-Test begleiten | `VEEAMRE` bootet, SMB-Ziel sichtbar, Restore Point sichtbar, vor Restore abgebrochen |
| P1 | `windows-image-backup-baseline.md` finalisieren | Erster Lauf und Teststatus mit Datum eingetragen |
| P1 | `docs/MASTER_TODO.md` nach jedem Abschluss aktualisieren | erledigte Punkte entfernt oder in "geschlossen" vermerkt |
| P2 | Alte Windows-Reinstall-Doku bereinigen | ueberholte WinRE-/Admin-To-dos als erledigt/ueberholt markiert |
| P2 | Git-Status sortieren | Eigene Aenderungen klar von vorhandenen User-Aenderungen getrennt |
| P2 | Commit vorbereiten | Commit-Message-Vorschlag und Datei-Liste bereit; kein Push ohne Freigabe |
## Claude-Aufgaben
Claude soll parallel nur repo-seitig arbeiten und keine produktiven Host-Aenderungen
ausfuehren. Die Aufgaben sind bewusst als echte Doku-/Planungsarbeit formuliert,
nicht nur als Pruefaufgaben:
| Prioritaet | Aufgabe | Abschlusskriterium |
|---|---|---|
| P1 | `docs/MASTER_TODO.md` gegen Detaildokus gegenpruefen | **erledigt 2026-06-05:** Sync-Notiz in `docs/AUDIT_2026-05-25_TODO.md`, Masterliste aktualisiert |
| P1 | Restore-Backlog aktualisieren | **erledigt 2026-06-05:** erledigte Kandidaten aus `docs/RESTORE_MATRIX.md` bereinigt |
| P1 | Family-Onboarding in ein ausfuehrbares Session-Paket umwandeln | **erledigt 2026-06-05:** `docs/FAMILY_ONBOARDING.md` enthaelt Vorbereitungs-, Termin- und Erfolgskriterien ohne Secret-Werte |
| P1 | `docs/NETWORK_INVENTORY.md` TBDs in Entscheidungen oder konkrete Operator-Fragen verwandeln | **erledigt 2026-06-05:** Tailscale IPv6/Exit Node/Subnet Router/ACL-Policy sind als Messaufgabe/Operator-Entscheidung formuliert; Gast-/WAN-Pfade sind geparkt oder mit Vorbedingungen versehen |
| P2 | Nicht-destruktive Runbooks fuer offene Restore-Tests vorbereiten | **erledigt 2026-06-05:** Runbook-Stubs fuer Unraid Flash, AdGuard, Tailscale, Redis 8 in `docs/RESTORE_MATRIX.md` |
| P2 | `docs/AUDIT_2026-05-25_TODO.md` und `MASTER_TODO.md` synchronisieren | **erledigt 2026-06-05:** keine doppelten oder widerspruechlichen P1/P2-Punkte |
| P2 | Windows-Reinstall-Altdoku auf ueberholte To-dos pruefen | **erledigt 2026-06-05:** WinRE/Admin-Check-Altlasten als erledigt/ueberholt markiert |
| P2 | Hardware-/Betriebsentscheidungen konsolidieren | **teilweise erledigt 2026-06-05:** USV und Cold-Backup-Rotation sind entschieden/geparkt; Masterliste fuehrt sie nicht mehr als aktive Umsetzungsaufgaben |
| P3 | Geparkte Punkte klassifizieren | Family/USV/WAN/CrowdSec/OIDC klar als Entscheidung statt Umsetzungsarbeit markiert |
## Operator-Aufgaben
| Prioritaet | Aufgabe | Abschlusskriterium |
|---|---|---|
| P1 | Veeam-Encryption-Entscheidung treffen | Fuer den ersten Full-Lauf ist kein Veeam-Encryption-Passwort noetig; falls Storage Encryption aktiviert wird, Passwort in Vaultwarden anlegen und neues Full erzeugen |
| P1 | Recovery-USB physisch booten | Boot ins Veeam-Recovery-System gelingt |
| P1 | Keine echten Restore-Ziele bestaetigen | Restore-Test wird vor destruktiver Datentraegerauswahl abgebrochen |
| P2 | BitLocker-Entscheidung treffen | `aktivieren`, `spaeter`, oder `bewusst aus` dokumentiert |
| P2 | Family-Onboarding real starten oder terminieren | konkreter Termin/Personenkreis statt offenem Wunsch |
| P3 | Hardware-Entscheidungen | USV/Cold-Rotation/WAN-Failover als kaufen, spaeter, oder bewusst nein markieren |
## Realistische Wochenend-Ziele
Bis Sonntagabend realistisch fertig:
- `baerchen` Veeam-Erstbackup verifiziert.
- `baerchen` Recovery-USB-Test ohne Restore verifiziert.
- Veeam-/BitLocker-Doku bereinigt.
- Master-To-do-Liste bereinigt.
- Restore-Backlog sortiert.
- Alte/ueberholte To-dos als erledigt/ueberholt markiert.
- Blockierte Punkte explizit als Betreiber-/Hardware-/Familienentscheidung markiert.
Nicht realistisch ohne externe Voraussetzungen:
- End-to-end-DR-Drill ohne zweite Hardware.
- Family-Onboarding ohne Familie/Geraete.
- USV erledigen ohne Kauf.
- WAN-Failover erledigen ohne Mobilfunk-/Router-Entscheidung.
- Dedizierter SMB-User ohne bewusste Unraid-User-/Share-Aenderung.
## Prompt fuer Claude
```text
Du bist Claude im KalliLab CORE Homelab-Repo.
Arbeitsziel fuer dieses Wochenende:
Hilf, alle offenen To-dos aus `docs/MASTER_TODO.md` bis Sonntagabend entweder
zu erledigen, sauber zu dokumentieren, oder bewusst als geparkt/blockiert zu
klassifizieren. Arbeite repo-seitig, keine produktiven Host-Aenderungen.
Pflichtregeln:
- Lies zuerst `CLAUDE.md`.
- Lies danach `HOMELAB_ARCHITECTURE_MASTER_V2.md`, `docs/WORKFLOW.md`,
`docs/README.md`, `docs/REPO_MAP.md`, `docs/MASTER_TODO.md`,
`docs/RESTORE_MATRIX.md`, `docs/DISASTER_RECOVERY.md`,
`docs/SECRETS_MAP.md` und `ops/windows-reinstall/docs/windows-image-backup-baseline.md`.
- Keine Secrets ins Repo. Nur Secret-Namen, Pfade und Ablageorte dokumentieren.
- Keine Komodo-/Docker-/Host-Hotfixes. Keine produktiven Schreibbefehle auf dem Homelab.
- Keine destruktiven Aktionen.
- Beachte vorhandene uncommitted Aenderungen; nichts revertieren, was du nicht selbst gemacht hast.
Konkrete Aufgaben:
1. Wandle `docs/FAMILY_ONBOARDING.md` von einer guten Erklaerseite in ein
ausfuehrbares Session-Paket um:
- 30-Minuten-Ablauf fuer das erste echte Onboarding
- Checkliste pro Geraet/Person ohne Namen oder Secret-Werte
- klare Abschlusskriterien fuer Vaultwarden, Immich und Mealie
- Liste der Operator-Fragen, falls Konten/Startpasswoerter fehlen
2. Bereinige `docs/NETWORK_INVENTORY.md`:
- Tailscale IPv6, Exit Node, Subnet Router und ACL-Policy nicht als
unerklaerte `TBD` stehen lassen
- wenn nicht verifizierbar: als konkrete Operator-Frage oder bewusst offene
Entscheidung formulieren
- Gast-/IoT-Zugriff als Entscheidungspfad dokumentieren, nicht als vage
Altlast
3. Ziehe `docs/MASTER_TODO.md` nach deinen Edits nach:
- echte naechste Schritte in P1/P2
- geparkte Entscheidungen nur im geparkten/geschlossenen Bereich
- keine Duplikate zu `docs/AUDIT_2026-05-25_TODO.md`
4. Falls du weitere diffuse TBDs in Hardware/Network/Family findest: nicht nur
melden, sondern in konkrete Entscheidung, geparkten Punkt oder naechsten
Operator-Schritt umformulieren.
5. Schon erledigte Restore-/Windows-Doku-Aufgaben nicht erneut bearbeiten,
ausser du findest einen klaren Widerspruch.
6. Am Ende liefere:
- geaenderte Dateien
- welche Punkte geschlossen wurden
- welche Punkte blockiert/geparkt bleiben und warum
- welche Operator-Schritte noch noetig sind
Nicht tun:
- Keine Secrets anzeigen oder erfinden.
- Kein Push.
- Kein `docker`, `ssh` oder Host-Schreibzugriff.
- Kein BitLocker, keine Veeam-Aenderung, keine Unraid-User-/Share-Aenderung.
```
## Abschlusskriterien fuer Sonntag
- `docs/MASTER_TODO.md` ist die fuehrende Liste.
- Alle erledigten Punkte haben Beleg in der Detaildoku.
- Alle nicht erledigbaren Punkte sind als blockiert/geparkt mit Grund markiert.
- `git status` ist verstanden: eigene Doku-Aenderungen vs. bestehende
User-Aenderungen sind getrennt.
- Commit ist vorbereitet, Push erfolgt nur nach Operator-Freigabe.
docs/WEEKEND_STATUS_2026-06-05.md
-41
View File
@@ -1,41 +0,0 @@
# Weekend Status - 2026-06-05
Kurzlebiges Arbeitsboard fuer den Wochenend-Sprint. Fuehrende Liste bleibt
`docs/MASTER_TODO.md`; dieses Board haelt nur den aktuellen Arbeitsstand fest.
## Jetzt laufend
| Owner | Aufgabe | Status | Naechster Schritt |
|---|---|---|---|
| Codex | Veeam-Erstbackup `baerchen-c-image` | erledigt | Erster Full-Lauf 2026-06-05 geschrieben; Recovery-Test bleibt offen |
| Codex | Veeam-Verifikationshilfe | erledigt | Hilfsskript bleibt fuer spaetere Checks verfuegbar |
| Claude | Restore-/Altdoku-Bereinigung | erledigt | Keine weitere Arbeit an Veeam/Windows/Restore-Matrix ohne neuen Widerspruch |
| Claude | Family-/Network-Ausfuehrungspaket | erledigt | Masterliste und Weekend-Plan sind nachgezogen |
## Naechste Operator-Schritte
| Zeitpunkt | Aufgabe | Ergebnis, das dokumentiert wird |
|---|---|---|
| Erledigt | Veeam-Erstbackup `baerchen-c-image` pruefen | 2026-06-05 19:46, Full-Lauf erfolgreich, Veeam-GUI 53,8 GB, Dauer 0:11:31 |
| Als naechstes | Recovery-USB `VEEAMRE` booten | Boot OK, Netzwerk OK, SMB-Ziel sichtbar |
| Im Recovery-Test | Restore Point anzeigen; falls spaeter verschluesselt: Passwort testen | Restore Point sichtbar; vor echtem Restore abgebrochen |
| Spaeter | BitLocker-Entscheidung treffen | `aktivieren`, `spaeter`, oder `bewusst aus` in `docs/MASTER_TODO.md`/Baseline nachziehen |
## Heute bereits geschlossen
| Thema | Ergebnis |
|---|---|
| WinRE/Admin-Altlasten | In Windows-Reinstall-Doku als erledigt/ueberholt markiert |
| Restore-Test-Kandidaten | Erledigte Kandidaten aus der aktiven Liste entfernt; Stubs fuer offene Kandidaten ergaenzt |
| Family-Onboarding | Aus der Familien-Doku wurde ein konkreter 30-45-Minuten-Terminablauf mit Vorbereitung und Erfolgskriterien |
| Network-TBDs | Tailscale-/Gastnetz-/WAN-Failover-Punkte wurden in Messaufgaben, Vorbedingungen oder geparkte Entscheidungen umgewandelt |
| Veeam-Erstbackup | Full-Lauf 2026-06-05 erfolgreich geschrieben: Veeam-GUI 53,8 GB, Dauer 0:11:31, MetaCheck 0 Fehler/0 Warnungen, VSS success; Veeam Storage Encryption war nicht aktiv |
| Cold-Backup-Rotation | Bewusst Hetzner-only; kein aktives Todo mehr |
| USV | Bewusst auf Q3/2026 geparkt; Power-Loss bleibt akzeptiertes Risiko |
## Nicht ohne neue Freigabe anfassen
- Keine BitLocker-Aktivierung.
- Keine Aenderung am Veeam-Job oder Encryption-Status.
- Keine Unraid-User-/Share-Aenderung.
- Keine produktiven Host- oder Docker-Schreibbefehle.
docs/audit/dr-workstation-readiness-2026-06-06.md
-137
View File
@@ -1,137 +0,0 @@
# DR-Workstation Readiness - 2026-06-06
Automatisch erzeugter lokaler Readiness-Check fuer den Operator-PC. Es wurden keine Secret-Werte, Passphrases oder Private-Key-Inhalte ausgegeben.
## Zusammenfassung
| Check | Ergebnis |
|---|---|
| WSL2 Ubuntu | vorhanden (`Ubuntu 24.04`, WSL Version 2) |
| SSH/Git in WSL | vorhanden |
| GitHub-Read-Smoke mit DR-Key | ok |
| Borg Client | installiert |
| Hetzner Storage Box mit DR-Key | ok |
| `~/dr-smoke.sh` | vorhanden |
| Finaler Borg-Smoke | ok, Operator-Bestaetigung 2026-06-06 10:05:30 |
| WSL sudo ohne Passwortprompt | nein, Operator muss Passwort eingeben |
## Bewertung
- Der lokale WSL2-/Ubuntu-Unterbau ist vorhanden.
- Die DR-Key-Arbeitskopien liegen in WSL unter `~/.ssh/dr-readonly` und `~/.ssh/dr-hetzner`.
- GitHub-Read-Smoke und Hetzner-SSH-Smoke sind erfolgreich.
- `borgbackup` ist installiert.
- Der vollstaendige Bare-Metal-DR-Smoke ist erfolgreich abgeschlossen.
## Finaler Borg-Smoke
Operator-Bestaetigung vom 2026-06-06:
- Befehl: `bash ~/dr-smoke.sh`
- GitHub Deploy-Key: HEAD `3a263a4...`
- Hetzner SSH-Login: Repos `backup`, `backup2`, `hetzner_borg_appdata`, `hetzner_borg_appdata_critical` sichtbar
- Borg-Repo: `ssh://u565255@u565255.your-storagebox.de/./hetzner_borg_appdata_critical`
- Repository ID: `5dd9b949...`
- Encryption: `Yes (repokey)`
- Borg-Statistik: `Original size 1.16 TB`, `Compressed size 1.13 TB`, `Deduplicated size 35.92 GB`
- Ergebnis: `DR-Smoke OK (2026-06-06 10:05:30)`
Die Borg-Passphrase wurde nur interaktiv eingegeben und nicht dauerhaft auf `baerchen` gespeichert.
## Rohchecks
### wsl_status
- ExitCode: `0`
```text
Standarddistribution: Ubuntu
Standardversion: 2
```
### wsl_list
- ExitCode: `0`
```text
NAME STATE VERSION
* Ubuntu Stopped 2
docker-desktop Stopped 2
```
### ubuntu_os
- ExitCode: `0`
```text
Distributor ID: Ubuntu
Description: Ubuntu 24.04.4 LTS
Release: 24.04
Codename: noble
6.6.114.1-microsoft-standard-WSL2
```
### tools
- ExitCode: `0`
```text
/usr/bin/borg
borg 1.2.8
/usr/bin/ssh
OpenSSH_9.6p1 Ubuntu-3ubuntu13.16, OpenSSL 3.0.13 30 Jan 2024
/usr/bin/git
git version 2.43.0
```
### sudo
- ExitCode: `0`
```text
sudo-password-needed
```
### wsl_ssh_files
- ExitCode: `0`
```text
total 40
drwx------ 2 michi michi 4096 Jun 6 09:14 .
drwxr-x--- 5 michi michi 4096 Jun 6 08:37 ..
-rw------- 1 michi michi 411 Jun 6 09:14 dr-hetzner
-rw------- 1 michi michi 419 Jun 6 09:14 dr-readonly
-rw------- 1 michi michi 411 Apr 4 19:29 id_ed25519
-rw-r--r-- 1 michi michi 97 Apr 4 19:29 id_ed25519.pub
-rw------- 1 michi michi 6358 Jun 6 09:14 known_hosts
-rw------- 1 michi michi 3013 Apr 20 20:13 known_hosts.old
-rw------- 1 michi michi 3858 Apr 24 08:27 known_hosts.pre-port222-20260604-122031.bak
-rwxr-xr-x 1 michi michi 1311 Jun 6 08:37 /home/michi/dr-smoke.sh
```
### github_dr_key_smoke
- ExitCode: `0`
```text
68d3ace598ee4d1cdad3ed94b63ae5046ac187fb HEAD
```
### hetzner_dr_key_smoke
- ExitCode: `0`
```text
backup
backup2
hetzner_borg_appdata
hetzner_borg_appdata_critical
```
docs/audit/system-audit-2026-06-05.md
-303
View File
@@ -1,303 +0,0 @@
# System-Audit 2026-06-05
**Scope:** Windows-Host `baerchen` (frisch aufgesetzt), Read-only
**Referenz-Doku:** `ops/windows-reinstall/docs/laufwerks-neustruktur-2026-06-04.md`, `boot-cleanup-plan-2026-06-04.md`
**Durchgeführt:** 2026-06-05, ohne Admin-Rechte
**Rohdaten:** `audit/raw/01_volumes_partitions.txt` bis `06_events_hardware.txt`
---
## 1. Ordner- und Laufwerksstruktur (Priorität)
### 1.1 Soll-Ist-Vergleich: Ordner-Existenz
| Pfad | Soll | Ist | Status |
|---|---|---|---|
| `D:\00_Inbox` | ✓ | vorhanden | OK |
| `D:\10_Dokumente` | ✓ | vorhanden | OK |
| `D:\11_Bilder` | ✓ | vorhanden | OK, aber ReadOnly-Attribut gesetzt |
| `D:\12_Videos` | ✓ | vorhanden | OK |
| `D:\13_Musik` | ✓ | vorhanden | OK |
| `D:\14_Downloads` | ✓ | vorhanden | OK |
| `D:\20_Projekte\aktiv` | ✓ | vorhanden | OK |
| `D:\20_Projekte\archiv` | ✓ | vorhanden | OK |
| `D:\30_Finanzen\Banking4` | ✓ | vorhanden | OK |
| `D:\30_Finanzen\WISO_Steuer` | ✓ | vorhanden | OK |
| `D:\90_Archiv` | ✓ | vorhanden | OK |
| `E:\Steam\steamapps` | ✓ | vorhanden | OK |
| `E:\BattleNet` | ✓ | vorhanden | OK |
| `E:\EpicGames` | ✓ | vorhanden | OK |
| `E:\EA` | ✓ | vorhanden | OK |
| `E:\Riot` | ✓ | vorhanden | OK |
| `E:\Ubisoft` | ✓ | vorhanden | OK |
| **`E:\_Standalone`** | **✓** | **FEHLT** | **LÜCKE** |
| `G:\repos` | ✓ | vorhanden | OK |
| `G:\tools` | ✓ | vorhanden als `Tools` (Großbuchstabe) | OK (NTFS case-insensitive) |
**Nicht in Soll-Doku, aber vorhanden:**
| Pfad | Beurteilung |
|---|---|
| `D:\Micha\Videos` | Altquelle, fast leer (1 Datei), Rest wurde bereinigt |
| `D:\WSL` | WSL-Datenpfad, nicht in Doku erwähnt, aber logisch |
| `G:\Apps` | Zweck unklar, nicht dokumentiert |
| `G:\Gitea_Clone` | Bewusst so (homelab-infra bleibt laut Doku unangetastet) |
| `G:\Workspace` | Nicht dokumentiert, wahrscheinlich Dev-Workspace |
### 1.2 Known-Folder-Redirects
| Ordner | Soll (Doku) | Ist (gemessen) | Status |
|---|---|---|---|
| Desktop | `D:\Micha\Desktop` | `D:\00_Inbox\Desktop` | **ABWEICHUNG** |
| Dokumente | `D:\10_Dokumente` | `D:\10_Dokumente` | OK |
| Downloads | `D:\14_Downloads` | `D:\14_Downloads` | OK |
| Bilder | `D:\11_Bilder` | `D:\11_Bilder` | OK |
| Musik | `D:\13_Musik` | `D:\13_Musik` | OK |
| Videos | `D:\12_Videos` | `D:\12_Videos` | OK |
**Desktop-Befund (Detail):**
- Soll-Doku schreibt: `D:\Micha\Desktop` (als bewusster Sonderfall ohne nummerierten Ordner).
- Ist: Desktop zeigt auf `D:\00_Inbox\Desktop` — dieser Ordner existiert, enthält 4 Dateien.
- `D:\Micha\Desktop` existiert **nicht**.
- `D:\Micha` enthält nur noch `Videos` (1 Datei, leer).
- Fazit: Das Known-Folder-Ziel wurde nach der Doku-Erstellung nochmals geändert. Die Doku ist in diesem Punkt veraltet. Der Desktop liegt funktional korrekt auf D:, aber das Ziel weicht vom dokumentierten Soll ab. **Doku-Update empfohlen.**
### 1.3 Doppelbestand D:\Micha\* vs. neue Nummernstruktur
| Alt | Dateien | Neu | Dateien | Bewertung |
|---|---|---|---|---|
| `D:\Micha\Dokumente` | NICHT MEHR VORHANDEN | `D:\10_Dokumente` | 4011 / 595 MB | Bereinigt ✓ |
| `D:\Micha\Bilder` | NICHT MEHR VORHANDEN | `D:\11_Bilder` | 7789 / 12,4 GB | Bereinigt ✓ |
| `D:\Micha\Videos` | 1 Datei, ~0 MB | `D:\12_Videos` | 1 Datei, ~0 MB | Quasi-leer, kein Doppelbestand |
| `D:\Micha\Musik` | NICHT MEHR VORHANDEN | `D:\13_Musik` | 0 Dateien | Bereinigt ✓ |
| `D:\Micha\Downloads` | NICHT MEHR VORHANDEN | `D:\14_Downloads` | 2186 / 2,2 GB | Bereinigt ✓ |
| `D:\Micha\Finanzen` | NICHT MEHR VORHANDEN | `D:\30_Finanzen` | 126 / 123 MB | Bereinigt ✓ |
**Fazit:** Der befürchtete Doppelbestand ist weitgehend aufgelöst. Nur `D:\Micha\Videos` ist noch vorhanden, ist aber inhaltlich leer. `D:\Micha` kann nach manueller Prüfung von Videos entfernt werden.
### 1.4 Labels
| Laufwerk | Soll | Ist | Status |
|---|---|---|---|
| D: | `Daten-Projekte` | `Daten-Projekte` | OK ✓ |
| E: | `Games` | `Games` | OK ✓ |
| H: | unveraendert | `Externe HDD` | OK ✓ |
### 1.5 Rollen-Konsistenz und Partitions-Layout
| Laufwerk | Soll-Rolle | Ist | Status |
|---|---|---|---|
| C: | Windows + kleine Programme | Disk 0, 167 GB SATA | OK |
| D: | Daten & Projekte | Disk 1, 168 GB SATA | OK |
| E: | Games | Disk 2, **930 GB** NVMe (nach F-Merge) | OK ✓ |
| F: | Altes Windows (löschen) | **Nicht mehr vorhanden** | Abgeschlossen ✓ |
| G: | Arbeits-SSD, Homelab/Dev | Disk 3, 931 GB NVMe | OK |
| H: | Externe Backup-HDD | Disk 4, 7.28 TB USB | OK |
E: und das ehemalige F: sind jetzt eine einzige 930 GB Partition auf Disk 2. Layout ist sauber.
### 1.6 Fachliche Gesamtbewertung der Struktur
**Stärken:**
- Die Nummernstruktur auf D: ist vollständig angelegt und die Known Folders zeigen bis auf Desktop korrekt dorthin.
- Der Doppelbestand ist fast vollständig bereinigt — das war die größte Risikoquelle.
- F: ist weg, E: ist auf volle Disk-Kapazität gewachsen — die BCD-Bereinigung und Partition-Erweiterung wurde sauber abgeschlossen.
- Label-Benennung konsistent.
- G: ist operational (repos, Tools, Gitea_Clone vorhanden).
**Lücken und Inkonsistenzen:**
1. **Desktop-Redirect weicht von Doku ab** (Ist: `D:\00_Inbox\Desktop`, Doku: `D:\Micha\Desktop`). Da `D:\Micha\Desktop` nicht existiert und der Desktop funktioniert, ist die Doku das Problem, nicht das System.
2. **`E:\_Standalone` fehlt** — laut Doku angelegt, tatsächlich nicht vorhanden. Kein funktionaler Schaden, aber Inkonsistenz zur Rollenbeschreibung.
3. **`D:\11_Bilder` hat ReadOnly-Attribut** auf Ordner-Ebene gesetzt — ungewöhnlich, keine erkennbare Ursache. Kein Showstopper, aber prüfenswert.
4. **`G:\Apps`, `G:\Workspace`** sind nicht in der Soll-Doku definiert. Kein Problem an sich, aber für spätere Audits hilfreich zu dokumentieren.
5. **`D:\WSL`** nicht dokumentiert — WSL-Datenpfade dort gehören explizit erwähnt.
6. **`D:\13_Musik`** ist leer (0 Dateien) — entweder war `D:\Micha\Musik` schon leer, oder die Kopie ist ausgeblieben. Zu prüfen ob Musik aus PostDelta-Backup nachgezogen werden muss.
**Gesamturteil:** Die Struktur ist in sich schlüssig und der Umbau ist zu ~95% abgeschlossen. Die verbleibenden Punkte sind kleine Doku-Lücken und ein fehlender Ordner, kein strukturelles Problem.
---
## 2. OS-Baseline
| Feld | Wert | Bewertung |
|---|---|---|
| Edition | Windows 11 Pro | OK |
| Build | 26200 (Insider/Preview-Build) | Achtung: kein Stable-Channel-Build |
| Aktivierung | OEM_DM, aktiv | OK |
| Installiert | 2026-05-10 | ~25 Tage alt |
| Letzter Boot | 2026-06-05 07:57 | Frisch gebootet |
| Ausstehende Updates | 0 | OK |
| Reboot pending | Nein | OK |
**Befund Build 26200:** Das ist ein Windows Insider/Canary-Channel Build, kein Produktions-Release. Für einen Nerd-Einsatz vertretbar, aber mit dem Wissen verbunden, dass Insider-Builds weniger stabil sind und keine LTS-Garantie haben.
---
## 3. Security
### Defender
- Aktiv, TamperProtection an, Signaturen aktuell. **OK.**
- Ausschlüsse und ASR-Regeln: nur als Admin lesbar — **kein Befund, aber blind spot.**
### Firewall
- Alle drei Profile aktiv. DefaultInboundAction `NotConfigured` bedeutet im Windows-Default: eingehend blockieren, ausgehend erlauben. **OK.**
- Port 27036 (Steam Remote Play) lauscht auf `0.0.0.0` — also LAN-seitig offen. Erwartetes Steam-Verhalten, aber explizit im Bewusstsein halten.
### BitLocker
- Nicht prüfbar ohne Admin. **Blind spot — Empfehlung: BitLocker für C: und D: aktivieren.**
### Secure Boot / TPM
- Nicht prüfbar ohne Admin. Hardware MSI MS-7D32 unterstützt beides. Status unbekannt.
### UAC
- Standard-Konfiguration korrekt (Secure Desktop aktiv). **OK.**
### Lokale Admins
- `Administrator` (Built-in) + `michi`. Zwei Accounts in Admins ist normal für einen Einzel-PC. OK.
### SSH Key Permissions
- `id_ed25519` hat `VORDEFINIERT\Administratoren FullControl` — das ist zu weit offen.
- SSH-Clients unter Windows tolerieren das, aber best practice ist: nur der eigene User darf lesen.
- **Empfehlung:** `icacls` Berechtigungen auf User only setzen (als Admin ausführen).
---
## 4. Storage & Boot
- Alle 5 physischen Disks: **Healthy / OK.**
- Wear-Level via `Get-StorageReliabilityCounter`: keine Ausgabe (SATA-SSDs und USB HDD liefern keine WMI-Daten). CrystalDiskInfo ist installiert — dort manuell prüfen.
- Die zwei Intel SATA SSDs (Disk 0 + 1) sind **180 GB** — typische Einzel-Partition-Auslastung auf C: ~36% und D: ~11%, reichlich Luft.
- **BCD:** ohne Admin nicht lesbar. Doku bestätigt sauberen Zustand nach Cleanup + Neustarttest.
- **WinRE:** ohne Admin nicht lesbar. Doku sagt Disabled — muss vor künftiger Partitionsarbeit aktiviert werden.
---
## 5. Netzwerk
- Ethernet: 192.168.178.103, DNS auf Kallilabcore (AdGuard). **Korrekt.**
- Tailscale: aktiv, dieser Rechner als `baerchen-1` online, direkter Pfad zu `kallilabcore`. **OK.**
- Kein SSH-Config — alle SSH-Verbindungen laufen ohne Host-Aliases. Funktional, aber unpraktisch.
- Lauschende Ports: Keine auffälligen Exposition nach außen außer SMB (139/445 — LAN-normal) und Steam 27036.
---
## 6. Remote-Management / SSH
- Kein `~\.ssh\config` vorhanden. Empfehlung: Host-Aliases anlegen (z.B. `Host kallilabcore`).
- SSH-Key vorhanden und aktuell.
- **Key-Rechte zu weit (s. Security).**
- Docker contexts: `desktop-linux` aktiv. Docker Desktop läuft.
- kubectl: keine Contexts — erwartet (kein k8s im Homelab).
- Tailscale: direkter Pfad zu Homelab aktiv, SSH über Tailscale-IP funktioniert.
---
## 7. Dev-Toolchain
| Tool | Version | Bewertung |
|---|---|---|
| git | 2.54.0 | Aktuell, OK |
| Python | 3.13.13 | Aktuell, OK |
| Node.js | 24.16.0 (LTS) | Aktuell, OK |
| Go | 1.26.4 | Aktuell, OK |
| Commit-Signing | nicht konfiguriert | Optional, aber für Homelab-GitOps empfohlen |
WSL Ubuntu ist installiert aber gestoppt. docker-desktop läuft als WSL2-Backend.
---
## 8. Hardware & Performance
- i5-14600KF, 14C/20T, 31.8 GB RAM — für Homelab-Dev-Rechner gut ausgestattet.
- Energieplan: **Ausbalanciert** — für einen Gaming- und Dev-Rechner suboptimal. `Höchstleistung` oder `Ultimative Leistung` wäre bei dauerhafter Nutzung besser.
- Keine echten Gerätekonflikte in PnP (alle "Unknown" sind erwartet: ghosted devices, Netzwerkgeräte, VSS).
---
## 9. Autostart & Persistenz
Läuft automatisch: Brave Update, Steam, Razer Synapse, Docker Desktop, iCUE, Realtek Audio, Tailscale, Ollama.
**Auffällig:** `SoftLanding\CreativeManagementTask` — unbekannter Scheduled Task, nicht einem Standard-Produkt zuzuordnen. Sollte manuell im Task Scheduler geprüft werden (Quelle, Executable, Publisher).
OneDrive läuft mit drei Tasks (Startup + Update) — falls Daten-Sync nicht gewünscht ist, sollte OneDrive deaktiviert werden, da es Dokumente/Bilder/etc. stummschalten könnte (bekanntes Windows-Verhalten nach Known-Folder-Redirect).
---
## 10. Zuverlässigkeit
| Event ID | Anzahl | Beschreibung | Risiko |
|---|---|---|---|
| 20 | 70 | Defender KB4052623 Update-Fehler (0x80240016) | Niedrig — Timing, Defender aktuell |
| 10010 | 15 | DCOM Server Timeout | Niedrig — Windows-Hintergrund |
| 7000 | 3 | Steam Service Start fehlgeschlagen | Niedrig — Race Condition beim Boot |
| 7023 | 3 | Windows Modules Installer beendet mit Fehler | Mittel — Update-Abbrüche prüfen |
| **6008** | **2** | **Unerwartetes Herunterfahren 2026-05-19 13:56** | **Mittel — einmaliger BSOD/Stromausfall** |
| 7034 | 2 | MSI Center Service Absturz | Niedrig |
- **Kein Crash-Dump** vorhanden (`C:\Windows\Minidump` leer). Entweder ist kein BSOD gewesen (Stromausfall), oder Dump-Einstellungen schreiben nicht.
- Empfehlung: Dump-Einstellungen auf "Kleiner Speicherauszug" oder "Vollständiger Speicherauszug" prüfen.
---
## 11. Homelab-Server (ausstehend)
**Status: NICHT DURCHGEFÜHRT**
SSH-Config ist leer — kein Host-Alias konfiguriert. Tailscale zeigt `kallilabcore` als aktiv auf `100.80.98.33` / `192.168.178.58`.
**Bitte bestätigen:**
- SSH-User für Kallilabcore (wahrscheinlich `root`?)
- Soll ich `ssh root@192.168.178.58` oder über Tailscale-IP verwenden?
Nach Bestätigung wird der Homelab-Teil nachgezogen und dieser Report ergänzt.
---
## 12. Gesamt-Findings (priorisiert)
### Kritisch / Handlungsbedarf vor nächster Partitionsarbeit
| # | Befund | Begründung |
|---|---|---|
| K1 | WinRE ist Disabled (laut Doku) | Ohne WinRE kein automatisches Recovery. Muss aktiviert werden bevor weitere Disk-Ops. |
| K2 | BitLocker-Status unbekannt (kein Admin) | C: und D: sollten verschlüsselt sein — aktuell Blind Spot. |
### Mittel / Zeitnah klären
| # | Befund |
|---|---|
| M1 | Desktop-Redirect zeigt auf `D:\00_Inbox\Desktop`, Doku sagt `D:\Micha\Desktop` — Doku aktualisieren |
| M2 | `E:\_Standalone` fehlt — Ordner anlegen oder aus Doku streichen |
| M3 | SSH Private Key Permissions zu weit (Admins haben FullControl) |
| M4 | Energieplan "Ausbalanciert" — für Gaming/Dev `Höchstleistung` empfohlen |
| M5 | `SoftLanding\CreativeManagementTask` unbekannt — Quelle und Publisher prüfen |
| M6 | Unerwartetes Herunterfahren 2026-05-19 — Ursache klären (Stromausfall? BSOD ohne Dump?) |
| M7 | `D:\11_Bilder` hat ReadOnly-Attribut — Ursache und Auswirkung prüfen |
### Niedrig / Nice-to-have
| # | Befund |
|---|---|
| N1 | SSH-Config leer — Host-Aliases anlegen |
| N2 | Git commit.gpgsign nicht gesetzt — für GitOps-Commits empfohlen |
| N3 | `D:\Micha\Videos` noch vorhanden (1 leere Datei) — bereinigen |
| N4 | `G:\Apps`, `G:\Workspace` nicht in Doku — dokumentieren oder strukturieren |
| N5 | `D:\WSL` nicht in Doku — erwähnen |
| N6 | `D:\13_Musik` leer — Musik aus PostDelta-Backup nachziehen? |
| N7 | OneDrive läuft (3 Tasks) — prüfen ob Sync für D:\10_Dokumente etc. gewünscht |
| N8 | Energiesparmodus-Dump-Einstellungen prüfen (kein Dump für 6008-Event) |
| N9 | `D:\DumpStack.log` ist ein Artefakt aus der alten D:-Nutzung, kann bereinigt werden |
| N10 | Insider-Build 26200 — bewusste Entscheidung, aber dokumentieren |
---
## 13. Nächste Schritte (empfohlen, nicht ausgeführt)
1. **Homelab-SSH-Zugang bestätigen** und Homelab-Audit nachziehen.
2. **WinRE aktivieren** (als Admin: `reagentc /enable`) — Voraussetzung für künftige Disk-Ops.
3. **BitLocker Status prüfen** (als Admin: `Get-BitLockerVolume`) und ggf. für C:/D: aktivieren.
4. **SSH-Key-Permissions straffen**: `icacls $env:USERPROFILE\.ssh\id_ed25519 /inheritance:r /grant:r "$env:USERNAME:F"` (als Admin).
5. **`SoftLanding\CreativeManagementTask` untersuchen** — im Task Scheduler Quelle und Aktion prüfen.
6. **Doku `laufwerks-neustruktur-2026-06-04.md`** unter Abschnitt Desktop-Befund korrigieren: Ist-Ziel `D:\00_Inbox\Desktop`.
7. **`E:\_Standalone`** anlegen falls geplant.
8. **`D:\Micha\Videos`** prüfen und ggf. löschen.
9. **CrystalDiskInfo** für SSD Wear-Level öffnen und Werte dokumentieren.
10. **Energieplan** auf `Höchstleistung` oder `Ultimative Leistung` umstellen.
docs/homelab-optimierung.md
-228
View File
@@ -1,228 +0,0 @@
# Homelab-Optimierung — Assessment 2026-06-10
Read-only-Analyse des Repos (Stand `master`, lokale Arbeitskopie 2026-06-10).
Keine produktiven Änderungen durchgeführt. Alle Empfehlungen sind Vorschläge
mit Rollback-Plan; nichts wurde deployed.
## Executive Summary
Das KalliLab-CORE-Homelab ist für ein Ein-Host-Setup ungewöhnlich reif:
GitOps mit Gitea+Komodo, sauberes Netzmodell (frontend/backend/app-intern),
Authelia mit 2FA-Catch-all, belegte Restore-Drills für alle Tier-1/2-Dienste,
Off-site-Borg nach Hetzner, DR-Workstation-Kit, Monitoring mit Prometheus/
Loki/Grafana/Alertmanager→ntfy. Die Doku-Disziplin ist das eigentliche Asset.
Die größten realen Lücken liegen nicht in der Architektur, sondern in der
**Container-Betriebsebene**: 20 von 30 Stacks haben keinen Healthcheck, kein
einziger Container hat Memory-/CPU-Limits, und mehrere Images laufen auf
mutablen Tags (`release`, `latest`, `:2`), bei denen Renovate-Digest-Bumps
faktisch unkontrollierte Versionssprünge sind — am kritischsten bei Immich.
Dazu kommen zwei strukturelle Risiken: **AdGuard ist DNS-SPOF ohne Fallback**
(hat bereits einen Teil-Deploy-Ausfall verursacht) und **Borg-Backups sind
vom Host aus löschbar** (append-only bewusst abgelehnt, aber die kostenlose
Kompensation — Hetzner-Storage-Box-Snapshots — ist nicht aktiviert).
## Gesamtbewertung
| Bereich | Note | Begründung |
|---|---|---|
| Architektur | **sehr gut** | klares Netzmodell, dokumentierte Ausnahmen, ein Ingress, Compose-first konsequent |
| Netzwerk/DNS/Proxy | **gut, ein SPOF** | Traefik v3 labelbasiert sauber; AdGuard+Unbound ohne zweiten Resolver — bekannter Vorfall (Bulk-Deploy-DNS-Ausfall, `docs/runbooks/komodo-bulk-deploy-dns.md`) |
| Container-Betrieb | **mittel** | 10/30 Stacks mit Healthcheck, 0 Ressourcen-Limits, mutable Tags hinter Digests versteckt |
| Storage/Backups | **sehr gut** | Borg→Hetzner, Dumps, H:/-Nearline, Restore-Drills mit Reports belegt; offen: Backup-Löschschutz |
| Security/Secrets | **gut** | `_FILE`/Stack-ENV konsequent, 2FA-Catch-all, WAN nur 443/tcp; `no-new-privileges` nur in 10/30 Stacks trotz P8-Pflichtregel |
| Monitoring/Alerting | **gut** | Prometheus/Blackbox/Loki/ntfy-Kette steht; Monitoring-Stack selbst hat keine Healthchecks und überwacht sich nicht selbst |
| Automatisierung/IaC | **sehr gut** | Komodo-Webhooks, Renovate, Posture-Check, Critical-Events-Watcher; manuelle Sync-Ausnahmen (traefik/dynamic, Authelia-Config) sind dokumentiert, aber fehleranfällig |
| Ausfallsicherheit | **bewusst begrenzt** | Ein Host, keine USV (geparkt Q3/2026), kein WAN-Failover — als akzeptiertes Risiko dokumentiert, das ist legitim |
| Strom/Kosten | **keine Daten** | keine Verbrauchsmessung im Repo sichtbar — siehe offene Fragen |
## Top 10 Verbesserungen nach Mehrwert
### 1. Immich vom `release`-Tag auf Versions-Tag pinnen
- **Beobachtung:** `apps/immich/docker-compose.yml:4` nutzt `immich-server:release@sha256:...` (ebenso ML). Renovate aktualisiert Digests — beim `release`-Tag ist ein "Digest-Update" in Wahrheit ein Major-/Minor-Versionssprung, ohne dass es im PR-Titel sichtbar wird. Immich ist berüchtigt für Breaking Changes zwischen Minors.
- **Warum relevant:** Ein gemergter "harmloser" Digest-PR kann Immich unangekündigt auf eine inkompatible Version heben (DB-Migrationen, ML-Modell-Wechsel).
- **Änderung:** Tag auf die konkret laufende Version umstellen (z. B. `immich-server:v2.x.y@sha256:<aktueller Digest>`), gleiche Vorgehensweise wie bei Mealie/Paperless. Laufende Version ermitteln: `docker exec immich_server cat /usr/src/app/package.json | grep version` oder Immich-UI → Version.
- **Verifikation:** Renovate erzeugt danach Versions-PRs statt stiller Digest-PRs; `docker inspect immich_server --format '{{.Config.Image}}'` zeigt den Versionstag.
- **Rollback:** Commit revert; Digest bleibt identisch, kein Redeploy-Zwang.
- **Nebenwirkungen:** keine zur Laufzeit (Digest unverändert). | Nutzen: **hoch** | Risiko: niedrig | Aufwand: klein | sofort
- Gleiches Muster prüfen für: `komodo:2`, `ddns-updater:latest`, `scrutiny:latest-omnibus`, `glances:latest-full` sowie tag-lose digest-only Images (`mail-archiver`, `borg-ui`, `ntfy` — Version im Compose unsichtbar).
### 2. Hetzner-Storage-Box-Snapshots als Ransomware-/Fehlbedienungsschutz aktivieren
- **Beobachtung:** Borg `append-only` wurde am 2026-06-01 bewusst verworfen (forced-command brach Key-Auth). Damit kann jeder mit dem Borg-Key (Host, borg-ui-Container mit `/local/secrets`-Mount) Archive **löschen** — ein kompromittierter Host vernichtet auch das Off-site-Backup.
- **Warum relevant:** Das ist die einzige verbliebene Lücke in einer sonst sehr guten Backup-Kette.
- **Änderung:** In der Hetzner-Robot-Konsole automatische Snapshots der Storage Box aktivieren (z. B. täglich, 7–14 Tage Retention). Snapshots sind host-seitig nicht löschbar und im Storage-Box-Preis enthalten.
- **Verifikation:** Robot-Konsole zeigt Snapshot-Liste; nach 2 Tagen: zwei Snapshots vorhanden. Restore-Probe: einzelne Datei aus Snapshot über das Snapshot-Verzeichnis lesen.
- **Rollback:** Snapshots deaktivieren — rein additiv, keine Auswirkung auf Borg.
- **Nebenwirkungen:** Snapshots zählen ggf. anteilig aufs Quota (aktuell 65 GB / 1 TB — viel Luft). | Nutzen: **sehr hoch** | Risiko: niedrig | Aufwand: klein (<30 min) | sofort
### 3. DNS-Fallback gegen den AdGuard-SPOF
- **Beobachtung:** AdGuard ist einziger LAN-Resolver. Der dokumentierte Vorfall (Bulk-Deploy: AdGuard-Recreate → Host ohne DNS → Komodo-Pulls scheitern) ist genau dieses Muster; das Runbook behandelt nur das Symptom.
- **Warum relevant:** Jeder AdGuard-Ausfall (Update, OOM, Disk) nimmt LAN + Host-DNS gleichzeitig mit — auch die Reparaturfähigkeit (Image-Pulls!) hängt daran.
- **Änderung (gestuft):**
- a) Host-Ebene: zweiten Nameserver (z. B. `1.1.1.1`) in der Unraid-Netzwerkkonfig als Fallback hinter `192.168.178.58` eintragen. Damit kann der Host immer Images pullen.
- b) LAN-Ebene: in der FRITZ!Box als zweiten lokalen DNS die FRITZ!Box selbst (oder einen Public DNS) hinterlegen — bewusster Trade-off: bei AdGuard-Down kein Ad-Blocking statt kein Internet.
- **Verifikation:** `docker stop adguard` im Wartungsfenster → `nslookup gitea.com` auf dem Host funktioniert weiterhin; danach `docker start adguard`.
- **Rollback:** Nameserver-Eintrag entfernen.
- **Nebenwirkungen:** DNS-Anfragen können am Filter vorbeilaufen, solange AdGuard down ist (gewollt); Fallback-Resolver sieht dann Anfragen (Privacy-Abwägung). | Nutzen: **hoch** | Risiko: niedrig | Aufwand: klein | diese Woche
### 4. Healthchecks für die App-Stacks nachrüsten
- **Beobachtung:** Nur 10 von 30 Compose-Dateien definieren Healthchecks (traefik, gitea, vaultwarden, authelia, postgresql17, redis, komodo, bentopdf, glances, hermes). **Ohne:** Nextcloud (App+DB+Redis), Immich (alle 4), Paperless, Mealie, Mail-Archiver, n8n, AdGuard, Unbound und der komplette Monitoring-Stack (11 Services).
- **Warum relevant:** Ohne Healthcheck meldet Docker "Up", auch wenn die App hängt; der Critical-Events-Watcher sieht nur `die`/`oom`, keine Hänger. Prometheus-Blackbox prüft nur HTTP-Routen von außen.
- **Änderung:** Pro Stack einen minimalen Healthcheck ergänzen, priorisiert: Nextcloud (`curl -f http://localhost/status.php`), Paperless, Mealie, n8n, Unbound (`drill @127.0.0.1 cloudflare.com` bzw. `unbound-control status`), AdGuard. Stackweise deployen, nicht als Bulk (siehe DNS-Runbook!).
- **Verifikation:** `docker ps --format '{{.Names}} {{.Status}}'` zeigt `(healthy)`; cAdvisor/Glance zeigen Health-Status.
- **Rollback:** Healthcheck-Block entfernen, Redeploy — kein Datenrisiko.
- **Nebenwirkungen:** Falsch kalibrierte Checks (zu kurze `start_period`) können Flapping erzeugen; konservativ starten (`interval: 60s`, `retries: 5`). | Nutzen: **hoch** | Risiko: niedrig | Aufwand: mittel | diesen Monat
### 5. Memory-Limits für die größten Verbraucher
- **Beobachtung:** Kein einziger Service hat `mem_limit`/`deploy.resources`. Auf einem Ein-Host-System konkurrieren ~50 Container; ein Speicherleck (Immich-ML, Nextcloud-PHP, Loki) kann den Host-OOM-Killer auslösen, der dann beliebige Tier-1-Container trifft (Postgres!).
- **Warum relevant:** Der OOM-Killer wählt nach Score, nicht nach Wichtigkeit. Limits machen den Blast-Radius deterministisch: die fehlerhafte App stirbt, nicht die Datenbank.
- **Änderung:** Erst messen: `docker stats --no-stream --format '{{.Name}}\t{{.MemUsage}}'` über ein paar Tage (oder cAdvisor-Dashboard `container_memory_working_set_bytes`). Dann Limits = Peak × 1,5 für die Top-5-Verbraucher (typisch: immich-ml, nextcloud, paperless, plex, prometheus) setzen.
- **Verifikation:** `docker inspect <c> --format '{{.HostConfig.Memory}}'`; Grafana-Panel Memory vs. Limit; keine neuen `oom`-Events im Critical-Events-Log.
- **Rollback:** Limit-Zeilen entfernen, Redeploy.
- **Nebenwirkungen:** Zu knappe Limits OOM-killen die App selbst — deshalb messen statt raten, und Limits nur bei unkritischen Apps zuerst. | Nutzen: **hoch** | Risiko: mittel | Aufwand: mittel | diesen Monat
### 6. `no-new-privileges` flächendeckend gemäß P8
- **Beobachtung:** Architektur-Regel P8 verlangt `no-new-privileges:true` standardmäßig; gesetzt ist es nur in 10 von 30 Stacks. Es fehlt u. a. bei allen Apps mit WAN-Exposition (Nextcloud, Immich, Paperless, Mealie, ntfy, n8n).
- **Warum relevant:** Billige Defense-in-Depth gegen Privilege-Escalation nach App-Kompromittierung — genau bei den exponierten Diensten am wertvollsten. Aktuell: dokumentierte Regel ≠ gelebter Stand (Policy-Drift).
- **Änderung:** `security_opt: ["no-new-privileges:true"]` in die fehlenden Stacks, stackweise mit Smoke-Test. Vorsicht bei Images mit s6/sudo-Setup (LSIO-Images wie speedtest/code-server haben es teils schon — prüfen) und bei Plex (Host-Netz, zuerst testen).
- **Verifikation:** `docker inspect <c> --format '{{.HostConfig.SecurityOpt}}'`; Posture-/Policy-Check erweitern, damit Drift künftig alarmiert.
- **Rollback:** Zeile entfernen, Redeploy.
- **Nebenwirkungen:** Container, die intern setuid brauchen (selten: einige Init-Systeme), starten nicht — fällt im Smoke-Test sofort auf. | Nutzen: mittel | Risiko: niedrig | Aufwand: mittel | diesen Monat
### 7. traefik/dynamic-Sync automatisieren statt manuell
- **Beobachtung:** `traefik/dynamic/*` (middlewares, tls, dashboards, plex) wird laut dokumentierter Ausnahme **manuell** auf den Host synchronisiert. Das ist die klassische Quelle für "Repo sagt A, Host macht B" — besonders heikel, weil hier Auth-Middlewares definiert sind.
- **Warum relevant:** Ein vergessener Sync nach einer Middleware-Änderung kann unbemerkt eine Schutzschicht im Live-Zustand alt lassen; auffallen würde es erst beim Audit.
- **Änderung:** Kleines Sync-Skript analog `services/authelia-diff.sh`: Repo-Spiegel `/mnt/user/services/homelab-infra/traefik/dynamic/` per `rsync --checksum --dry-run` gegen `/mnt/user/appdata/traefik/dynamic/` diffen; Diff ≠ leer → ntfy-Warnung über den bestehenden Posture-Check. (Stufe 2 optional: automatisch syncen; erst nur alarmieren.)
- **Verifikation:** Testweise eine Whitespace-Änderung im Repo-Spiegel → Posture-Check meldet `traefik_dynamic_drift`.
- **Rollback:** Check aus dem Posture-Skript entfernen; rein lesend, kein Produktionsrisiko.
- **Nebenwirkungen:** keine (read-only Check). | Nutzen: mittel | Risiko: niedrig | Aufwand: klein | diese Woche
### 8. Watchdog für den Monitoring-Stack selbst (Dead-Man's-Switch)
- **Beobachtung:** Die Alert-Kette ist Prometheus → Alertmanager → Bridge → ntfy. Fällt ein Glied (oder der ganze Monitoring-Stack) aus, kommen schlicht **keine** Alerts mehr — Stille ist nicht von "alles gut" unterscheidbar. Kein Healthcheck im Monitoring-Compose.
- **Warum relevant:** Das Monitoring überwacht alles außer sich selbst.
- **Änderung:** Dauerhaft feuernde `Watchdog`-Alert-Rule in `monitoring/prometheus/alerts.yml` + externen Heartbeat-Empfänger: einfachste Variante ist healthchecks.io (free) — Alertmanager-Route schickt den Watchdog alle 5 min an die Heartbeat-URL; bleibt er aus, alarmiert healthchecks.io per Mail/Push von außen.
- **Verifikation:** `docker stop monitoring-prometheus` im Wartungsfenster → externe Benachrichtigung nach ~10 min; danach Start.
- **Rollback:** Rule + Route entfernen.
- **Nebenwirkungen:** neue (kleine) externe Abhängigkeit — in `docs/EXTERNAL_DEPENDENCIES.md` eintragen. | Nutzen: **hoch** | Risiko: niedrig | Aufwand: klein | diese Woche
### 9. Lokale Arbeitskopie sauber halten (GitOps-Hygiene)
- **Beobachtung:** Die lokale Arbeitskopie hat aktuell 6 modifizierte Dateien und 2 untracked Artefakte (u. a. `docs/KalliLab_CORE_Audit_2026-06-06.pdf`, `ops/h-drive-nearline/README.md`), die nicht committed sind. Bei "Gitea = Quelle der Wahrheit" ist eine dauerhaft schmutzige Arbeitskopie ein Drift-Risiko (Änderungen gehen bei Pull-Konflikten verloren oder landen versehentlich in fremden Commits).
- **Warum relevant:** Genau die Drift-Klasse, vor der `docs/GITOPS_DRIFT_RUNBOOK.md` warnt — nur auf Ebene 2 (lokaler Clone) statt Ebene 4.
- **Änderung:** Modifizierte Doku-Dateien reviewen und committen oder verwerfen; PDF entweder committen (wenn es Referenz ist) oder in `.gitignore`/außerhalb des Repos ablegen; `ops/h-drive-nearline/README.md` committen.
- **Verifikation:** `git status` zeigt clean tree (bis auf bewusste Arbeit).
- **Rollback:** n/a (Aufräumarbeit). | Nutzen: mittel | Risiko: niedrig | Aufwand: klein (<30 min) | sofort
### 10. Doku-Drift-Fixes (klein, aber Vertrauensbasis)
- **Beobachtung:** `HOMELAB_ARCHITECTURE_MASTER_V2.md` nennt "Redis-Caches auf `redis:7.4-alpine` vereinheitlicht" — real laufen alle auf `redis:8.8.0-alpine`. Ebenso "PostgreSQL 17"-Pfade/Servicenamen bei PG 18 (letzteres ist dokumentiert bewusst, ersteres nicht).
- **Warum relevant:** Das Masterdokument ist laut eigener Regel die erste Lesepflicht für jeden (auch KI-)Eingriff; veraltete Fakten dort erzeugen falsche Entscheidungen.
- **Änderung:** Redis-Abschnitt in Sektion 13 auf 8.8 aktualisieren; bei Gelegenheit einen Mini-Check ins Posture-/Audit-Ritual: "stimmen Versionsangaben im Master noch?"
- **Verifikation:** `grep -n "7.4-alpine" HOMELAB_ARCHITECTURE_MASTER_V2.md` → leer.
- **Rollback:** trivial (Doku). | Nutzen: niedrig–mittel | Risiko: keiner | Aufwand: klein | sofort
## Top 5 Risiken (zuerst entschärfen)
1. **Löschbare Off-site-Backups** — Host-Kompromittierung oder ein falscher `borg delete` vernichtet auch Hetzner. → Empfehlung 2 (Snapshots). Bis dahin ist das DR-Konzept gegen Ransomware unvollständig.
2. **DNS-SPOF AdGuard** — bereits einmal real eingetreten (Teil-Deploy 2026-06); betrifft auch die Selbstheilungsfähigkeit (Image-Pulls). → Empfehlung 3.
3. **Verdeckte Versionssprünge via `release`/`latest`-Digest-Bumps** — v. a. Immich (DB-Migrationen!). → Empfehlung 1.
4. **OOM-Kaskade ohne Limits** — ein Leck in einer Tier-3-App kann Postgres killen. → Empfehlung 5. (Der Critical-Events-Watcher meldet das nur, verhindert es nicht.)
5. **Blinde Alert-Kette** — Monitoring-Ausfall = Stille statt Alarm. → Empfehlung 8.
Bewusst akzeptierte Risiken (USV geparkt, ein Host, kein WAN-Failover, kein
zweites Off-site-Ziel) sind dokumentiert und werden hier nicht erneut
aufgemacht — die Entscheidungen sind nachvollziehbar.
## Quick Wins unter 30 Minuten
| Quick Win | Wirkung | Kommando/Weg |
|---|---|---|
| Hetzner-Snapshots aktivieren | Backup-Löschschutz | Robot-Konsole → Storage Box → Snapshots (Empf. 2) |
| Host-DNS-Fallback eintragen | Selbstheilung bei AdGuard-Down | Unraid Settings → Network → DNS 2 = `1.1.1.1` (Empf. 3a) |
| Arbeitskopie aufräumen | GitOps-Hygiene | `git status`, committen/verwerfen (Empf. 9) |
| Redis-Doku-Drift fixen | Master-Doku wieder korrekt | Sektion 13 editieren (Empf. 10) |
| Memory-Baseline ziehen | Grundlage für Limits | `docker stats --no-stream` auf dem Host, Output archivieren |
| Watchdog-Rule anlegen | Vorbereitung Dead-Man's-Switch | `alerts.yml` + healthchecks.io-Account (Empf. 8) |
## 30-Tage-Optimierungsplan
**Woche 1 — Risiko-Entschärfung (alles klein):**
Hetzner-Snapshots (Empf. 2) · Host-DNS-Fallback + Stop/Start-Test (Empf. 3a) ·
Immich-Tag-Pinning (Empf. 1) · Arbeitskopie aufräumen (Empf. 9) ·
Memory-Baseline starten.
**Woche 2 — Beobachtbarkeit:**
Dead-Man's-Switch produktiv (Empf. 8) · traefik/dynamic-Drift-Check in den
Posture-Check (Empf. 7) · Healthchecks für Nextcloud, Paperless, Mealie, n8n
(Empf. 4, stackweise).
**Woche 3 — Hardening:**
`no-new-privileges` für alle WAN-exponierten Apps (Empf. 6) · Healthchecks
für AdGuard/Unbound/Monitoring-Kern · restliche Mutable-Tag-Kandidaten pinnen
(komodo, scrutiny, glances, ddns-updater, tag-lose digest-only Images).
**Woche 4 — Stabilität:**
Memory-Limits aus der Baseline für die Top-5-Verbraucher (Empf. 5) ·
FRITZ!Box-DNS-Fallback-Entscheidung (Empf. 3b) · Doku nachziehen
(Master Sektion 13, SERVICE_CATALOG, dieses Dokument abhaken).
## Größere Projekte mit hohem Nutzen (später)
- **End-to-end-DR-Drill** sobald zweite Hardware existiert (bereits geplant,
bleibt der wertvollste offene Beweis).
- **Strom-/Kostentransparenz:** smarte Steckdose mit Messfunktion (z. B.
Shelly Plug S) vor den Unraid-Host, Werte via Home Assistant → InfluxDB 3 →
Grafana. Erst messen, dann ggf. optimieren (Spindown-Policy, CPU-Governor).
Messbarkeit: W-Dauerlast und kWh/Monat als Grafana-Panel.
- **USV-Review Q3/2026** wie geparkt — nach Strommessung lässt sich die
USV-Dimensionierung direkt ableiten.
- **Renovate-Policy verfeinern:** Digest-PRs für mutable Tags entweder
abschalten oder mit Warn-Label versehen, damit Befund 1 strukturell nicht
zurückkommt.
## Konkrete Verifikationskommandos (Sammlung, alle read-only)
```bash
# Health-Status aller Container
docker ps --format '{{.Names}}\t{{.Status}}' | sort
# Memory-Baseline
docker stats --no-stream --format '{{.Name}}\t{{.MemUsage}}\t{{.MemPerc}}' | sort -k3 -hr | head -15
# Welche Container ohne no-new-privileges laufen
docker ps -q | xargs docker inspect --format '{{.Name}} {{.HostConfig.SecurityOpt}}' | grep -v no-new-privileges
# Effektive Image-Referenzen (mutable Tags erkennen)
docker ps --format '{{.Names}}\t{{.Image}}' | grep -E 'latest|release|:2$|:[0-9]+$'
# DNS-Fallback-Test (Wartungsfenster!)
docker stop adguard && nslookup gitea.com && docker start adguard
# Borg-Snapshot-Gegenprobe (nach Aktivierung, von der Storage Box)
ssh -p 23 u565255@u565255.your-storagebox.de ls .snapshots/ 2>/dev/null || echo "via Robot-Konsole prüfen"
```
## Rollback-Hinweise (generell)
- Jede Compose-Änderung: Revert-Commit nach Gitea pushen → Komodo deployed
den Vorzustand; Datenpfade bleiben unberührt (alle Empfehlungen hier sind
config-only, keine Daten-/Volume-Migrationen).
- Healthchecks/Limits/security_opt: Zeilen entfernen + Redeploy genügt.
- Host-DNS/FRITZ!Box-Einträge: Eintrag löschen, sofort wirksam.
- Hetzner-Snapshots und Dead-Man's-Switch sind rein additiv.
- Nichts in diesem Dokument erfordert `push --force`, History-Rewrite oder
Löschoperationen auf Datenpfaden.
## Offene Fragen an den Operator
1. **Strom:** Gibt es eine Messung des Host-Verbrauchs (W idle/last)? Ohne
Zahl ist der Bereich Kosten/Strom nicht bewertbar. → Shelly/Messsteckdose?
2. **RAM-Ausstattung des Hosts:** Wie viel RAM hat Kallilabcore gesamt und
wie ist die aktuelle Auslastung (`free -h`)? Bestimmt, wie aggressiv
Memory-Limits sinnvoll sind.
3. **Renovate-Verhalten gewollt?** Sollen Digest-Bumps auf `release`/`latest`
weiter automatisch als PRs kommen, oder ist die Pinning-Strategie aus
Empfehlung 1 die gewünschte Linie für alle Stacks?
4. **healthchecks.io o. ä. als externe Abhängigkeit akzeptabel?** Alternativ
ginge ein ntfy-basierter Heartbeat von einem zweiten Gerät (z. B. dem
Gaming-PC per Scheduled Task) — null neue Cloud-Abhängigkeit.
5. **FRITZ!Box-DNS-Fallback (3b):** Filterlücke bei AdGuard-Down akzeptieren
oder lieber nur den Host-Fallback (3a) umsetzen?
docs/runbooks/komodo-bulk-deploy-dns.md
-58
View File
@@ -1,58 +0,0 @@
# Runbook: Komodo Bulk-Deploy schlaegt mit DNS `connection refused` fehl
Stand: 2026-06-10 · Typ: Runbook / ADR-light · Status: Sofortmassnahme empfohlen, noch nicht umgesetzt
## Symptom
Ein Bulk-Merge (z. B. Renovate-Sammel-PR) loest gleichzeitig viele Komodo-Stack-Webhooks aus. Komodo startet parallele `DeployStack`. Nur ein Teil der Stacks deployt, der Rest bleibt auf dem alten Image. In der Deploy-Stufe **Compose Pull** stehen Fehler wie:
```
Get "https://registry-1.docker.io/v2/": dial tcp: lookup registry-1.docker.io
on 192.168.178.58:53: read udp ...->192.168.178.58:53: read: connection refused
```
Manuelles Re-Deploy der betroffenen Stacks danach funktioniert (AdGuard ist dann wieder oben).
## Ursache
Der Host nutzt **AdGuard Home als einzigen Resolver** (`/etc/resolv.conf` = nur `nameserver 192.168.178.58`, keine `/etc/docker/daemon.json`). AdGuard laeuft selbst als Container auf dem Host und bindet `0.0.0.0:53`. Wird der `adguard`-Stack im selben Batch neu deployt, faellt Port 53 fuer Sekunden aus. Alle parallelen `docker compose pull` der anderen Stacks koennen `registry-1.docker.io` dann nicht aufloesen -> `connection refused` -> Deploy `success=false`.
Es ist **kein** Webhook-, Auth- oder Docker-Hub-Rate-Limit-Problem: Webhooks authentifizieren sauber, `webhook_enabled=true`, Fehlerbild ist `connection refused` auf den eigenen DNS-Port direkt nach AdGuard-Recreate. Fuer den Pull-Pfad zaehlt der Docker-Daemon/Go-Resolver (iteriert ueber die `resolv.conf`-Server und springt bei Socket-Fehlern zum naechsten), nicht der glibc-Client.
## Sofortmassnahme (Schicht 1)
Unraid -> Settings -> Network Settings -> `eth0`:
- DNS server 1: `192.168.178.58` (AdGuard, bleibt)
- **DNS server 2: `192.168.178.1`** (FritzBox) -> Apply
Damit ueberleben Registry-Pulls einen kurzen AdGuard-Ausfall via Resolver-Failover. Im Normalbetrieb wird weiter DNS1 (AdGuard) genutzt, der Filter bleibt aktiv.
Pruefen / Bedingungen:
- **Kein `options rotate`** in `/etc/resolv.conf` (sonst dauerhafter Filter-Bypass). Aktuell nicht gesetzt; nach Apply erneut pruefen.
- Router muss oeffentliche Namen **selbst** aufloesen und nicht intern an AdGuard zurueckleiten.
- Hinweis zur Verifikation: Ein `nslookup registry-1.docker.io 192.168.178.1` bei laufendem AdGuard ist ein gutes Signal, aber **kein letzter Beweis**. Wasserdicht: AdGuard kurz stoppen und `dig @192.168.178.1 registry-1.docker.io`, oder FritzBox-Upstream / AdGuard-Querylog pruefen.
Rollback: DNS server 2 leeren + Apply.
## Betriebsregel (Schicht 2)
- **AdGuard und Unbound nicht gemeinsam mit abhaengigen Stacks im Bulk deployen.** DNS-Infrastruktur immer separat / einzeln deployen, nicht waehrend 20+ parallele Pulls laufen.
- Renovate-PRs gestaffelt mergen (eine Etappe pro Deploy) statt Sammel-Merge. Deckt dieses Problem fuer den Normalbetrieb bereits ab.
## Spaeter optional
- Komodo-Deploys serialisieren: statt vieler paralleler Stack-Webhooks eine **Procedure** (sequenzielle Stages) oder **Resource Sync** mit `after`-Ordering. Trifft die Ursache direkter, ist aber ein groesserer Umbau und **kein Renovate-Blocker**.
- Host-DNS vom AdGuard-Container entkoppeln (AdGuard eigene IP via macvlan, Host-Resolver auf Router/Unbound), damit `:53` am Host nicht exklusiv am Container-Lifecycle haengt.
## Verworfen
- `/etc/docker/daemon.json` mit `"dns": [...]`: wirkt nur fuer Container-DNS, nicht fuer Daemon-eigene Image-Pulls.
- AdGuard `network_mode: host`: beim Recreate ist der DNS-Prozess trotzdem weg; macht aus dem Single Point of Failure keinen HA-Resolver.
## Referenzen
- Diagnose-Zugriff: SSH `root@192.168.178.58`; Komodo-Mongo (`docker exec komodo-mongo`, DB `komodo`, Collections `Stack`/`Update`); Gitea SQLite `/data/gitea/gitea.db` (Tabelle `webhook`, `repo_id=3`).
- Verwandt: `docs/WORKFLOW.md` (DNS-Regeln fuer Container), `docs/GITOPS_DRIFT_RUNBOOK.md`.
</content>
host-services/Adguard/docker-compose.yml
+1 -1
View File
@@ -1,6 +1,6 @@
services:
adguard:
image: adguard/adguardhome:v0.107.77@sha256:e6f2b8bcda06064ab055b44933a4f0e983c35558b9cdb8d2e7ab1efcee36d890
image: adguard/adguardhome:v0.107.76@sha256:7157eb1dc3b26c7af1d6898759a7b3f7d0fa09891fbd2d3caa6abc1057a9179b
container_name: adguard
restart: unless-stopped
volumes:
host-services/tailscale/docker-compose.yml
+25
View File
@@ -0,0 +1,25 @@
services:
tailscale:
image: tailscale/tailscale:stable@sha256:25cde9ad76020b0e29229136d0c38b5962e9a0e1774ffac9b0df68e4a37d6cf0
container_name: Tailscale-Docker
restart: unless-stopped
network_mode: host
cap_add:
- NET_ADMIN
- NET_RAW
security_opt:
- no-new-privileges:true
devices:
- /dev/net/tun:/dev/net/tun
environment:
- TZ=Europe/Berlin
- TS_HOSTNAME=kallilab-core
- TS_STATE_DIR=/state
- TS_AUTH_ONCE=true
volumes:
- /mnt/user/appdata/tailscale:/state
monitoring/docker-compose.yml
+6 -29
View File
@@ -25,7 +25,7 @@ services:
- cadvisor
alertmanager:
image: prom/alertmanager:v0.32.2@sha256:b85533a2eb45865835315810315f6951331b2dbc8c93a6cf9a51e156a006a706
image: prom/alertmanager:v0.32.1@sha256:51a825c2a40acc3e338fdd00d622e01ec090f72be2b3ea46be0839cd47a4d286
container_name: monitoring-alertmanager
restart: unless-stopped
command:
@@ -66,18 +66,15 @@ services:
image: prom/blackbox-exporter:v0.28.0@sha256:e753ff9f3fc458d02cca5eddab5a77e1c175eee484a8925ac7d524f04366c2fc
container_name: monitoring-blackbox-exporter
restart: unless-stopped
# Use AdGuard so *.kaleschke.info resolves to the internal Traefik IP.
# External resolvers (1.1.1.1/8.8.8.8) return the public WAN IP, which
# causes hairpin-NAT timeouts when probing from inside the Docker network.
dns:
- 172.23.0.3
- 1.1.1.1
- 8.8.8.8
command:
- --config.file=/etc/blackbox_exporter/blackbox.yml
volumes:
- ./blackbox/blackbox.yml:/etc/blackbox_exporter/blackbox.yml:ro
networks:
- monitoring_net
- dns_net
expose:
- "9115"
security_opt:
@@ -118,7 +115,7 @@ services:
- loki
grafana:
image: grafana/grafana:13.0.2@sha256:5dad0df181cb644a14e13617b913b261a54f7d4fd4510721dba420929f35bea2
image: grafana/grafana:13.0.1@sha256:0f86bada30d65ef9d0183b90c1e2682ac92d53d95da8bed322b984ea78a4a73a
container_name: monitoring-grafana
user: "0"
restart: unless-stopped
@@ -132,20 +129,6 @@ services:
GF_USERS_ALLOW_SIGN_UP: "false"
GF_AUTH_ANONYMOUS_ENABLED: "false"
GF_PLUGINS_PREINSTALL_DISABLED: "true"
# --- Authelia OIDC SSO (2026-06-06) ---
GF_AUTH_GENERIC_OAUTH_ENABLED: "true"
GF_AUTH_GENERIC_OAUTH_NAME: Authelia
GF_AUTH_GENERIC_OAUTH_CLIENT_ID: grafana
GF_AUTH_GENERIC_OAUTH_CLIENT_SECRET__FILE: /run/secrets/grafana_oidc_client_secret
GF_AUTH_GENERIC_OAUTH_SCOPES: "openid profile email groups"
GF_AUTH_GENERIC_OAUTH_AUTH_URL: https://auth.kaleschke.info/api/oidc/authorization
GF_AUTH_GENERIC_OAUTH_TOKEN_URL: https://auth.kaleschke.info/api/oidc/token
GF_AUTH_GENERIC_OAUTH_API_URL: https://auth.kaleschke.info/api/oidc/userinfo
GF_AUTH_GENERIC_OAUTH_USE_PKCE: "true"
GF_AUTH_GENERIC_OAUTH_ALLOW_SIGN_UP: "true"
# Proof: alle OIDC-Logins als Admin; spaeter ueber groups verfeinern
GF_AUTH_GENERIC_OAUTH_ROLE_ATTRIBUTE_PATH: "'Admin'"
GF_AUTH_GENERIC_OAUTH_ROLE_ATTRIBUTE_STRICT: "false"
entrypoint:
- /bin/sh
- -c
@@ -162,7 +145,6 @@ services:
secrets:
- monitoring_grafana_admin_password
- monitoring_grafana_influxdb_token
- grafana_oidc_client_secret
expose:
- "3000"
security_opt:
@@ -178,8 +160,7 @@ services:
- traefik.http.routers.monitoring-grafana.entrypoints=websecure
- traefik.http.routers.monitoring-grafana.tls=true
- traefik.http.routers.monitoring-grafana.tls.certresolver=le
# ForwardAuth bewusst entfernt 2026-06-06: Grafana macht jetzt eigenes OIDC-SSO gegen Authelia
- traefik.http.routers.monitoring-grafana.middlewares=secure-headers@file
- traefik.http.routers.monitoring-grafana.middlewares=authelia@file,secure-headers@file
- traefik.http.services.monitoring-grafana.loadbalancer.server.port=3000
grafana-dashboard-importer:
@@ -337,7 +318,7 @@ services:
- no-new-privileges:true
influxdb3-core:
image: influxdb:3.9.3-core@sha256:c27c9b2ca2625b5b6966f0b09baa448102310e63a471fd60dff22646a2522e29
image: influxdb:3.9.2-core@sha256:31ad94df2248134989b2cf73d965e51dd5f35dfae22d7ed8f4776b12e6f69f4e
container_name: monitoring-influxdb3-core
user: "0"
restart: unless-stopped
@@ -370,8 +351,6 @@ networks:
driver: bridge
frontend_net:
external: true
dns_net:
external: true
volumes:
prometheus_data:
@@ -385,7 +364,5 @@ secrets:
file: /mnt/user/appdata/secrets/monitoring_grafana_admin_password.txt
monitoring_grafana_influxdb_token:
file: /mnt/user/appdata/secrets/monitoring_grafana_influxdb_token.txt
grafana_oidc_client_secret:
file: /mnt/user/appdata/secrets/grafana_oidc_client_secret
influxdb3_admin_token:
file: /mnt/user/appdata/secrets/influxdb3_admin_token.json
ops/borg-ui/BACKUP_SCOPE.md
+4 -2
View File
@@ -90,16 +90,18 @@ The live Unraid User Scripts execute repo scripts from `/mnt/user/services/homel
## Explicitly Not Backed Up as Raw Live DB Files
- `/mnt/user/appdata/postgresql17`
- `/mnt/user/appdata/postgresql18`
- `/mnt/user/appdata/mealie/postgres`
- `/mnt/user/appdata/mealie/postgres18`
- `/mnt/user/appdata/immich_postgres`
- `/mnt/user/appdata/immich_postgres_vectorchord`
- `/mnt/user/appdata/nextcloud/postgres`
- `/mnt/user/appdata/nextcloud/postgres18`
- `/mnt/user/appdata/komodo/mongo`
- `/mnt/user/appdata/redis`
- `/mnt/user/appdata/scrutiny/influxdb`
Archived PG18/VectorChord rollback volumes under `/mnt/user/appdata/_archive/pg18-immich-rollback-volumes-20260602` are retained only as temporary rollback material, not as primary backup truth.
## Low-Priority / Rebuildable
These are not part of the first-class Borg scope:
ops/borg-ui/docker-compose.yml
+1 -1
View File
@@ -1,6 +1,6 @@
services:
borg-ui:
image: ainullcode/borg-ui@sha256:0922157e8f77a1b2bd23cd09366a458ea6de07fd9306aa1485f9cfe623eca17f
image: ainullcode/borg-ui@sha256:b44c0a92b650d80f215a986dadda5c2604c61eb28a7571e19c046eff41d761e7
container_name: borg-ui
restart: unless-stopped
security_opt:
ops/code-server/docker-compose.yml
+1 -1
View File
@@ -1,6 +1,6 @@
services:
code-server:
image: lscr.io/linuxserver/code-server:4.123.0@sha256:cb261a7f87674b445e0fd66d87d55900c1b823d276c727ab0d168a75e69e9992
image: lscr.io/linuxserver/code-server:4.122.0@sha256:0caf1b65ebec84b94397108b56da6c33f124c5390f5832da94e75f4609c0e2ad
container_name: code-server
restart: unless-stopped
security_opt:
ops/filebrowser/docker-compose.yml
+1 -1
View File
@@ -1,6 +1,6 @@
services:
filebrowser:
image: filebrowser/filebrowser:v2.63.14@sha256:1ec9b0c68297550c92f4a93feed432850c2993b261706cc3cc2e808f94a95e76
image: filebrowser/filebrowser:v2.63.5@sha256:aefb0c20de10ef8b617995ca5522479ad40d41e6386bd01946a345c6026ff31c
container_name: filebrowser
restart: unless-stopped
security_opt:
ops/glance/config/glance.yml
+6
View File
@@ -497,6 +497,12 @@ pages:
description: Upstream Resolver
category: network
hide: false
Tailscale-Docker:
name: Tailscale
icon: https://cdn.jsdelivr.net/gh/homarr-labs/dashboard-icons/svg/tailscale.svg
description: VPN
category: network
hide: false
ddns-updater:
name: DDNS Updater
icon: mdi:cloud-sync
ops/hermes-agent/Dockerfile
+1 -1
View File
@@ -1,4 +1,4 @@
FROM nousresearch/hermes-agent:v2026.6.5
FROM nousresearch/hermes-agent:v2026.5.29
USER root
ops/hermes-agent/services.json
+2 -2
View File
@@ -99,7 +99,7 @@
"dump_file": null,
"data_paths": ["/mnt/user/appdata/postgresql18"],
"first_check": "backend_net Konnektivitaet? Disk-Space auf /mnt/user/appdata? pg_isready im Container?",
"notes": "Dumps per Dienst unter dumps/latest; raw DB nicht primaerer Restore-Weg; alter PG17-Pfad ist unter /mnt/user/appdata/_archive/pg18-immich-rollback-volumes-20260602/postgresql17 archiviert"
"notes": "Dumps per Dienst unter dumps/latest; raw DB nicht primaerer Restore-Weg; alter PG17-Pfad bleibt nur Rollback-Altstand"
},
"komodo-core": {
"description": "GitOps UI / API / Stack-Manager",
@@ -202,7 +202,7 @@
"dump_file": "immich.dump",
"data_paths": ["/mnt/user/appdata/immich_postgres_vectorchord"],
"first_check": "immich_default Netz? Disk-Space? pg_isready?",
"notes": "PG14 mit VectorChord/pgvector; nie ins frontend_net; immich_default Netz isoliert; alter immich_postgres-Pfad ist unter /mnt/user/appdata/_archive/pg18-immich-rollback-volumes-20260602/immich-postgres-pgvecto-rs archiviert"
"notes": "PG14 mit VectorChord/pgvector; nie ins frontend_net; immich_default Netz isoliert; alter immich_postgres-Pfad bleibt nur Rollback-Altstand"
},
"immich_redis": {
"description": "Immich Cache",
ops/hermes-agent/services.yaml
+2 -2
View File
@@ -138,7 +138,7 @@ services:
data_paths:
- /mnt/user/appdata/postgresql18
first_check: "backend_net Konnektivitaet? Disk-Space auf /mnt/user/appdata? pg_isready im Container?"
notes: "Dumps per Dienst unter dumps/latest; raw DB nicht primaerer Restore-Weg; alter PG17-Pfad ist unter /mnt/user/appdata/_archive/pg18-immich-rollback-volumes-20260602/postgresql17 archiviert"
notes: "Dumps per Dienst unter dumps/latest; raw DB nicht primaerer Restore-Weg; alter PG17-Pfad bleibt nur Rollback-Altstand"
komodo-core:
description: GitOps UI / API / Stack-Manager
@@ -263,7 +263,7 @@ services:
data_paths:
- /mnt/user/appdata/immich_postgres_vectorchord
first_check: "immich_default Netz? Disk-Space? pg_isready?"
notes: "PG14 mit VectorChord/pgvector; nie ins frontend_net; immich_default Netz isoliert; alter immich_postgres-Pfad ist unter /mnt/user/appdata/_archive/pg18-immich-rollback-volumes-20260602/immich-postgres-pgvecto-rs archiviert"
notes: "PG14 mit VectorChord/pgvector; nie ins frontend_net; immich_default Netz isoliert; alter immich_postgres-Pfad bleibt nur Rollback-Altstand"
immich_redis:
description: Immich Cache
ops/komodo/docker-compose.yml
+1 -6
View File
@@ -2,14 +2,9 @@ services:
# ──────────────────────────────────────────────────────────────────
# MongoDB – Datenbank fuer Komodo Core
# Netz: komodo_net (internal: true) – niemals frontend_net
# ACHTUNG: Dieser Stack wird NICHT aus diesem Repo deployed. Der komodo-Stack
# ist in Komodo inline (file_contents) verwaltet (Bootstrap-/Self-Stack).
# Diese Datei ist nur Doku/Spiegel; Aenderungen hier wirken NICHT zur Laufzeit.
# ops/komodo/** ist in renovate.json ignorePaths. Siehe docs/RENOVATE.md.
# Digest = aktuell real laufender Stand (kein Renovate-Auto-Update).
# ──────────────────────────────────────────────────────────────────
komodo-mongo:
image: mongo:8.0.23@sha256:44aa79ae28ff80b56fe58681b66cda9336706df408a5175a6c04988aa54610d3
image: mongo:8.0.23@sha256:f93b9015613e393b76fdf4fb71f3435ece6a3b46cc56c62c08875ad08442aa4c
container_name: komodo-mongo
labels:
komodo.skip:
ops/maintenance/check-dr-workstation-readiness.ps1
-95
View File
@@ -1,95 +0,0 @@
param(
[string]$ReportPath = "G:\Gitea_Clone\homelab-infra\docs\audit\dr-workstation-readiness-2026-06-06.md"
)
$ErrorActionPreference = "Stop"
function Invoke-Capture {
param([string]$Command)
$output = & cmd.exe /c $Command 2>&1
[pscustomobject]@{
Command = $Command
ExitCode = $LASTEXITCODE
Output = ($output | ForEach-Object { ([string]$_).Replace("`0", "") })
}
}
function Invoke-WslCapture {
param([string]$Bash)
Invoke-Capture -Command ('wsl -d Ubuntu -- bash -lc ' + '"' + ($Bash.Replace('"', '\"')) + '"')
}
$checks = [ordered]@{}
$checks["wsl_status"] = Invoke-Capture -Command "wsl --status"
$checks["wsl_list"] = Invoke-Capture -Command "wsl --list --verbose"
$checks["ubuntu_os"] = Invoke-WslCapture -Bash "lsb_release -a 2>/dev/null || cat /etc/os-release; uname -r"
$checks["tools"] = Invoke-WslCapture -Bash "command -v borg || true; borg --version 2>/dev/null || true; command -v ssh || true; ssh -V 2>&1 || true; command -v git || true; git --version 2>/dev/null || true"
$checks["sudo"] = Invoke-WslCapture -Bash "sudo -n true >/dev/null 2>&1 && echo sudo-noprompt-ok || echo sudo-password-needed"
$checks["wsl_ssh_files"] = Invoke-WslCapture -Bash "ls -la ~/.ssh 2>/dev/null || true; test -f ~/dr-smoke.sh && ls -la ~/dr-smoke.sh || true"
$checks["github_dr_key_smoke"] = Invoke-WslCapture -Bash "GIT_SSH_COMMAND='ssh -i ~/.ssh/dr-readonly -o BatchMode=yes -o IdentitiesOnly=yes -o ConnectTimeout=8' git ls-remote git@github.com:michaelkaleschke-spec/homelab-infra.git HEAD 2>&1 | sed -n '1,5p'"
$checks["hetzner_dr_key_smoke"] = Invoke-WslCapture -Bash "ssh -i ~/.ssh/dr-hetzner -o BatchMode=yes -o IdentitiesOnly=yes -o ConnectTimeout=8 -p 23 u565255@u565255.your-storagebox.de 'ls' 2>&1 | sed -n '1,10p'"
$borgInstalled = ($checks["tools"].Output -match "borg \d")
$githubOk = ($checks["github_dr_key_smoke"].Output -match "HEAD")
$hetznerOk = ($checks["hetzner_dr_key_smoke"].Output -match "hetzner_borg_appdata_critical")
$sudoNeedsPassword = ($checks["sudo"].Output -match "sudo-password-needed")
$drSmokeExists = ($checks["wsl_ssh_files"].Output -match "dr-smoke.sh")
$lines = @()
$lines += "# DR-Workstation Readiness - 2026-06-06"
$lines += ""
$lines += "Automatisch erzeugter lokaler Readiness-Check fuer den Operator-PC. Es wurden keine Secret-Werte, Passphrases oder Private-Key-Inhalte ausgegeben."
$lines += ""
$lines += "## Zusammenfassung"
$lines += ""
$lines += "| Check | Ergebnis |"
$lines += "|---|---|"
$lines += '| WSL2 Ubuntu | vorhanden (`Ubuntu 24.04`, WSL Version 2) |'
$lines += "| SSH/Git in WSL | vorhanden |"
$lines += "| GitHub-Read-Smoke mit DR-Key | " + ($(if ($githubOk) { "ok" } else { "nicht ok" })) + " |"
$lines += "| Borg Client | " + ($(if ($borgInstalled) { "installiert" } else { "fehlt" })) + " |"
$lines += "| Hetzner Storage Box mit DR-Key | " + ($(if ($hetznerOk) { "ok" } else { "nicht ok" })) + " |"
$lines += '| `~/dr-smoke.sh` | ' + ($(if ($drSmokeExists) { "vorhanden" } else { "fehlt" })) + ' |'
$lines += "| WSL sudo ohne Passwortprompt | " + ($(if ($sudoNeedsPassword) { "nein, Operator muss Passwort eingeben" } else { "ja" })) + " |"
$lines += ""
$lines += "## Bewertung"
$lines += ""
$lines += "- Der lokale WSL2-/Ubuntu-Unterbau ist vorhanden."
$lines += '- Die DR-Key-Arbeitskopien liegen in WSL unter `~/.ssh/dr-readonly` und `~/.ssh/dr-hetzner`.'
$lines += "- GitHub-Read-Smoke und Hetzner-SSH-Smoke sind erfolgreich."
$lines += '- `borgbackup` ist installiert.'
$lines += "- Der vollstaendige Bare-Metal-DR-Smoke wartet nur noch auf die interaktive Borg-Passphrase."
$lines += ""
$lines += "## Naechste Operator-Schritte"
$lines += ""
$lines += "In Ubuntu ausfuehren:"
$lines += ""
$lines += '```bash'
$lines += "bash ~/dr-smoke.sh"
$lines += '```'
$lines += ""
$lines += 'Borg fragt dabei interaktiv nach der Borg-Repo-Passphrase. Diese Passphrase wurde nicht auf `baerchen` gefunden und wird bewusst nicht dauerhaft gespeichert.'
$lines += ""
$lines += "## Rohchecks"
$lines += ""
foreach ($name in $checks.Keys) {
$check = $checks[$name]
$lines += "### $name"
$lines += ""
$lines += '- ExitCode: `' + $check.ExitCode + '`'
$lines += ""
$lines += '```text'
$lines += ($check.Output | ForEach-Object {
$_ -replace ([regex]::Escape($env:USERPROFILE)), '%USERPROFILE%'
})
$lines += '```'
$lines += ""
}
New-Item -ItemType Directory -Force -Path (Split-Path -Parent $ReportPath) | Out-Null
while ($lines.Count -gt 0 -and $lines[-1] -eq "") {
$lines = $lines[0..($lines.Count - 2)]
}
$lines -join "`r`n" | Set-Content -LiteralPath $ReportPath -Encoding UTF8
Write-Host "Report written: $ReportPath"
ops/maintenance/check-guest-iot-isolation.ps1
-127
View File
@@ -1,127 +0,0 @@
param(
[string]$HostLanIp = "192.168.178.58",
[string]$FritzBoxIp = "192.168.178.1",
[ValidateSet("LanPreflight", "Guest")]
[string]$Mode = "LanPreflight",
[string]$ReportPath = ""
)
$ErrorActionPreference = "Stop"
function Test-TcpPort {
param(
[string]$RemoteHost,
[int]$Port,
[int]$TimeoutMs = 1500
)
$client = [System.Net.Sockets.TcpClient]::new()
try {
$async = $client.BeginConnect($RemoteHost, $Port, $null, $null)
$ok = $async.AsyncWaitHandle.WaitOne($TimeoutMs, $false)
if (-not $ok) {
return $false
}
$client.EndConnect($async)
return $true
} catch {
return $false
} finally {
$client.Close()
}
}
function Add-Result {
param(
[System.Collections.Generic.List[object]]$Results,
[string]$Name,
[string]$Target,
[bool]$Reachable,
[string]$ExpectedGuest,
[string]$Risk
)
$Results.Add([pscustomobject]@{
Name = $Name
Target = $Target
Reachable = $Reachable
ExpectedFromGuest = $ExpectedGuest
RiskIfReachableFromGuest = $Risk
})
}
$adapters = Get-NetIPConfiguration |
Where-Object { $_.IPv4Address -and $_.NetAdapter.Status -eq "Up" } |
Select-Object InterfaceAlias,
@{Name="IPv4";Expression={$_.IPv4Address.IPAddress -join ", "}},
@{Name="Gateway";Expression={$_.IPv4DefaultGateway.NextHop -join ", "}},
@{Name="DnsServer";Expression={$_.DNSServer.ServerAddresses -join ", "}}
$results = [System.Collections.Generic.List[object]]::new()
Add-Result $results "Unraid HTTP/LAN" "${HostLanIp}:80" (Test-TcpPort $HostLanIp 80) "blocked" "Guest can reach LAN web entrypoint directly"
Add-Result $results "Unraid HTTPS/LAN" "${HostLanIp}:443" (Test-TcpPort $HostLanIp 443) "blocked" "Guest can reach LAN HTTPS entrypoint directly"
Add-Result $results "Gitea SSH/LAN" "${HostLanIp}:222" (Test-TcpPort $HostLanIp 222) "blocked" "Guest can reach Git SSH"
Add-Result $results "AdGuard Admin/LAN" "${HostLanIp}:8082" (Test-TcpPort $HostLanIp 8082) "blocked" "Guest can reach AdGuard admin UI"
Add-Result $results "InfluxDB LAN" "${HostLanIp}:8181" (Test-TcpPort $HostLanIp 8181) "blocked" "Guest can reach InfluxDB writer endpoint"
Add-Result $results "FRITZ!Box LAN UI" "${FritzBoxIp}:80" (Test-TcpPort $FritzBoxIp 80) "blocked-or-guest-gateway-only" "Guest can reach main router UI"
$risk = if ($Mode -eq "Guest") {
$results | Where-Object {
$_.ExpectedFromGuest -like "blocked*" -and $_.Reachable
}
} else {
$results | Where-Object {
$_.Name -in @("AdGuard Admin/LAN", "InfluxDB LAN") -and $_.Reachable
}
}
$timestamp = Get-Date -Format "yyyy-MM-dd HH:mm:ss"
$lines = [System.Collections.Generic.List[string]]::new()
$lines.Add("# Guest/IoT Isolation Check")
$lines.Add("")
$lines.Add("Timestamp: $timestamp")
$lines.Add("Mode: $Mode")
$lines.Add("Host LAN IP: $HostLanIp")
$lines.Add("FRITZ!Box IP: $FritzBoxIp")
$lines.Add("Risk count: $($risk.Count)")
$lines.Add("")
$lines.Add("## Active Network Adapters")
$lines.Add("")
$lines.Add("| Interface | IPv4 | Gateway | DNS |")
$lines.Add("|---|---|---|---|")
foreach ($adapter in $adapters) {
$lines.Add("| $($adapter.InterfaceAlias) | $($adapter.IPv4) | $($adapter.Gateway) | $($adapter.DnsServer) |")
}
$lines.Add("")
$lines.Add("## Port Tests")
$lines.Add("")
$lines.Add("| Name | Target | Reachable | Expected from guest Wi-Fi | Risk if reachable from guest |")
$lines.Add("|---|---|---:|---|---|")
foreach ($result in $results) {
$lines.Add("| $($result.Name) | $($result.Target) | $($result.Reachable) | $($result.ExpectedFromGuest) | $($result.RiskIfReachableFromGuest) |")
}
$lines.Add("")
$lines.Add("## Interpretation")
$lines.Add("")
$lines.Add("- `LanPreflight`: reachable `80/443/222` can be normal; `8082` and `8181` should still be blocked.")
$lines.Add("- `Guest`: all listed LAN targets should be blocked. Public domains may still work via the internet path.")
$lines.Add("- A non-zero risk count means the selected mode failed.")
$text = $lines -join [Environment]::NewLine
if ($ReportPath) {
$parent = Split-Path -Parent $ReportPath
if ($parent) {
New-Item -ItemType Directory -Force -Path $parent | Out-Null
}
Set-Content -Path $ReportPath -Value $text -Encoding UTF8
}
Write-Output $text
if ($risk.Count -gt 0) {
exit 2
}
exit 0
ops/maintenance/check-guest-iot-preflight.sh
-90
View File
@@ -1,90 +0,0 @@
#!/bin/bash
set -euo pipefail
HOST_LAN_IP="${HOST_LAN_IP:-192.168.178.58}"
TAILSCALE_IP="${TAILSCALE_IP:-100.80.98.33}"
FRITZBOX_TR064_URL="${FRITZBOX_TR064_URL:-http://192.168.178.1:49000/tr64desc.xml}"
REPORT_ROOT="${REPORT_ROOT:-/mnt/user/backups/restore-reports}"
STAMP="$(date +%F-%H%M%S)"
REPORT_FILE="$REPORT_ROOT/guest-iot-preflight-$STAMP.md"
mkdir -p "$REPORT_ROOT"
tcp_check() {
local host="$1"
local port="$2"
timeout 2 bash -c "cat < /dev/null > /dev/tcp/$host/$port" >/dev/null 2>&1
}
result_row() {
local name="$1"
local target="$2"
local expectation="$3"
local status="$4"
printf '| %s | `%s` | %s | %s |\n' "$name" "$target" "$status" "$expectation"
}
{
echo "# Guest/IoT Preflight"
echo
echo "Timestamp: $(date '+%F %T')"
echo "Scope: host-side read-only checks before enabling FRITZ!Box guest/IoT network"
echo
echo "## FRITZ!Box TR-064"
echo
if curl -fsS --max-time 5 "$FRITZBOX_TR064_URL" >/tmp/guest-iot-fritzbox-tr064.xml 2>/dev/null; then
model="$(grep -o '<friendlyName>[^<]*' /tmp/guest-iot-fritzbox-tr064.xml | head -n1 | sed 's/<friendlyName>//')"
echo "- TR-064 descriptor reachable: yes"
echo "- Model: ${model:-unknown}"
else
echo "- TR-064 descriptor reachable: no"
fi
rm -f /tmp/guest-iot-fritzbox-tr064.xml
echo
echo "## Host listeners"
echo
echo '```text'
ss -ltnp | sort -k4 | grep -E ':(53|80|443|222|8082|8181)[[:space:]]' || true
echo '```'
echo
echo "## Port reachability from host namespace"
echo
echo "| Check | Target | Status | Expectation |"
echo "|---|---|---|---|"
for port in 80 443 222 53; do
if tcp_check "$HOST_LAN_IP" "$port"; then
result_row "LAN service" "$HOST_LAN_IP:$port" "may be reachable from normal LAN; must be blocked from guest Wi-Fi" "reachable"
else
result_row "LAN service" "$HOST_LAN_IP:$port" "not reachable from host namespace or UDP-only" "blocked"
fi
done
if tcp_check "$HOST_LAN_IP" 8082; then
result_row "AdGuard Admin via LAN IP" "$HOST_LAN_IP:8082" "should be blocked" "reachable"
else
result_row "AdGuard Admin via LAN IP" "$HOST_LAN_IP:8082" "should be blocked" "blocked"
fi
if tcp_check "$TAILSCALE_IP" 8082; then
result_row "AdGuard Admin via Tailscale IP" "$TAILSCALE_IP:8082" "operator path should work" "reachable"
else
result_row "AdGuard Admin via Tailscale IP" "$TAILSCALE_IP:8082" "operator path should work" "blocked"
fi
if tcp_check "$HOST_LAN_IP" 8181; then
result_row "InfluxDB via LAN IP" "$HOST_LAN_IP:8181" "should be blocked unless HA LAN writer is reintroduced" "reachable"
else
result_row "InfluxDB via LAN IP" "$HOST_LAN_IP:8181" "should be blocked unless HA LAN writer is reintroduced" "blocked"
fi
echo
echo "## Next operator step"
echo
echo "Enable FRITZ!Box guest Wi-Fi only after confirming LAN isolation is active. Then connect a phone/laptop to guest Wi-Fi and run:"
echo
echo '```powershell'
echo 'G:\Gitea_Clone\homelab-infra\ops\maintenance\check-guest-iot-isolation.ps1 -Mode Guest'
echo '```'
} | tee "$REPORT_FILE"
echo "Guest/IoT preflight report: $REPORT_FILE"
ops/maintenance/check-unraid-flash-backup.sh
-125
View File
@@ -1,125 +0,0 @@
#!/usr/bin/env bash
set -euo pipefail
# check-unraid-flash-backup.sh
#
# Read-only Validierung des Unraid-Flash-Backup-Artefakts
# (`unraid-flash-config.tar.gz`) ohne produktive Extraktion.
#
# Prueft:
# 1. Artefakt, Checksumme und Manifest sind vorhanden
# 2. Artefakt ist frisch genug (Standard: <= 36 h)
# 3. `sha256sum -c` ist OK
# 4. Archiv enthaelt die array-/identitaetsdefinierenden Kern-Configs
#
# Es wird NICHTS extrahiert. `tar -tzf` listet nur Eintragsnamen.
# Das Artefakt enthaelt Host-Konfiguration inkl. SSH-Host-Keys, passwd/shadow
# und Tailscale-State und ist wie Secret-Material zu behandeln. Dieses Skript
# gibt bewusst nur Datei-/Eintragsnamen aus, niemals Inhalte.
#
# Exit-Codes:
# 0 alles OK
# 1 Validierung fehlgeschlagen (fehlende Datei, Checksumme falsch,
# fehlende Kern-Config)
# 2 Artefakt aelter als erlaubt (Frische-Warnung)
DUMPS_DIR="${DUMPS_DIR:-/mnt/user/backups/borg/dumps/latest}"
ARTIFACT="${ARTIFACT:-unraid-flash-config.tar.gz}"
MAX_AGE_HOURS="${MAX_AGE_HOURS:-36}"
# Kern-Configs, die ein brauchbares Flash-Restore mindestens enthalten muss.
CRITICAL_FILES=(
"config/super.dat" # Array-/Disk-Zuordnung
"config/disk.cfg" # Array-Einstellungen
"config/ident.cfg" # Hostname/Identitaet
"config/share.cfg" # Share-Grundeinstellungen
"config/network.cfg" # Netzwerk
"config/docker.cfg" # Docker-Settings
"config/go" # Boot-Script
"config/domain.cfg" # VM/Domain-Settings
)
fail=0
artifact_path="$DUMPS_DIR/$ARTIFACT"
sha_path="$artifact_path.sha256"
manifest_path="$DUMPS_DIR/unraid-flash-config.manifest.txt"
echo "## Unraid Flash Backup Validierung"
echo "Verzeichnis: $DUMPS_DIR"
echo
# 1. Existenz
for f in "$artifact_path" "$sha_path" "$manifest_path"; do
if [ -f "$f" ]; then
echo "OK vorhanden: $(basename "$f")"
else
echo "FEHLER fehlt: $(basename "$f")"
fail=1
fi
done
echo
# Wenn das Artefakt fehlt, hat alles Weitere keinen Sinn.
if [ ! -f "$artifact_path" ]; then
echo "Abbruch: Artefakt nicht vorhanden."
exit 1
fi
# 2. Frische
now_epoch="$(date +%s)"
file_epoch="$(stat -c %Y "$artifact_path")"
age_hours=$(( (now_epoch - file_epoch) / 3600 ))
echo "Alter des Artefakts: ${age_hours} h (Grenze: ${MAX_AGE_HOURS} h)"
stale=0
if [ "$age_hours" -gt "$MAX_AGE_HOURS" ]; then
echo "WARNUNG Artefakt ist aelter als ${MAX_AGE_HOURS} h."
stale=1
else
echo "OK Artefakt ist frisch."
fi
echo
# 3. Checksumme
if [ -f "$sha_path" ]; then
if ( cd "$DUMPS_DIR" && sha256sum -c "$(basename "$sha_path")" ) ; then
echo "OK sha256 stimmt."
else
echo "FEHLER sha256-Pruefung fehlgeschlagen."
fail=1
fi
echo
fi
# 4. Kern-Configs (nur Namen, keine Extraktion)
echo "## Kern-Configs im Archiv"
listing="$(tar -tzf "$artifact_path")"
entry_count="$(printf '%s\n' "$listing" | wc -l | tr -d ' ')"
echo "Eintraege im Archiv: $entry_count"
for cf in "${CRITICAL_FILES[@]}"; do
if printf '%s\n' "$listing" | grep -qxF "$cf"; then
echo "OK $cf"
else
echo "FEHLER $cf fehlt im Archiv"
fail=1
fi
done
echo
# Manifest-Kopf zur Orientierung (enthaelt keine Secret-Werte)
if [ -f "$manifest_path" ]; then
echo "## Manifest"
cat "$manifest_path"
echo
fi
if [ "$fail" -ne 0 ]; then
echo "ERGEBNIS: FEHLGESCHLAGEN"
exit 1
fi
if [ "$stale" -ne 0 ]; then
echo "ERGEBNIS: OK, aber Frische-Warnung"
exit 2
fi
echo "ERGEBNIS: OK"
exit 0
ops/maintenance/dr-workstation-smoke.sh
-41
View File
@@ -1,41 +0,0 @@
#!/bin/bash
# DR-Workstation Quartals-Smoke
#
# Prueft Git-Read, Hetzner-SSH und Borg-Repo-Erreichbarkeit vom Operator-PC.
# Speichert keine Passphrase. Borg fragt interaktiv nach der Repo-Passphrase.
set -euo pipefail
GITHUB_KEY="${GITHUB_KEY:-$HOME/.ssh/dr-readonly}"
HETZNER_KEY="${HETZNER_KEY:-$HOME/.ssh/dr-hetzner}"
GITHUB_REPO="${GITHUB_REPO:-git@github.com:michaelkaleschke-spec/homelab-infra.git}"
BORG_REPO="${BORG_REPO:-ssh://u565255@u565255.your-storagebox.de/./hetzner_borg_appdata_critical}"
echo "=== Tooling ==="
command -v ssh
command -v git
command -v borg
borg --version
echo
echo "=== Key files ==="
test -r "$GITHUB_KEY" || { echo "Missing GitHub key: $GITHUB_KEY" >&2; exit 1; }
test -r "$HETZNER_KEY" || { echo "Missing Hetzner key: $HETZNER_KEY" >&2; exit 1; }
ls -l "$GITHUB_KEY" "$HETZNER_KEY"
echo
echo "=== GitHub Deploy-Key ==="
GIT_SSH_COMMAND="ssh -i $GITHUB_KEY -o IdentitiesOnly=yes -o BatchMode=yes" \
git ls-remote "$GITHUB_REPO" HEAD
echo
echo "=== Hetzner SSH-Login ==="
ssh -i "$HETZNER_KEY" -o IdentitiesOnly=yes -o BatchMode=yes -p 23 \
u565255@u565255.your-storagebox.de "ls" | head -5
echo
echo "=== Borg-Repo ==="
export BORG_RSH="ssh -i $HETZNER_KEY -o IdentitiesOnly=yes -p 23"
borg info "$BORG_REPO" | head -12
echo
echo "DR-Smoke OK ($(date '+%F %T'))"
ops/maintenance/release-alt-volumes.sh
+15 -38
View File
@@ -3,7 +3,6 @@ set -euo pipefail
MODE="dry-run"
CUTOFF_DATE="2026-06-02"
ARCHIVE_ROOT="/mnt/user/appdata/_archive/pg18-immich-rollback-volumes-20260602"
if [[ "${1:-}" == "--execute" ]]; then
MODE="execute"
@@ -24,10 +23,10 @@ if [[ "$MODE" == "execute" && "$today" < "$CUTOFF_DATE" ]]; then
fi
declare -a CANDIDATES=(
"/mnt/user/appdata/postgresql17|/mnt/user/appdata/postgresql18|postgresql17|shared PostgreSQL 17 rollback"
"/mnt/user/appdata/mealie/postgres|/mnt/user/appdata/mealie/postgres18|mealie-postgres17|Mealie PostgreSQL 17 rollback"
"/mnt/user/appdata/nextcloud/postgres|/mnt/user/appdata/nextcloud/postgres18|nextcloud-postgres17|Nextcloud PostgreSQL 17 rollback"
"/mnt/user/appdata/immich_postgres|/mnt/user/appdata/immich_postgres_vectorchord|immich-postgres-pgvecto-rs|Immich pgvecto.rs rollback"
"/mnt/user/appdata/postgresql17|/mnt/user/appdata/postgresql18|shared PostgreSQL 17 rollback"
"/mnt/user/appdata/mealie/postgres|/mnt/user/appdata/mealie/postgres18|Mealie PostgreSQL 17 rollback"
"/mnt/user/appdata/nextcloud/postgres|/mnt/user/appdata/nextcloud/postgres18|Nextcloud PostgreSQL 17 rollback"
"/mnt/user/appdata/immich_postgres|/mnt/user/appdata/immich_postgres_vectorchord|Immich pgvecto.rs rollback"
)
require_container_healthy() {
@@ -49,10 +48,9 @@ require_container_healthy() {
fi
}
echo "Alt-volume archive check"
echo "Alt-volume release check"
echo "Mode: $MODE"
echo "Date: $today"
echo "Archive: $ARCHIVE_ROOT"
echo
require_container_healthy postgresql17
@@ -70,58 +68,37 @@ if [[ -x /mnt/user/services/homelab-infra/ops/restore-tests/run-restore-checks.s
/mnt/user/services/homelab-infra/ops/restore-tests/run-restore-checks.sh freshness
fi
mapfile -t active_mounts < <(docker inspect $(docker ps -aq) --format '{{range .Mounts}}{{println .Source}}{{end}}' 2>/dev/null || true)
if [[ "$MODE" == "execute" ]]; then
mkdir -p "$ARCHIVE_ROOT"
fi
mapfile -t active_mounts < <(docker inspect $(docker ps -q) --format '{{range .Mounts}}{{println .Source}}{{end}}' 2>/dev/null || true)
for entry in "${CANDIDATES[@]}"; do
IFS='|' read -r old_path active_path archive_name label <<< "$entry"
archive_path="$ARCHIVE_ROOT/$archive_name"
IFS='|' read -r old_path active_path label <<< "$entry"
if [[ ! -d "$active_path" ]]; then
echo "Missing active path for $label: $active_path" >&2
exit 1
fi
if printf '%s\n' "${active_mounts[@]}" | grep -Fxq "$old_path"; then
echo "Refusing: old path is still mounted by a container: $old_path" >&2
exit 1
fi
if [[ -d "$old_path" && -d "$archive_path" ]]; then
echo "Refusing: both old path and archive path exist for $label." >&2
echo "Old: $old_path" >&2
echo "Archive: $archive_path" >&2
exit 1
fi
if [[ -d "$archive_path" ]]; then
size="$(du -sh "$archive_path" 2>/dev/null | awk '{print $1}')"
echo "Archived: $archive_path ($label, $size)"
echo
if [[ ! -d "$old_path" ]]; then
echo "Already absent: $old_path ($label)"
continue
fi
if [[ ! -d "$old_path" ]]; then
echo "Absent and not archived: $old_path ($label)" >&2
if printf '%s\n' "${active_mounts[@]}" | grep -Fxq "$old_path"; then
echo "Refusing: old path is still mounted by a running container: $old_path" >&2
exit 1
fi
size="$(du -sh "$old_path" 2>/dev/null | awk '{print $1}')"
echo "Candidate: $old_path ($label, $size)"
echo "Active: $active_path"
echo "Archive: $archive_path"
if [[ "$MODE" == "execute" ]]; then
mv "$old_path" "$archive_path"
printf '%s MOVE %s -> %s size=%s\n' "$(date -Is)" "$old_path" "$archive_path" "$size" >> "$ARCHIVE_ROOT/MANIFEST.txt"
echo "Moved: $archive_path"
rm -rf --one-file-system "$old_path"
echo "Removed: $old_path"
else
echo "Dry-run: would move $old_path to $archive_path"
echo "Dry-run: would remove $old_path"
fi
echo
done
echo "Alt-volume archive check completed."
echo "Alt-volume release check completed."
ops/restore-tests/README.md
+3 -22
View File
@@ -20,7 +20,6 @@ Ziel:
## Geplante Struktur
- `schedule.md`: Intervalle und Verantwortlichkeiten
- `common.sh`: gemeinsame Helfer fuer Borg-Lookup, Borg-Extract und Compose-Cleanup; prueft vor Borg-Operationen auch `borg-ui:/data/borg.db` und `borg-ui:/local/secrets/borg_repo_passphrase.txt`
- `vaultwarden-restore-test.ps1`: erster Mini-Restore-Ablauf
- `vaultwarden-restore-test.sh`: hosttauglicher Vaultwarden-Restore-Job
- `vaultwarden-plan.md`: konkreter Vaultwarden-Testplan
@@ -38,21 +37,9 @@ Ziel:
- `immich-plan.md`: konkreter Immich-Testplan
- `immich-runbook.md`: Operator-Runbook fuer den ersten Immich-Lauf
- `immich-compose.test.yml`: isolierte Testinstanz fuer Immich inkl. VectorChord/pgvector-Test-Postgres und Test-Redis
- `authelia-restore-test.sh`: Authelia-Restore-Job (Config-Smoke; Erstlauf 2026-06-03 erfolgreich)
- `authelia-compose.test.yml`: isolierte Testinstanz fuer Authelia inkl. Test-Postgres, Filesystem-Notifier (kein echter SMTP-Versand)
- `authelia-plan.md`: konkreter Authelia-Testplan
- `authelia-runbook.md`: Operator-Runbook fuer den ersten Authelia-Lauf
- `adguard-restore-test.sh`: AdGuard-Home-Restore-Job (Config + isolierter Container + HTTP/DNS-Smoke; Erstlauf 2026-06-06 erfolgreich)
- `adguard-compose.test.yml`: isolierte AdGuard-Testinstanz auf localhost-Ports `13001` und `15353`
- `redis-restore-test.sh`: Redis-8-Restore-Job (Pre-Cutover-Artefakt + isolierter Container + PING/INFO/DBSIZE; Erstlauf 2026-06-06 erfolgreich)
- `redis-compose.test.yml`: isolierte Redis-8-Testinstanz auf localhost-Port `16379`
- `nextcloud-restore-test.sh`: Nextcloud-Restore-Job (Scaffold; **blockiert** durch Unraid shfs-chmod-Inkompatibilitaet - siehe unten)
- `nextcloud-compose.test.yml`: isolierte Testinstanz fuer Nextcloud inkl. Test-Postgres und Test-Redis
- `check-restore-freshness.ps1`: woechentlicher Frische-Check fuer Dumps und Reports
- `run-restore-checks.ps1`: einfacher Dispatcher fuer Restore-Jobs
- `check-restore-freshness.sh`: hosttauglicher Frische-Check
- `negative-freshness-alert-test.sh`: sicherer Negativtest fuer den Frische-Alarmweg; nutzt synthetische leere Testpfade unter `/mnt/user/backups/restore-lab/freshness-negative`, veraendert keine produktiven Dumps und sendet bei erkanntem Fehler einen Test-Alert nach `homelab-alerts`
- `run-restore-checks.sh`: hosttauglicher Dispatcher
- `common.sh`: gemeinsame Host-Helferfunktionen
- `automation-plan.md`: Host-Job- und Automatisierungsmodell
@@ -95,15 +82,9 @@ Aktuell ist das erste validierte Muster vorhanden.
- echter Gitea-Restore am 2026-05-07 erfolgreich verifiziert
- echter Paperless-Restore am 2026-05-07 erfolgreich verifiziert
- Immich-Restore-Test am 2026-05-27 erfolgreich verifiziert; Test-Postgres wurde nach der VectorChord-Migration am 2026-05-31 auf das produktive Immich-Postgres-Image umgestellt
- Authelia-Restore-Smoke am 2026-06-03 erfolgreich verifiziert; bewusst ohne produktiven Dump-Restore wegen Storage-Encryption-Key-Kopplung
- AdGuard-Home-Restore-Smoke am 2026-06-06 erfolgreich verifiziert; Borg-Config-Restore, HTTP `/control/status` 401, DNS-Smoke ok, 7 Filterlisten-Eintraege, Report `/mnt/user/backups/restore-reports/adguard-2026-06-06.md`
- Redis-8-Restore-Smoke am 2026-06-06 erfolgreich verifiziert; Pre-Cutover-Artefakt, Redis 8.8, PING ok, AOF aktiv, DBSIZE 1, Report `/mnt/user/backups/restore-reports/redis-2026-06-06.md`
- Bash-Dispatcher und Bash-Restore-Jobs am 2026-05-07 erfolgreich hostseitig verifiziert
- Restore-Lab und Report-Pfade auf dem Host angelegt
- `ntfy`-Wrapper ist fuer Host-Jobs verfuegbar
- Frische-Negativtest ist als sicherer Host-Job verfuegbar und am 2026-06-06 auf Unraid validiert: `ops/restore-tests/run-restore-checks.sh freshness-negative`. Ergebnis: synthetischer leerer Dump-Pfad erzeugte 10 Criticals, Test-Alert ging nach `homelab-alerts`, produktive Dump-Pfade blieben unangetastet. Report: `/mnt/user/backups/restore-reports/freshness-negative-2026-06-06-130320.md`.
- Nextcloud-Restore-Test: Scaffold existiert, aber **blockiert**. Nextcloud 33 fuehrt zur Laufzeit `chmod()` auf Dateien unter `/var/www/html` aus (`OC_Util.php:486`). Auf Unraids FUSE/shfs User-Shares ist `chmod` strukturell nicht moeglich, was zu permanenter 503 fuehrt. Loesungsoptionen: (a) Restore-Lab auf ein Cache-Drive statt User Share legen, (b) Docker-Volumes statt Bind-Mounts verwenden, (c) tmpfs-Mount fuer html/ + `rsync` der Borg-Daten hinein. Bis dahin ist Nextcloud als Backlog-Item dokumentiert.
- Komodo-Mongo-Daten-Restore am 2026-06-03 erfolgreich: 86904 Dokumente (inkl. 32 Stacks), Report `/mnt/user/backups/restore-reports/komodo-mongo-restore-2026-06-03.md`
- naechste grosse Kandidaten sind Mailarchiver und Mealie; Nextcloud bleibt blockiert (shfs-chmod)
- V1-Ablauf weiter ohne `ntfy`, mit Bereinigung nach Erfolg
- naechster grosser Kandidat ist ein erneuter Immich-Lauf nach VectorChord-Migration mit Zeitmessung; danach in die Rotation aufnehmen
Vor dem ersten echten Testlauf je neuem Dienst muessen Zielpfade, Quellpfade und Bereinigungsschritte bewusst freigegeben werden.
Vor dem ersten echten Testlauf muessen Zielpfade, Quellpfade und Bereinigungsschritte bewusst freigegeben werden.
ops/restore-tests/adguard-compose.test.yml
-14
View File
@@ -1,14 +0,0 @@
services:
restoretest-adguard:
image: adguard/adguardhome:v0.107.76@sha256:7157eb1dc3b26c7af1d6898759a7b3f7d0fa09891fbd2d3caa6abc1057a9179b
container_name: restoretest-adguard
restart: "no"
ports:
- "127.0.0.1:15353:53/tcp"
- "127.0.0.1:15353:53/udp"
- "127.0.0.1:13001:80/tcp"
volumes:
- /mnt/user/backups/restore-lab/adguard/work:/opt/adguardhome/work
- /mnt/user/backups/restore-lab/adguard/conf:/opt/adguardhome/conf
security_opt:
- no-new-privileges:true
ops/restore-tests/adguard-restore-test.sh
-181
View File
@@ -1,181 +0,0 @@
#!/bin/bash
set -euo pipefail
# AdGuard Home Restore Smoke Test
#
# Scope:
# - Borg-Extract von /local/appdata/adguard/conf
# - YAML-/Strukturcheck fuer AdGuardHome.yaml
# - Start einer isolierten Testinstanz auf localhost-Ports
# - HTTP-Smoke gegen Admin-UI/API
# - DNS-Smoke gegen localhost:15353, falls ein passender Resolver-Client vorhanden ist
SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
. "$SCRIPT_DIR/common.sh"
WHATIF=0
KEEP_DATA=0
for arg in "$@"; do
case "$arg" in
--what-if) WHATIF=1 ;;
--keep-data) KEEP_DATA=1 ;;
*) echo "Unknown argument: $arg" >&2; exit 1 ;;
esac
done
RESTORE_ROOT="/mnt/user/backups/restore-lab/adguard"
REPORT_ROOT="/mnt/user/backups/restore-reports"
EXTRACT_DIR="$BORG_RESTORE_HOST_ROOT/adguard-extract"
COMPOSE_FILE="$SCRIPT_DIR/adguard-compose.test.yml"
REPORT_FILE="$REPORT_ROOT/adguard-$(date +%F).md"
TEST_HTTP="http://127.0.0.1:13001"
TEST_DNS_PORT="15353"
if [ "$WHATIF" -eq 1 ]; then
cat <<EOF
AdGuard Home restore test
Mode: WhatIf
RestoreRoot: $RESTORE_ROOT
Borg source: local/appdata/adguard/conf
Test HTTP endpoint: $TEST_HTTP
Test DNS endpoint: 127.0.0.1:$TEST_DNS_PORT
Scope: Config-Restore + isolated AdGuard boot + HTTP/DNS smoke
EOF
exit 0
fi
require_cmd docker
require_cmd curl
require_path "$BORG_PASSPHRASE_FILE_DEFAULT"
require_path "$COMPOSE_FILE"
RESTORE_SUCCESS=0
cleanup() {
cleanup_compose "$COMPOSE_FILE"
if [ "$RESTORE_SUCCESS" -ne 1 ]; then
preserve_on_failure "adguard" "$RESTORE_ROOT"
rm -rf "$EXTRACT_DIR"
return
fi
if [ "$KEEP_DATA" -ne 1 ]; then
rm -rf "$RESTORE_ROOT"
fi
rm -rf "$EXTRACT_DIR"
}
trap cleanup EXIT
rm -rf "$EXTRACT_DIR" "$RESTORE_ROOT"
mkdir -p "$RESTORE_ROOT/conf" "$RESTORE_ROOT/work"
archive="$(latest_archive_name)"
repo="$(borg_repo_url)"
if [ -z "$archive" ] || [ -z "$repo" ]; then
echo "Could not resolve Borg repo/archive from borg-ui database" >&2
exit 1
fi
borg_extract "/restore/adguard-extract" "local/appdata/adguard/conf"
if [ ! -d "$EXTRACT_DIR/local/appdata/adguard/conf" ]; then
echo "AdGuard conf path missing in Borg archive" >&2
exit 1
fi
cp -a "$EXTRACT_DIR/local/appdata/adguard/conf/." "$RESTORE_ROOT/conf/"
chmod -R a+rX "$RESTORE_ROOT/conf"
chmod -R a+rwX "$RESTORE_ROOT/work"
config_file="$RESTORE_ROOT/conf/AdGuardHome.yaml"
if [ ! -s "$config_file" ]; then
echo "Missing restored AdGuardHome.yaml" >&2
exit 1
fi
if command -v ruby >/dev/null 2>&1; then
ruby -e 'require "yaml"; YAML.load_file(ARGV.fetch(0))' "$config_file"
yaml_check="ruby-yaml-ok"
else
grep -q '^dns:' "$config_file"
grep -q '^http:' "$config_file"
yaml_check="basic-structure-ok"
fi
filter_count="$(grep -c '^[[:space:]]*-[[:space:]]*enabled:' "$config_file" 2>/dev/null || true)"
docker compose -f "$COMPOSE_FILE" up -d restoretest-adguard >/dev/null
http_status=""
for _ in $(seq 1 60); do
http_status="$(curl -s -o /tmp/adguard-body.html -w '%{http_code}' \
"$TEST_HTTP/control/status" || true)"
if [ "$http_status" = "200" ] || [ "$http_status" = "401" ] || [ "$http_status" = "403" ]; then
break
fi
sleep 2
done
if [ "$http_status" != "200" ] && [ "$http_status" != "401" ] && [ "$http_status" != "403" ]; then
echo "AdGuard HTTP smoke failed: status=$http_status" >&2
docker logs --tail 80 restoretest-adguard >&2 || true
exit 1
fi
dns_status="not-run"
dns_detail="no dig/drill command available"
if command -v dig >/dev/null 2>&1; then
if dig @127.0.0.1 -p "$TEST_DNS_PORT" git.kaleschke.info A +time=3 +tries=1 >/tmp/adguard-dig.out 2>&1; then
dns_status="ok"
dns_detail="$(grep -E '^[[:alnum:].-]+[[:space:]]+[0-9]+[[:space:]]+IN[[:space:]]+A[[:space:]]+' /tmp/adguard-dig.out | head -1 || true)"
else
dns_status="failed"
dns_detail="$(tail -20 /tmp/adguard-dig.out | tr '\n' ' ')"
fi
elif command -v drill >/dev/null 2>&1; then
if drill -p "$TEST_DNS_PORT" git.kaleschke.info @127.0.0.1 >/tmp/adguard-drill.out 2>&1; then
dns_status="ok"
dns_detail="$(grep -E '^[[:alnum:].-]+\\.[[:space:]]+[0-9]+[[:space:]]+IN[[:space:]]+A[[:space:]]+' /tmp/adguard-drill.out | head -1 || true)"
else
dns_status="failed"
dns_detail="$(tail -20 /tmp/adguard-drill.out | tr '\n' ' ')"
fi
fi
if [ "$dns_status" = "failed" ]; then
echo "AdGuard DNS smoke failed: $dns_detail" >&2
docker logs --tail 80 restoretest-adguard >&2 || true
exit 1
fi
write_report "$REPORT_FILE" <<EOF
# AdGuard Home Restore Test Report - $(date +%F)
- Service: \`adguard\`
- Source repo: \`$repo\`
- Archive: \`$archive\`
- Restore root: \`$RESTORE_ROOT\`
- Test container: \`restoretest-adguard\`
- Test HTTP endpoint: \`$TEST_HTTP/control/status\`
- Test DNS endpoint: \`127.0.0.1:$TEST_DNS_PORT\`
- Result: \`SUCCESS\`
## Checks
- Borg extract of conf: \`ok\`
- Restored config file: \`AdGuardHome.yaml\`
- Config check: \`$yaml_check\`
- Filter-list-like entries counted: \`$filter_count\`
- HTTP status from /control/status: \`$http_status\`
- DNS smoke: \`$dns_status\`
- DNS detail: \`$dns_detail\`
## Notes
- Productive AdGuard DNS port 53 and admin port 8082 were NOT used.
- Test ports were bound to localhost only: \`127.0.0.1:15353\` and \`127.0.0.1:13001\`.
- Login credentials are part of the restored AdGuardHome.yaml and were not printed.
- Test data was cleaned after success: \`$([ "$KEEP_DATA" -eq 1 ] && echo no || echo yes)\`
EOF
RESTORE_SUCCESS=1
echo "AdGuard restore test ok -> $REPORT_FILE"
ops/restore-tests/authelia-compose.test.yml
-53
View File
@@ -1,53 +0,0 @@
services:
restoretest-authelia-postgres:
# Gleiche Major-Version wie shared PostgreSQL 18 in Produktion.
image: postgres:18.4@sha256:8ff36f3c66371cba71d20ceedccfc3de9669a68737607888c4ef0af93abe8e39
container_name: restoretest-authelia-postgres
restart: "no"
environment:
TZ: Europe/Berlin
POSTGRES_USER: authelia
POSTGRES_DB: authelia
POSTGRES_PASSWORD: restoretest-authelia-db
PGDATA: /var/lib/postgresql/18/docker
volumes:
- /mnt/user/backups/restore-lab/authelia/postgres:/var/lib/postgresql
healthcheck:
test: ["CMD-SHELL", "pg_isready -U authelia -d authelia"]
interval: 10s
timeout: 5s
retries: 10
security_opt:
- no-new-privileges:true
restoretest-authelia:
# Gleicher Image-Digest wie security/authelia/docker-compose.yml in Produktion.
image: authelia/authelia:4.39.20@sha256:1b363e9279e742397966333f364e0876ae02bf5c876de73e83af6d48c57ff51b
container_name: restoretest-authelia
restart: "no"
depends_on:
restoretest-authelia-postgres:
condition: service_healthy
command:
- authelia
- --config=/config/configuration.yml
environment:
TZ: Europe/Berlin
# Wegwerf-Secrets nur fuer den isolierten Smoke. Niemals produktive
# Authelia-Secrets in diesem Compose verwenden. Die produktiven
# authelia_*_FILE-Mounts werden bewusst NICHT eingebunden.
AUTHELIA_SESSION_SECRET: restoretest-authelia-session-secret-placeholder-32
AUTHELIA_STORAGE_ENCRYPTION_KEY: restoretest-authelia-storage-enc-key-placeholder-32
AUTHELIA_STORAGE_POSTGRES_PASSWORD: restoretest-authelia-db
# server.address wird in der vom Skript erzeugten configuration.yml
# gesetzt (tcp://0.0.0.0:9091). Eine zusaetzliche ENV waere
# redundant - und in Authelia 4.39 nicht als Doppel-Underscore
# akzeptiert (war Ursache des "configuration environment variable
# not expected"-Warnings im Lauf 2026-06-03).
volumes:
- /mnt/user/backups/restore-lab/authelia/test-config:/config
ports:
# nur 127.0.0.1, keine Public-Route, keine Traefik-Labels
- "127.0.0.1:19091:9091"
security_opt:
- no-new-privileges:true
ops/restore-tests/authelia-plan.md
-89
View File
@@ -1,89 +0,0 @@
# Authelia Restore Test Plan
## Ziel
Nachweisen, dass die Authelia-Konfiguration aus dem produktiven Borg-Archiv in einer isolierten Testumgebung wieder lauffaehig ist und der HTTP-Health-Endpunkt antwortet, ohne dass dabei produktive Secrets, produktives Postgres oder produktiver SMTP-Versand beruehrt werden.
Bewusst **nicht** Teil dieses Tests:
- Restore mit produktiven Authelia-Secrets. Der Test nutzt ausschliesslich Wegwerf-Werte fuer `AUTHELIA_SESSION_SECRET`, `AUTHELIA_STORAGE_ENCRYPTION_KEY` und `AUTHELIA_STORAGE_POSTGRES_PASSWORD`. SMTP- und Legacy-JWT-Env-Werte werden bewusst nicht gesetzt, damit Authelia keinen `notifier.smtp`-Block oder deprecated `jwt_secret` aus Env erzeugt.
- SMTP-Realanruf an GMX. Die minimale Test-Konfiguration setzt nur den Filesystem-Notifier.
- Forward-Auth gegen Traefik. Test laeuft nur auf `127.0.0.1:19091`, keine Traefik-Route.
- WebAuthn-/Duo-/OIDC-Identity-Provider-Endpunkte. Smoke prueft `/api/health`.
- **pg_restore des produktiven `postgresql17-authelia.dump`**. Authelia verschluesselt Storage-Werte mit `AUTHELIA_STORAGE_ENCRYPTION_KEY`. Ein Restore mit produktiven Daten in eine Test-Instanz mit Wegwerf-Key schlaegt im Startup-Check **by design** fehl ("the configured encryption key does not appear to be valid for this database"). Frische des produktiven Dumps wird ueber `check-restore-freshness.sh` ueberwacht; Daten-Decrypt-Drill ist eine separate DR-Aufgabe und braucht eine eigene Sicherheits-Choreographie mit kontrollierter Schluessel-Verwendung. Beobachtet im Erstlauf 2026-06-03 (Commit-Reihe `cacf77b..8d71dfb`); seit dem 2026-06-03-Folgecommit ist der Dump-Restore explizit aus dem Smoke entfernt.
## Quelle
- Backup-Quelle: produktives Borg-Archiv (`hetzner_borg_appdata_critical`)
- fachlich relevante Pfade im Archiv:
- `local/appdata/authelia/config` (verpflichtend)
- `local/borg-dumps/latest/postgresql17-authelia.dump` (existiert ggf. im Archiv; wird vom Smoke bewusst NICHT eingespielt, siehe oben)
- produktive Secrets unter `/mnt/user/appdata/secrets/authelia_*.txt` werden **nicht** gemountet
## Test-Ziel
- Restore-Lab: `/mnt/user/backups/restore-lab/authelia`
- Testdatenpfade:
- `/mnt/user/backups/restore-lab/authelia/config` (restaurierte Originalkonfiguration + `configuration.yml.original`)
- `/mnt/user/backups/restore-lab/authelia/test-config` (Runtime-Mount mit minimaler Test-`configuration.yml`)
- `/mnt/user/backups/restore-lab/authelia/postgres` (Test-Postgres-Datadir)
- `/mnt/user/backups/restore-lab/authelia/dumps/latest/postgresql17-authelia.dump` (falls extrahiert)
- `/mnt/user/backups/restore-lab/authelia/test-config/notifier/notifications.txt` (Filesystem-Notifier-Ausgabe)
- Testcontainer:
- `restoretest-authelia` (Image-Pin wie Produktion)
- `restoretest-authelia-postgres` (postgres:18.4, gleiche Major wie shared Postgres)
- Testport: `127.0.0.1:19091:9091`
- Report-Ziel: `/mnt/user/backups/restore-reports/authelia-YYYY-MM-DD.md`
## Schutzregeln
- produktive Pfade `/mnt/user/appdata/authelia/*` werden **nicht** beschrieben
- produktive Secret-Dateien `/mnt/user/appdata/secrets/authelia_*.txt` werden **nicht** gemountet
- produktive shared PostgreSQL 18 wird **nicht** angesprochen (`test-config/configuration.yml` definiert nur Test-Postgres)
- echter SMTP-Versand wird **nicht** ausgeloest (`test-config/configuration.yml` definiert nur Filesystem-Notifier)
- produktive Domain `auth.kaleschke.info` wird **nicht** uebernommen
- Testcontainer publishen nur auf `127.0.0.1`, keine LAN-/Tailscale-Bindung
- Borg-Passphrase wird aus `/mnt/user/appdata/secrets/borg_repo_passphrase.txt` gelesen und nirgendwo geloggt
## Geplanter Ablauf
1. Restore-Lab-Pfade leer anlegen
2. `local/appdata/authelia/config` aus dem aktuellsten Borg-Archiv extrahieren
3. minimale `test-config/configuration.yml` erzeugen; restaurierte Begleitdateien wie `users_database.yml` bleiben im Runtime-Mount, produktive externe Abhaengigkeiten werden nicht uebernommen; `notifier` auf Filesystem, `ntp.disable_startup_check: true`, `storage` auf Test-Postgres
4. Test-Postgres mit `ops/restore-tests/authelia-compose.test.yml` **frisch** hochfahren (keine Daten aus Dump - siehe Encryption-Key-Begruendung oben)
5. `authelia config validate` gegen `test-config/configuration.yml` laufen lassen
6. `restoretest-authelia` starten und HTTP-Health `http://127.0.0.1:19091/api/health` pollen
7. Report unter `/mnt/user/backups/restore-reports/authelia-YYYY-MM-DD.md` schreiben
8. Testcontainer stoppen und Restore-Lab bereinigen (`--keep-data` ueberschreibt)
## Smoke-Test
Minimal erfolgreich:
- Borg-Extract der Authelia-Config gelingt
- Test-Postgres startet `healthy`
- `authelia config validate` laeuft ohne Fehler durch
- HTTP `200` auf `/api/health` innerhalb 120 s
Optional spaeter:
- vollstaendigen Auth-Flow gegen Test-User aus `users_database.yml` durchspielen
- WebAuthn-Endpunkt /api/secondfactor/webauthn pruefen
- ForwardAuth-Pfad gegen Mock-Backend testen
## Bekannte Komplikationen
| Risiko | Beschreibung | Mitigation |
|---|---|---|
| Testkonfig-Schema-Drift | Authelia erwartet nach Upgrade andere Keys in der Minimal-Konfig | bei `config validate`-Fehler Test-Block im Skript anpassen |
| SMTP-Startup-Check blockiert Start | Wenn Authelia trotz `disable_startup_check` SMTP probiert | Container-Logs lesen, ggf. Notifier-Block weiter haerten |
| NTP-Lookup im Test-Netz | Container hat keinen DNS-Resolver fuer `time.cloudflare.com` | im Smoke per `ntp.disable_startup_check: true` deaktiviert |
| Storage-Encryption-Key vs. Dump | siehe "Bewusst nicht Teil dieses Tests" - der Smoke laeuft FRISCH ohne Dump | by design - Daten-Decrypt-Drill ist separate Aufgabe |
| identity_validation Schema-Drift | Aelteres/neueres Authelia-Schema erwartet andere Keys | Validate-Config Output lesen, ggf. Test-Block anpassen |
| users_database.yml mit produktiven Hashes | Daten werden ins Restore-Lab kopiert, aber niemals gemountet auf produktive Domain | OK; Testpfad ist isoliert, kein Browser-Zugang ueber LAN |
## Status
- Skript- und Compose-Scaffold abgelegt am 2026-06-02
- Erstlauf am 2026-06-03 erfolgreich: Config aus Borg, minimale Test-Konfiguration, frisches Test-Postgres, HTTP `/api/health` `200`, Report `/mnt/user/backups/restore-reports/authelia-2026-06-03.md`
- Fuer die Rotation vorgesehen: zweiter Samstag in geraden Monaten, 07:30
ops/restore-tests/authelia-restore-test.sh
-311
View File
@@ -1,311 +0,0 @@
#!/bin/bash
set -euo pipefail
# Authelia Restore Smoke Test
#
# Nicht-destruktiver Restore-Smoke-Test fuer Authelia.
#
# Was dieser Smoke nachweist:
# - Authelia-Config kann aus dem produktiven Borg-Archiv extrahiert werden
# - die restaurierten Begleitdateien (users_database.yml etc.) sind lesbar
# - eine minimale Test-Konfiguration, die diese Begleitdateien nutzt und
# produktive externe Abhaengigkeiten (Postgres/SMTP) durch Wegwerf-Backends
# ersetzt, ist gegen den produktiven Authelia-Image-Pin valide
# (`authelia config validate`)
# - Authelia startet damit gegen ein frisches Test-Postgres und antwortet
# auf `/api/health`
#
# Was dieser Smoke bewusst NICHT nachweist:
# - Daten-Restore des produktiven authelia.dump. Authelia verschluesselt
# Storage-Werte mit AUTHELIA_STORAGE_ENCRYPTION_KEY; ein Restore mit
# produktiven Daten in eine Test-Instanz mit Wegwerf-Encryption-Key
# schlaegt im Startup-Check fehl ("the configured encryption key does
# not appear to be valid for this database"). Daten-Decrypt ist eine
# eigene DR-Aufgabe mit kontrollierter Schluessel-Verwendung, nicht
# Teil dieses Smokes. Frische des Dumps wird ueber
# check-restore-freshness.sh ueberwacht.
# - vollstaendiger Login-/2FA-/ForwardAuth-Flow.
#
# Produktive Authelia-Container, produktive Postgres-DB, produktive Secrets
# und produktiver SMTP-Versand werden NICHT angefasst.
SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
. "$SCRIPT_DIR/common.sh"
WHATIF=0
KEEP_DATA=0
for arg in "$@"; do
case "$arg" in
--what-if) WHATIF=1 ;;
--keep-data) KEEP_DATA=1 ;;
*) echo "Unknown argument: $arg" >&2; exit 1 ;;
esac
done
RESTORE_ROOT="/mnt/user/backups/restore-lab/authelia"
RESTORED_CONFIG_DIR="$RESTORE_ROOT/config"
TEST_CONFIG_DIR="$RESTORE_ROOT/test-config"
REPORT_ROOT="/mnt/user/backups/restore-reports"
EXTRACT_DIR="$BORG_RESTORE_HOST_ROOT/authelia-extract"
COMPOSE_FILE="$SCRIPT_DIR/authelia-compose.test.yml"
REPORT_FILE="$REPORT_ROOT/authelia-$(date +%F).md"
if [ "$WHATIF" -eq 1 ]; then
cat <<EOF
Authelia restore test
Mode: WhatIf
RestoreRoot: $RESTORE_ROOT
ReportRoot: $REPORT_ROOT
Expected Borg source paths:
- local/appdata/authelia/config
Planned isolation:
- Test-Postgres: postgres:18.4 mit Wegwerf-Credentials, FRISCH
- Test-Authelia: authelia/authelia:4.39.20 (Image-Pin wie Produktion)
- Wegwerf-Secrets ausschliesslich im Test-Compose
- test-config/configuration.yml wird im Restore-Lab erzeugt:
* storage -> Test-Postgres (kein produktives Postgres erreicht)
* notifier -> Filesystem (KEIN SMTP-Versand)
* session -> lokaler Smoke ohne produktive Session-Secrets
* ntp -> disable_startup_check (kein DNS im isolierten Test-Netz)
- Test endpoint: 127.0.0.1:19091/api/health (no Traefik, no public domain)
Bewusst NICHT Teil dieses Smokes:
- pg_restore von postgresql17-authelia.dump. Authelia verschluesselt
Storage-Werte mit AUTHELIA_STORAGE_ENCRYPTION_KEY; ein Restore in eine
Test-Instanz mit Wegwerf-Key ist by design nicht boot-faehig.
Dump-Frische wird via check-restore-freshness.sh ueberwacht.
Smoke-Test:
- authelia config validate gegen test-config/configuration.yml
- HTTP 200 von /api/health
EOF
exit 0
fi
require_cmd docker
require_cmd curl
require_path "$BORG_PASSPHRASE_FILE_DEFAULT"
require_path "$COMPOSE_FILE"
RESTORE_SUCCESS=0
cleanup() {
cleanup_compose "$COMPOSE_FILE"
if [ "$RESTORE_SUCCESS" -ne 1 ]; then
preserve_on_failure "authelia" "$RESTORE_ROOT"
rm -rf "$EXTRACT_DIR"
return
fi
if [ "$KEEP_DATA" -ne 1 ]; then
rm -rf "$RESTORE_ROOT"
fi
rm -rf "$EXTRACT_DIR"
}
trap cleanup EXIT
rm -rf "$EXTRACT_DIR" "$RESTORE_ROOT"
mkdir -p "$RESTORED_CONFIG_DIR" "$TEST_CONFIG_DIR" "$RESTORE_ROOT/postgres"
archive="$(latest_archive_name)"
repo="$(borg_repo_url)"
if [ -z "$archive" ] || [ -z "$repo" ]; then
echo "Could not resolve Borg repo/archive from borg-ui database" >&2
exit 1
fi
# Stufe 1: Config aus Borg extrahieren
borg_extract "/restore/authelia-extract" "local/appdata/authelia/config"
if [ ! -d "$EXTRACT_DIR/local/appdata/authelia/config" ]; then
echo "Authelia config path missing in Borg archive" >&2
exit 1
fi
cp -a "$EXTRACT_DIR/local/appdata/authelia/config/." "$RESTORED_CONFIG_DIR/"
# Stufe 2: Minimale Test-Konfiguration erzeugen.
# Die restaurierte Originalkonfig bleibt als Diagnosematerial erhalten. Der
# Smoke nutzt bewusst eine neu geschriebene Test-Config, damit keine produktiven
# Blocks (SMTP, echtes Postgres, Session/JWT-Altkeys) hineinmergen koennen.
ORIGINAL_CONFIG_FILE="$RESTORED_CONFIG_DIR/configuration.yml"
TEST_CONFIG_FILE="$TEST_CONFIG_DIR/configuration.yml"
if [ ! -f "$ORIGINAL_CONFIG_FILE" ]; then
echo "configuration.yml missing in restored config dir" >&2
exit 1
fi
# Kopiere alle Begleitdateien (z. B. users_database.yml) in einen separaten
# Runtime-Mount. configuration.yml wird danach vollstaendig neu geschrieben.
cp -a "$RESTORED_CONFIG_DIR/." "$TEST_CONFIG_DIR/"
cp "$ORIGINAL_CONFIG_FILE" "$RESTORED_CONFIG_DIR/configuration.yml.original"
cat > "$TEST_CONFIG_FILE" <<'YAML'
---
# Minimal-Konfiguration nur fuer den Restore-Smoke.
theme: dark
server:
address: tcp://0.0.0.0:9091
log:
level: info
authentication_backend:
file:
path: /config/users_database.yml
password:
algorithm: argon2id
iterations: 3
key_length: 32
salt_length: 16
memory: 65536
parallelism: 4
access_control:
# Authelia 4.39 verlangt: wenn KEINE Regeln gesetzt sind, muss default_policy
# 'two_factor' oder 'one_factor' sein. 'bypass' ist als Default-Policy ohne
# explizite Regeln nicht erlaubt. Fuer den Smoke ist das egal: /api/health
# ist ein public Endpunkt und laeuft nicht durch access_control.
default_policy: two_factor
regulation:
max_retries: 3
find_time: 2m
ban_time: 5m
totp:
issuer: kaleschke.info
period: 30
skew: 1
storage:
postgres:
address: tcp://restoretest-authelia-postgres:5432
database: authelia
username: authelia
# Passwort kommt ueber AUTHELIA_STORAGE_POSTGRES_PASSWORD ENV.
notifier:
disable_startup_check: true
filesystem:
filename: /config/notifier/notifications.txt
ntp:
# Test-Netz hat keinen DNS-Resolver fuer time.cloudflare.com; ohne diesen
# Schalter loggt Authelia "Could not determine the clock offset" und der
# Startup-Check kann fehlschlagen.
disable_startup_check: true
session:
cookies:
- name: authelia_session_restoretest
domain: kaleschke.info
authelia_url: https://auth.kaleschke.info
default_redirection_url: https://glance.kaleschke.info
expiration: 1h
inactivity: 5m
identity_validation:
reset_password:
jwt_secret: restoretest-authelia-reset-password-jwt-secret-placeholder-64bytes
jwt_lifespan: 5m
jwt_algorithm: HS256
YAML
mkdir -p "$TEST_CONFIG_DIR/notifier"
chmod -R a+rwX "$TEST_CONFIG_DIR/notifier"
# Stufe 3: Test-Postgres hochfahren (FRISCH, keine Daten aus Dump).
# Authelia legt sein Schema beim ersten Start selbst an und schreibt eine
# Encryption-Probe mit AUTHELIA_STORAGE_ENCRYPTION_KEY. Ein Restore des
# produktiven authelia.dump in diese Instanz wuerde die Encryption-Probe
# mit einem anderen Key vorbelegen und Authelia beim Startup-Check
# ablehnen lassen ("the configured encryption key does not appear to be
# valid for this database"). Genau aus diesem Grund laeuft der Smoke
# bewusst auf einer leeren DB. Frische des produktiven Dumps wird
# separat in check-restore-freshness.sh ueberwacht.
docker compose -f "$COMPOSE_FILE" up -d restoretest-authelia-postgres >/dev/null
until docker exec restoretest-authelia-postgres pg_isready -U authelia -d authelia >/dev/null 2>&1; do
sleep 2
done
# Stufe 4: config validate im Container-Kontext, gegen minimale Test-Config
validate_status="ok"
if ! docker run --rm \
-e AUTHELIA_SESSION_SECRET=restoretest-authelia-session-secret-placeholder-32 \
-e AUTHELIA_STORAGE_ENCRYPTION_KEY=restoretest-authelia-storage-enc-key-placeholder-32 \
-e AUTHELIA_STORAGE_POSTGRES_PASSWORD=restoretest-authelia-db \
-v "$TEST_CONFIG_DIR:/config" \
authelia/authelia:4.39.20@sha256:1b363e9279e742397966333f364e0876ae02bf5c876de73e83af6d48c57ff51b \
authelia config validate --config /config/configuration.yml \
>/tmp/authelia-validate.log 2>&1; then
validate_status="failed"
cat /tmp/authelia-validate.log >&2
exit 1
fi
# Stufe 5: Authelia-Container starten. Das Compose nutzt test-config als
# /config-Mount mit isolierten Test-Backends.
docker compose -f "$COMPOSE_FILE" up -d restoretest-authelia >/dev/null
http_status=""
for _ in $(seq 1 60); do
http_status="$(curl -s -o /tmp/authelia-body.html -w '%{http_code}' \
http://127.0.0.1:19091/api/health || true)"
if [ "$http_status" = "200" ]; then
break
fi
sleep 2
done
if [ "$http_status" != "200" ]; then
echo "Authelia HTTP health failed: status=$http_status" >&2
docker logs --tail 120 restoretest-authelia >&2 || true
exit 1
fi
write_report "$REPORT_FILE" <<EOF
# Authelia Restore Test Report - $(date +%F)
- Service: \`authelia\`
- Source repo: \`$repo\`
- Archive: \`$archive\`
- Restore root: \`$RESTORE_ROOT\`
- Test containers:
- \`restoretest-authelia\`
- \`restoretest-authelia-postgres\` (fresh schema, no productive dump)
- Test endpoint: \`http://127.0.0.1:19091/api/health\`
- Result: \`SUCCESS\`
## Checks
- Borg extract of config: \`ok\`
- configuration.yml present in archive: \`ok\`
- test runtime configuration.yml written: \`ok\`
- \`authelia config validate\`: \`$validate_status\`
- HTTP /api/health status: \`$http_status\`
## Scope
Dieser Smoke prueft: Borg-Restore der Config, Validate gegen Produktions-Image,
Authelia-Boot gegen frische Test-Postgres + Wegwerf-Encryption-Key,
HTTP-Health-Endpoint antwortet.
Bewusst NICHT Teil des Smokes: pg_restore des produktiven authelia.dump.
Authelia verschluesselt Storage-Werte mit \`AUTHELIA_STORAGE_ENCRYPTION_KEY\`;
ein Restore mit produktiven Daten in eine Test-Instanz mit Wegwerf-Key
schlaegt im Startup-Check by design fehl. Frische des produktiven Dumps
wird in \`check-restore-freshness.sh\` ueberwacht; Daten-Decrypt-Drill ist
eine separate DR-Aufgabe.
## Notes
- Test ran without Traefik and without the productive domain \`auth.kaleschke.info\`.
- Productive Authelia secrets under \`/mnt/user/appdata/secrets/authelia_*.txt\` were NOT mounted.
- Notifier was forced to filesystem (\`/config/notifier/notifications.txt\`); no SMTP call to GMX.
- Storage forced to isolated test postgres; productive shared PostgreSQL 18 was NOT touched.
- NTP startup-check disabled in test config (kein DNS-Resolver im isolierten Compose-Netz).
- Test data was cleaned after success: \`$([ "$KEEP_DATA" -eq 1 ] && echo no || echo yes)\`
EOF
RESTORE_SUCCESS=1
echo "Authelia restore test ok -> $REPORT_FILE"
ops/restore-tests/authelia-runbook.md
-86
View File
@@ -1,86 +0,0 @@
# Authelia Restore Runbook
## Status
Skript und Test-Compose sind validiert. **Erstlauf 2026-06-03 erfolgreich**: Config aus Borg extrahiert, minimale Test-Konfiguration validiert, frisches Test-Postgres gestartet, HTTP `/api/health` `200`. Report: `/mnt/user/backups/restore-reports/authelia-2026-06-03.md`. Authelia ist Tier-1-kritisch, deshalb bleibt dieser Test bewusst konservativ: Smoke-Test prueft nur Config-Validate + HTTP-Health, kein vollstaendiger Auth-Flow und kein produktiver Dump-Restore.
## Vorbedingungen
- Borg-Quelle ist verfuegbar
- `borg-ui`-Container laeuft
- Borg-Passphrase-Datei vorhanden: `/mnt/user/appdata/secrets/borg_repo_passphrase.txt`
- `borg-ui` mountet die Passphrase im Container als `/local/secrets/borg_repo_passphrase.txt`
- aktuelles Borg-Archiv enthaelt `local/appdata/authelia/config`
- optional: `local/borg-dumps/latest/postgresql17-authelia.dump`
- Testpfade unter `/mnt/user/backups/restore-lab/` und `/mnt/user/backups/restore-reports/` sind freigegeben
- Port `127.0.0.1:19091` frei
- freier Speicher unter `/mnt/user/backups/restore-lab/authelia` (~200 MB reichen)
## Bestaetigter Host-Stand (Soll)
- produktiver Authelia-Container: `authelia` mit Image `authelia/authelia:4.39.20@sha256:1b363e9279e742397966333f364e0876ae02bf5c876de73e83af6d48c57ff51b`
- produktiver Config-Pfad: `/mnt/user/appdata/authelia/config`
- produktive Secrets: `/mnt/user/appdata/secrets/authelia_*.txt` (werden vom Test **nicht** gebraucht)
- produktive Storage: shared PostgreSQL 18 (wird vom Test **nicht** angesprochen)
## Erster Lauf - trockene Variante
```bash
bash /mnt/user/services/homelab-infra/ops/restore-tests/authelia-restore-test.sh --what-if
```
Erwartete Ausgabe: nur Plan-Output, kein Docker-Start, kein Borg-Extract.
## Erster Lauf - echter Test (Operator-freigegeben)
```bash
bash /mnt/user/services/homelab-infra/ops/restore-tests/authelia-restore-test.sh --keep-data
```
Bei Erfolg:
- Report unter `/mnt/user/backups/restore-reports/authelia-YYYY-MM-DD.md`
- Restore-Lab-Daten bleiben mit `--keep-data` erhalten
- ohne `--keep-data` wird das Restore-Lab geloescht; bei Fehler wird es nach `/mnt/user/backups/restore-lab/_failed/authelia-...` verschoben
## Smoke-Test-Pruefungen
Minimal erwartet im Report:
- Borg extract of config: `ok`
- Test-Postgres healthy
- `authelia config validate`: `ok`
- HTTP /api/health status: `200`
## Fehlerfaelle
| Symptom | Ursache | Massnahme |
|---|---|---|
| `config validate` failt mit `notifier` Block | Testkonfig enthaelt mehr als einen Notifier | `test-config/configuration.yml` pruefen; Minimal-Test-Block im Skript anpassen |
| `config validate` failt mit `session.domain` | aelteres/neueres Schema | Test-`session:`-Block an reales Authelia-Schema anpassen |
| `config validate` failt mit `access_control` default_policy | Authelia >=4.39 verlangt ohne Rules `two_factor`/`one_factor` | Test-Block ist bereits auf `two_factor` gesetzt; bei weiterer Schema-Aenderung anpassen |
| HTTP-Timeout 120 s | Authelia haengt in Postgres-Schema-Migration | `docker logs --tail 200 restoretest-authelia` lesen, ggf. Wartezeit erhoehen |
| `encryption key does not appear to be valid for this database` | jemand hat `pg_restore` des produktiven Dumps wieder eingebaut | `pg_restore` ist seit `2026-06-03` bewusst NICHT mehr Teil dieses Smokes - siehe Plan/Skript-Doku; nicht re-aktivieren ohne kontrollierte Encryption-Key-Choreographie |
| SMTP-Connect im Log | Testkonfig oder Env erzeugt unerwartet SMTP | `test-config/configuration.yml` und `AUTHELIA_*SMTP*` Env pruefen |
| `Could not determine the clock offset` | DNS-Lookup `time.cloudflare.com` failt im isolierten Test-Netz | `ntp.disable_startup_check: true` ist im Test-Config-Block bereits gesetzt; bei Aenderung beibehalten |
| `configuration environment variable not expected: AUTHELIA__SERVER__ADDRESS` | Doppel-Underscore ENV im Compose | seit `2026-06-03` entfernt; `server.address` kommt aus configuration.yml |
## Cleanup
- bei Erfolg ohne `--keep-data`: `rm -rf /mnt/user/backups/restore-lab/authelia` und Extract-Cache
- bei Fehler: Datenpfad wird via `preserve_on_failure` nach `/mnt/user/backups/restore-lab/_failed/authelia-...` umbenannt
Produktive Authelia-Container, produktive Secrets, produktive Postgres-DB und produktiver SMTP-Account werden niemals beruehrt.
## Schedule
Empfohlener Schedule nach erfolgreichem Erstlauf: zweimonatlich (2. Samstag in geraden Monaten), damit nicht mit Paperless kollidierend.
## Festgelegte Entscheidungen
- Test-Compose nutzt denselben Image-Digest wie Produktion.
- Wegwerf-Secrets ausschliesslich im Test-Compose; niemals produktive Authelia-Secrets einsetzen.
- Test-Postgres ist isoliert; produktive shared PostgreSQL 18 wird nicht angesprochen.
- Notifier wird auf Filesystem umgebogen; KEIN echter SMTP-Versand.
- Test-Port nur auf `127.0.0.1:19091`, keine LAN-/Traefik-Anbindung.
- Borg-Passphrase wird aus Host-Secret-Datei gelesen und nirgendwo geloggt.
ops/restore-tests/check-restore-freshness.sh
-76
View File
@@ -25,69 +25,6 @@ check_file_age_days() {
echo $(( (now_epoch - mtime) / 86400 ))
}
# pg_restore --list als billiger Header-Check fuer Custom-Format-Dumps;
# erkennt Korruption, die mit reinem "exists+nonempty" durchrutscht. Wir
# brauchen kein laufendes Postgres; der Check liest nur die Toc-Section.
PG_DUMPS="postgresql17-paperless.dump postgresql17-mailarchiver.dump postgresql17-authelia.dump mealie.dump immich.dump nextcloud.dump"
is_pg_custom_dump() {
case " $PG_DUMPS " in *" $1 "*) return 0;; *) return 1;; esac
}
pg_header_ok() {
local path="$1"
if ! command -v pg_restore >/dev/null 2>&1; then
# ohne Host-pg_restore: in laufendem Postgres-Container probieren
if command -v docker >/dev/null 2>&1 && docker inspect postgresql17 >/dev/null 2>&1; then
if docker exec -i postgresql17 pg_restore --list < "$path" >/dev/null 2>&1; then
return 0 # Header valide
else
return 1 # Header korrupt
fi
fi
return 2 # nicht pruefbar (kein pg_restore, kein Container)
fi
pg_restore --list "$path" >/dev/null 2>&1
}
check_pg_header() {
local dump="$1"
local path="$2"
local age="$3"
local missing_mode="${4:-critical}"
if [ ! -f "$path" ]; then
if [ "$missing_mode" = "optional" ]; then
info+=("DUMP_OPTIONAL_MISSING $dump")
else
critical+=("DUMP_MISSING $dump")
fi
return
fi
if [ ! -s "$path" ]; then
critical+=("DUMP_EMPTY $dump")
return
fi
if [ "$age" -gt "$MAX_DUMP_AGE_HOURS" ]; then
if [ "$missing_mode" = "optional" ]; then
warnings+=("DUMP_OPTIONAL_STALE $dump age=${age}h")
else
critical+=("DUMP_STALE $dump age=${age}h")
fi
return
fi
if pg_header_ok "$path"; then
rc=0
else
rc=$?
fi
case "$rc" in
0) info+=("DUMP_OK $dump age=${age}h header=ok") ;;
1) critical+=("DUMP_HEADER_INVALID $dump (pg_restore --list failed)") ;;
2) info+=("DUMP_OK $dump age=${age}h header=unchecked") ;;
esac
}
for dump in \
postgresql17-paperless.dump \
postgresql17-mailarchiver.dump \
@@ -111,24 +48,11 @@ for dump in \
age="$(check_file_age_hours "$path")"
if [ "$age" -gt "$MAX_DUMP_AGE_HOURS" ]; then
critical+=("DUMP_STALE $dump age=${age}h")
continue
fi
if is_pg_custom_dump "$dump"; then
check_pg_header "$dump" "$path" "$age"
else
info+=("DUMP_OK $dump age=${age}h")
fi
done
optional_dump="postgresql17-authelia.dump"
optional_path="$DUMP_ROOT/$optional_dump"
optional_age=0
if [ -f "$optional_path" ]; then
optional_age="$(check_file_age_hours "$optional_path")"
fi
check_pg_header "$optional_dump" "$optional_path" "$optional_age" optional
for service in vaultwarden gitea paperless; do
if [ ! -d "$REPORT_ROOT" ]; then
warnings+=("REPORT_ROOT_MISSING $REPORT_ROOT")
ops/restore-tests/common.sh
-42
View File
@@ -20,28 +20,7 @@ require_path() {
}
}
require_borg_container() {
docker inspect "$BORG_CONTAINER" >/dev/null 2>&1 || {
echo "Missing Borg container: $BORG_CONTAINER" >&2
exit 1
}
[ "$(docker inspect -f '{{.State.Running}}' "$BORG_CONTAINER" 2>/dev/null)" = "true" ] || {
echo "Borg container is not running: $BORG_CONTAINER" >&2
exit 1
}
docker exec "$BORG_CONTAINER" test -r /data/borg.db >/dev/null 2>&1 || {
echo "Missing borg-ui database in container: $BORG_CONTAINER:/data/borg.db" >&2
exit 1
}
docker exec "$BORG_CONTAINER" test -r /local/secrets/borg_repo_passphrase.txt >/dev/null 2>&1 || {
echo "Missing Borg passphrase in container: $BORG_CONTAINER:/local/secrets/borg_repo_passphrase.txt" >&2
echo "Host path exists, but borg-ui must mount it as /local/secrets/borg_repo_passphrase.txt." >&2
exit 1
}
}
latest_archive_name() {
require_borg_container
docker exec -i "$BORG_CONTAINER" python3 - <<'PY'
import sqlite3
conn = sqlite3.connect('/data/borg.db')
@@ -55,7 +34,6 @@ PY
}
borg_repo_url() {
require_borg_container
docker exec -i "$BORG_CONTAINER" python3 - <<'PY'
import sqlite3
conn = sqlite3.connect('/data/borg.db')
@@ -72,7 +50,6 @@ borg_extract() {
local extract_dir="$1"
shift
local paths=("$@")
require_borg_container
docker exec -i "$BORG_CONTAINER" python3 - "$extract_dir" "${paths[@]}" <<'PY'
import os, sys, subprocess
extract_dir = sys.argv[1]
@@ -111,22 +88,3 @@ cleanup_compose() {
docker compose -f "$compose_file" down >/dev/null 2>&1 || true
fi
}
# Hilfsfunktion: bei Fehler-Exit Restore-Lab-Pfad nicht loeschen, sondern in
# einen `_failed/<service>-<date>-<pid>`-Pfad umbenennen, damit Post-Mortem
# moeglich bleibt. Aufrufer setzt vor Erfolg `RESTORE_SUCCESS=1`.
RESTORE_FAILED_ROOT="${RESTORE_FAILED_ROOT:-/mnt/user/backups/restore-lab/_failed}"
preserve_on_failure() {
local service="$1"
local path="$2"
if [ ! -e "$path" ]; then
return 0
fi
mkdir -p "$RESTORE_FAILED_ROOT"
local target="$RESTORE_FAILED_ROOT/${service}-$(date +%F)-$$"
if mv "$path" "$target" 2>/dev/null; then
echo "preserved failed restore data: $target" >&2
else
echo "failed to preserve restore data: $path -> $target" >&2
fi
}
ops/restore-tests/gitea-restore-test.sh
+3 -10
View File
@@ -37,14 +37,8 @@ require_cmd curl
require_path "$BORG_PASSPHRASE_FILE_DEFAULT"
require_path "$COMPOSE_FILE"
RESTORE_SUCCESS=0
cleanup() {
cleanup_compose "$COMPOSE_FILE"
if [ "$RESTORE_SUCCESS" -ne 1 ]; then
preserve_on_failure "gitea" "$RESTORE_ROOT"
rm -rf "$EXTRACT_DIR"
return
fi
if [ "$KEEP_DATA" -ne 1 ]; then
rm -rf "$DATA_DIR"
fi
@@ -67,9 +61,9 @@ sleep 8
status="$(curl -s -o /tmp/gitea-body.html -w '%{http_code}' http://127.0.0.1:13000)"
grep -qi "Gitea" /tmp/gitea-body.html
if timeout 5 bash -lc '</dev/tcp/127.0.0.1/12222' >/dev/null 2>&1; then
ssh_state="tcp-open"
ssh_state="open"
else
echo "Gitea SSH port not reachable (TCP connect failed)" >&2
echo "Gitea SSH port not reachable" >&2
exit 1
fi
@@ -91,7 +85,7 @@ write_report "$REPORT_FILE" <<EOF
- Borg extract into isolated restore-lab: \`ok\`
- HTTP status: \`$status\`
- HTML content: \`Gitea\`
- SSH TCP port: \`$ssh_state\` (TCP connect only, not a full SSH handshake)
- SSH port: \`$ssh_state\`
- Repository sample: \`$repo_sample\`
## Notes
@@ -100,5 +94,4 @@ write_report "$REPORT_FILE" <<EOF
- Test data was cleaned after success: \`$([ "$KEEP_DATA" -eq 1 ] && echo no || echo yes)\`
EOF
RESTORE_SUCCESS=1
echo "Gitea restore test ok -> $REPORT_FILE"
ops/restore-tests/gitea-runbook.md
+2 -2
View File
@@ -62,7 +62,7 @@ Wenn das Archiv den Pfad anders ablegt, zuerst mit `borg list "$BORG_REPO" "::AR
3. Testcontainer starten
```bash
docker compose -f /mnt/user/services/homelab-infra/ops/restore-tests/gitea-compose.test.yml up -d
docker compose -f /mnt/user/services/homelab/ops/restore-tests/gitea-compose.test.yml up -d
```
4. Smoke-Test
@@ -83,7 +83,7 @@ Minimal erfolgreich:
5. Testcontainer wieder stoppen
```bash
docker compose -f /mnt/user/services/homelab-infra/ops/restore-tests/gitea-compose.test.yml down
docker compose -f /mnt/user/services/homelab/ops/restore-tests/gitea-compose.test.yml down
```
6. Report schreiben
ops/restore-tests/immich-restore-test.sh
-7
View File
@@ -64,14 +64,8 @@ require_cmd curl
require_path "$BORG_PASSPHRASE_FILE_DEFAULT"
require_path "$COMPOSE_FILE"
RESTORE_SUCCESS=0
cleanup() {
cleanup_compose "$COMPOSE_FILE"
if [ "$RESTORE_SUCCESS" -ne 1 ]; then
preserve_on_failure "immich" "$RESTORE_ROOT"
rm -rf "$EXTRACT_DIR"
return
fi
if [ "$KEEP_DATA" -ne 1 ]; then
rm -rf "$RESTORE_ROOT"
fi
@@ -250,5 +244,4 @@ write_report "$REPORT_FILE" <<EOF
- Restore-Quelle Dump: \`local/borg-dumps/latest/immich.dump\` aus aktuellem Borg-Archiv.
EOF
RESTORE_SUCCESS=1
echo "Immich restore test ok -> $REPORT_FILE"
ops/restore-tests/komodo-bootstrap-compose.test.yml
+1 -1
View File
@@ -3,7 +3,7 @@ services:
# Schreibt in den Restore-Lab-Pfad, NICHT in das produktive
# /mnt/user/appdata/komodo/mongo-Volume.
restoretest-komodo-mongo:
image: mongo:8.0.23@sha256:44aa79ae28ff80b56fe58681b66cda9336706df408a5175a6c04988aa54610d3
image: mongo:7.0.32@sha256:32979a1189dfdc44da3f5ed40d910495f5ad8f6f7f77556646f890a30b2d3f56
container_name: restoretest-komodo-mongo
restart: "no"
command: --quiet
ops/restore-tests/komodo-bootstrap-test.sh
-6
View File
@@ -53,13 +53,8 @@ fi
require_cmd docker
require_path "$COMPOSE_FILE"
RESTORE_SUCCESS=0
cleanup() {
docker compose -f "$COMPOSE_FILE" -p "$PROJECT_NAME" down -v >/dev/null 2>&1 || true
if [ "$RESTORE_SUCCESS" -ne 1 ]; then
preserve_on_failure "komodo-bootstrap" "$RESTORE_ROOT"
return
fi
if [ "$KEEP_DATA" -ne 1 ]; then
rm -rf "$RESTORE_ROOT"
fi
@@ -137,5 +132,4 @@ write_report "$REPORT_FILE" <<EOF
- Test-Daten wurden \`$([ "$KEEP_DATA" -eq 1 ] && echo behalten || echo bereinigt)\`.
EOF
RESTORE_SUCCESS=1
echo "Komodo bootstrap trockenlauf ok -> $REPORT_FILE"
ops/restore-tests/komodo-mongo-restore-compose.test.yml
-19
View File
@@ -1,19 +0,0 @@
services:
restoretest-komodo-mongorestore:
image: mongo:8.0.23@sha256:44aa79ae28ff80b56fe58681b66cda9336706df408a5175a6c04988aa54610d3
container_name: restoretest-komodo-mongorestore
restart: "no"
command: --quiet
environment:
MONGO_INITDB_ROOT_USERNAME: komodo
MONGO_INITDB_ROOT_PASSWORD: restoretest-komodo-mongo-pwd
volumes:
- /mnt/user/backups/restore-lab/komodo-mongo-restore/mongo:/data/db
healthcheck:
test: ["CMD", "mongosh", "--quiet", "--eval", "db.adminCommand('ping').ok"]
interval: 10s
timeout: 5s
retries: 10
start_period: 30s
security_opt:
- no-new-privileges:true
ops/restore-tests/komodo-mongo-restore-test.sh
-163
View File
@@ -1,163 +0,0 @@
#!/bin/bash
set -euo pipefail
# Komodo Mongo Daten-Restore Test
#
# Baut auf dem bestehenden Komodo-Bootstrap-Test auf und fuegt hinzu:
# - mongorestore von komodo-mongo.archive.gz in die Test-Mongo
# - Liest danach die stack-Collection, um zu pruefen, dass Komodo-
# Stack-Definitionen wiederhergestellt sind
#
# Das ist der Test, der im DR-Fall beweist, dass die KOMODO_*-Stack-
# ENV-Werte aus dem Mongo-Dump rekonstruiert werden koennen (die
# kanonische Quelle gemaess docs/DISASTER_RECOVERY.md 6.2.1).
#
# Produktive Komodo-Container und produktive Mongo-Datadir werden
# NICHT angefasst.
SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
. "$SCRIPT_DIR/common.sh"
WHATIF=0
KEEP_DATA=0
for arg in "$@"; do
case "$arg" in
--what-if) WHATIF=1 ;;
--keep-data) KEEP_DATA=1 ;;
*) echo "Unknown argument: $arg" >&2; exit 1 ;;
esac
done
RESTORE_ROOT="/mnt/user/backups/restore-lab/komodo-mongo-restore"
REPORT_ROOT="/mnt/user/backups/restore-reports"
COMPOSE_FILE="$SCRIPT_DIR/komodo-mongo-restore-compose.test.yml"
PROJECT_NAME="restoretest-komodo-mongorestore"
REPORT_FILE="$REPORT_ROOT/komodo-mongo-restore-$(date +%F).md"
DUMP_HOST_PATH="/mnt/user/backups/borg/dumps/latest/komodo-mongo.archive.gz"
if [ "$WHATIF" -eq 1 ]; then
cat <<EOF
Komodo Mongo Daten-Restore Test
Mode: WhatIf
RestoreRoot: $RESTORE_ROOT
ReportRoot: $REPORT_ROOT
DumpPath: $DUMP_HOST_PATH
Planned steps:
1. Frische Test-Mongo hochfahren (gleiche Compose wie Bootstrap-Test)
2. mongorestore --archive --gzip aus $DUMP_HOST_PATH
3. Stack-Collection auslesen (Beweis: Stack-Definitionen sind da)
4. Report schreiben
5. Cleanup
EOF
exit 0
fi
require_cmd docker
require_path "$COMPOSE_FILE"
require_path "$DUMP_HOST_PATH"
RESTORE_SUCCESS=0
cleanup() {
docker compose -f "$COMPOSE_FILE" -p "$PROJECT_NAME" down -v >/dev/null 2>&1 || true
if [ "$RESTORE_SUCCESS" -ne 1 ]; then
preserve_on_failure "komodo-mongo-restore" "$RESTORE_ROOT"
return
fi
if [ "$KEEP_DATA" -ne 1 ]; then
rm -rf "$RESTORE_ROOT"
fi
}
trap cleanup EXIT
rm -rf "$RESTORE_ROOT"
mkdir -p "$RESTORE_ROOT/mongo" "$RESTORE_ROOT/core" "$RESTORE_ROOT/keys" "$RESTORE_ROOT/periphery"
# Stufe 1: Nur Test-Mongo starten (kein Core/Periphery noetig fuer Dump-Restore)
docker compose -f "$COMPOSE_FILE" -p "$PROJECT_NAME" up -d \
restoretest-komodo-mongorestore >/dev/null
mongo_ok=0
for _ in $(seq 1 30); do
s="$(docker inspect restoretest-komodo-mongorestore --format '{{.State.Health.Status}}' 2>/dev/null || true)"
if [ "$s" = "healthy" ]; then mongo_ok=1; break; fi
sleep 2
done
if [ "$mongo_ok" -ne 1 ]; then
echo "Test-Mongo never reported healthy" >&2
docker logs --tail 80 restoretest-komodo-mongorestore >&2 || true
exit 1
fi
# Stufe 2: mongorestore aus dem Host-Dump
# --drop loescht existierende Collections vor dem Restore (frische DB, also harmlos).
# --gzip weil der Dump als .archive.gz erzeugt wurde.
# Auth mit den Wegwerf-Credentials aus dem Test-Compose.
restore_status="ok"
# --noIndexRestore: der Smoke prueft nur, dass Daten lesbar sind, nicht dass
# alle Indexe sauber aufgebaut werden. mongorestore scheitert sonst am
# Index-Rebuild weil der Test-User keine dbAdmin-Rolle hat. Fuer den
# DR-Nachweis (Stack-ENV-Werte lesbar) reicht das.
if ! docker exec -i restoretest-komodo-mongorestore \
mongorestore --archive --gzip --noIndexRestore \
-u komodo -p restoretest-komodo-mongo-pwd --authenticationDatabase admin \
--drop \
< "$DUMP_HOST_PATH" 2>/tmp/komodo-mongorestore.err; then
restore_status="failed"
cat /tmp/komodo-mongorestore.err >&2
exit 1
fi
# Stufe 3: Stack-Collection auslesen
# Komodo speichert Stack-Definitionen in der DB "komodo", Collection "Stack"
# (oder "stack" je nach Version). Wir zaehlen Dokumente als Beweis.
stack_count="n/a"
for coll in Stack stack; do
count="$(docker exec restoretest-komodo-mongorestore mongosh --quiet \
-u komodo -p restoretest-komodo-mongo-pwd --authenticationDatabase admin \
--eval "db.getSiblingDB('komodo').getCollection('$coll').countDocuments({})" \
2>/dev/null | tr -d '[:space:]' || true)"
if [ -n "$count" ] && [ "$count" != "0" ] && [ "$count" != "n/a" ]; then
stack_count="$count (collection: $coll)"
break
fi
done
# Alle DBs + Collections auflisten als zusaetzlicher Nachweis
db_list="$(docker exec restoretest-komodo-mongorestore mongosh --quiet \
-u komodo -p restoretest-komodo-mongo-pwd --authenticationDatabase admin \
--eval "db.adminCommand({listDatabases:1}).databases.map(d=>d.name).join(', ')" \
2>/dev/null | tr -d '\r' || echo "n/a")"
write_report "$REPORT_FILE" <<EOF
# Komodo Mongo Daten-Restore Test - $(date +%F)
- Dump: \`$DUMP_HOST_PATH\`
- Dump size: \`$(ls -lh "$DUMP_HOST_PATH" | awk '{print $5}')\`
- Project: \`$PROJECT_NAME\`
- Restore root: \`$RESTORE_ROOT\`
- Result: \`SUCCESS\`
## Checks
- Test-Mongo healthy: \`ok\`
- mongorestore --archive --gzip: \`$restore_status\`
- Databases after restore: \`$db_list\`
- Stack documents: \`$stack_count\`
## Scope
Dieser Test beweist, dass \`komodo-mongo.archive.gz\` in eine frische
Mongo-Instanz eingespielt werden kann und die Stack-Definitionen danach
lesbar sind. Im DR-Fall ist das die kanonische Quelle fuer
\`KOMODO_*\`-Stack-ENV-Werte (docs/DISASTER_RECOVERY.md 6.2.1).
## Notes
- Produktive Komodo-Container und produktive Mongo-Datadir wurden nicht beruehrt.
- Test-Mongo nutzt Wegwerf-Credentials (restoretest-komodo-mongo-pwd).
- Kein Komodo-Core gestartet (nicht noetig fuer Dump-Restore-Nachweis).
- Test-Daten wurden \`$([ "$KEEP_DATA" -eq 1 ] && echo behalten || echo bereinigt)\`.
EOF
RESTORE_SUCCESS=1
echo "Komodo Mongo restore test ok -> $REPORT_FILE"
ops/restore-tests/mailarchiver-compose.test.yml
-41
View File
@@ -1,41 +0,0 @@
services:
restoretest-mailarchiver-postgres:
image: postgres:18.4@sha256:8ff36f3c66371cba71d20ceedccfc3de9669a68737607888c4ef0af93abe8e39
container_name: restoretest-mailarchiver-postgres
restart: "no"
environment:
TZ: Europe/Berlin
POSTGRES_USER: mailarchiver
POSTGRES_DB: mailarchiver
POSTGRES_PASSWORD: restoretest-mailarchiver-db
PGDATA: /var/lib/postgresql/18/docker
volumes:
- /mnt/user/backups/restore-lab/mailarchiver/postgres:/var/lib/postgresql
healthcheck:
test: ["CMD-SHELL", "pg_isready -U mailarchiver -d mailarchiver"]
interval: 10s
timeout: 5s
retries: 10
security_opt:
- no-new-privileges:true
restoretest-mailarchiver:
image: s1t5/mailarchiver@sha256:ea7fd8c2e3e0ef0941e8dd9e726e35a8de33296f5c7b9ed811df5168ae6a9714
container_name: restoretest-mailarchiver
restart: "no"
depends_on:
restoretest-mailarchiver-postgres:
condition: service_healthy
environment:
TZ: Europe/Berlin
# Wegwerf-Connection-String fuer isolierten Test.
# Produktiver MAILARCHIVER_DB_CONNECTION ist Stack-ENV-only und wird
# hier bewusst NICHT verwendet.
ConnectionStrings__DefaultConnection: "Host=restoretest-mailarchiver-postgres;Database=mailarchiver;Username=mailarchiver;Password=restoretest-mailarchiver-db"
Authentication__Password: restoretest-mailarchiver-auth
ports:
- "127.0.0.1:15000:5000"
volumes:
- /mnt/user/backups/restore-lab/mailarchiver/data-protection-keys:/app/DataProtection-Keys
security_opt:
- no-new-privileges:true
ops/restore-tests/mailarchiver-restore-test.sh
-172
View File
@@ -1,172 +0,0 @@
#!/bin/bash
set -euo pipefail
# Mail-Archiver Restore Smoke Test
#
# Borg-Extract der Data-Protection-Keys + pg_restore des mailarchiver-Dumps
# in isoliertes Test-Postgres + Container-Boot + HTTP-Smoke.
#
# In Produktion nutzt Mail-Archiver die Shared PostgreSQL 18 — im Test
# bekommt er ein eigenes isoliertes Test-Postgres mit Wegwerf-Credentials.
# Authelia-ForwardAuth wird im Smoke nicht geprueft (kein Traefik, kein
# Auth-Middleware).
SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
. "$SCRIPT_DIR/common.sh"
WHATIF=0
KEEP_DATA=0
for arg in "$@"; do
case "$arg" in
--what-if) WHATIF=1 ;;
--keep-data) KEEP_DATA=1 ;;
*) echo "Unknown argument: $arg" >&2; exit 1 ;;
esac
done
RESTORE_ROOT="/mnt/user/backups/restore-lab/mailarchiver"
REPORT_ROOT="/mnt/user/backups/restore-reports"
EXTRACT_DIR="$BORG_RESTORE_HOST_ROOT/mailarchiver-extract"
COMPOSE_FILE="$SCRIPT_DIR/mailarchiver-compose.test.yml"
REPORT_FILE="$REPORT_ROOT/mailarchiver-$(date +%F).md"
DUMP_HOST_PATH="/mnt/user/backups/borg/dumps/latest/postgresql17-mailarchiver.dump"
if [ "$WHATIF" -eq 1 ]; then
cat <<EOF
Mail-Archiver restore test
Mode: WhatIf
RestoreRoot: $RESTORE_ROOT
Borg source: local/appdata/mailarchiver/data-protection-keys
Host dump: $DUMP_HOST_PATH (645M)
Test endpoint: 127.0.0.1:15000
EOF
exit 0
fi
require_cmd docker
require_cmd curl
require_path "$BORG_PASSPHRASE_FILE_DEFAULT"
require_path "$COMPOSE_FILE"
require_path "$DUMP_HOST_PATH"
RESTORE_SUCCESS=0
cleanup() {
cleanup_compose "$COMPOSE_FILE"
if [ "$RESTORE_SUCCESS" -ne 1 ]; then
preserve_on_failure "mailarchiver" "$RESTORE_ROOT"
rm -rf "$EXTRACT_DIR"
return
fi
if [ "$KEEP_DATA" -ne 1 ]; then
rm -rf "$RESTORE_ROOT"
fi
rm -rf "$EXTRACT_DIR"
}
trap cleanup EXIT
rm -rf "$EXTRACT_DIR" "$RESTORE_ROOT"
mkdir -p "$RESTORE_ROOT/data-protection-keys" "$RESTORE_ROOT/postgres"
archive="$(latest_archive_name)"
repo="$(borg_repo_url)"
if [ -z "$archive" ] || [ -z "$repo" ]; then
echo "Could not resolve Borg repo/archive from borg-ui database" >&2
exit 1
fi
# Stufe 1: Data-Protection-Keys aus Borg
borg_extract "/restore/mailarchiver-extract" "local/appdata/mailarchiver/data-protection-keys"
if [ ! -d "$EXTRACT_DIR/local/appdata/mailarchiver/data-protection-keys" ]; then
echo "Mailarchiver data-protection-keys path missing in Borg archive" >&2
exit 1
fi
cp -a "$EXTRACT_DIR/local/appdata/mailarchiver/data-protection-keys/." "$RESTORE_ROOT/data-protection-keys/"
chmod -R a+rwX "$RESTORE_ROOT/data-protection-keys"
# Stufe 2: Test-Postgres + Dump
docker compose -f "$COMPOSE_FILE" up -d restoretest-mailarchiver-postgres >/dev/null
until docker exec restoretest-mailarchiver-postgres pg_isready -U mailarchiver -d mailarchiver >/dev/null 2>&1; do
sleep 2
done
restore_ok=0
for attempt in $(seq 1 12); do
if docker exec -i restoretest-mailarchiver-postgres \
pg_restore -U mailarchiver -d mailarchiver --clean --if-exists --no-owner --no-privileges \
< "$DUMP_HOST_PATH" 2>/tmp/mailarchiver-pg-restore.err; then
restore_ok=1
break
fi
if grep -qiE "starting up|shutting down|connection refused" /tmp/mailarchiver-pg-restore.err; then
sleep 5
continue
fi
if grep -qiE "FATAL|PANIC" /tmp/mailarchiver-pg-restore.err; then
cat /tmp/mailarchiver-pg-restore.err >&2
exit 1
fi
restore_ok=1
break
done
if [ "$restore_ok" -ne 1 ]; then
cat /tmp/mailarchiver-pg-restore.err >&2
exit 1
fi
# Stufe 3: Container starten
docker compose -f "$COMPOSE_FILE" up -d restoretest-mailarchiver >/dev/null
# Mailarchiver ist ein .NET-App, braucht ein paar Sekunden fuer DB-Migration.
# Smoke gegen den Root-Endpunkt — bei Authelia-geschuetztem Dienst liefert
# der Container selbst trotzdem einen HTTP-Response (302 oder 200).
http_status=""
for _ in $(seq 1 60); do
http_status="$(curl -s -o /tmp/mailarchiver-body.html -w '%{http_code}' \
-L http://127.0.0.1:15000/ || true)"
if [ "$http_status" = "200" ] || [ "$http_status" = "302" ] || [ "$http_status" = "401" ]; then
break
fi
sleep 2
done
if [ "$http_status" != "200" ] && [ "$http_status" != "302" ] && [ "$http_status" != "401" ]; then
echo "Mailarchiver HTTP smoke failed: status=$http_status" >&2
docker logs --tail 80 restoretest-mailarchiver >&2 || true
exit 1
fi
# Tabellen-Count als Sanity
table_count="$(docker exec restoretest-mailarchiver-postgres \
psql -U mailarchiver -d mailarchiver -tAc \
"SELECT count(*) FROM information_schema.tables WHERE table_schema='public';" \
2>/dev/null | tr -d '[:space:]' || echo "n/a")"
write_report "$REPORT_FILE" <<EOF
# Mail-Archiver Restore Test Report - $(date +%F)
- Service: \`mail-archiver\`
- Source repo: \`$repo\`
- Archive: \`$archive\`
- Restore root: \`$RESTORE_ROOT\`
- Test containers: \`restoretest-mailarchiver\`, \`restoretest-mailarchiver-postgres\`
- Test endpoint: \`http://127.0.0.1:15000/\`
- Result: \`SUCCESS\`
## Checks
- Borg extract of data-protection-keys: \`ok\`
- Host dump copy (645M): \`ok\`
- Dump import into isolated Postgres: \`ok\`
- HTTP status: \`$http_status\`
- Public table count in test DB: \`$table_count\`
## Notes
- Productive secrets (MAILARCHIVER_DB_CONNECTION, MAILARCHIVER_AUTH_PASSWORD) NOT used.
- Authelia ForwardAuth NOT tested (no Traefik in smoke).
- Test data was cleaned after success: \`$([ "$KEEP_DATA" -eq 1 ] && echo no || echo yes)\`
EOF
RESTORE_SUCCESS=1
echo "Mailarchiver restore test ok -> $REPORT_FILE"
ops/restore-tests/mealie-compose.test.yml
-45
View File
@@ -1,45 +0,0 @@
services:
restoretest-mealie-postgres:
image: postgres:18.4@sha256:8ff36f3c66371cba71d20ceedccfc3de9669a68737607888c4ef0af93abe8e39
container_name: restoretest-mealie-postgres
restart: "no"
environment:
TZ: Europe/Berlin
POSTGRES_USER: mealie
POSTGRES_DB: mealie
POSTGRES_PASSWORD: restoretest-mealie-db
PGDATA: /var/lib/postgresql/18/docker
volumes:
- /mnt/user/backups/restore-lab/mealie/postgres:/var/lib/postgresql
healthcheck:
test: ["CMD-SHELL", "pg_isready -U mealie -d mealie"]
interval: 10s
timeout: 5s
retries: 10
security_opt:
- no-new-privileges:true
restoretest-mealie:
image: ghcr.io/mealie-recipes/mealie:v3.19.2@sha256:f68e959bf66f4f458893ea58facac71690fe6f2ac7a31466b5cecb41b4e99c02
container_name: restoretest-mealie
restart: "no"
depends_on:
restoretest-mealie-postgres:
condition: service_healthy
environment:
TZ: Europe/Berlin
ALLOW_SIGNUP: "false"
PUID: "99"
PGID: "100"
DB_ENGINE: postgres
POSTGRES_SERVER: restoretest-mealie-postgres
POSTGRES_DB: mealie
POSTGRES_USER: mealie
POSTGRES_PASSWORD: restoretest-mealie-db
BASE_URL: http://127.0.0.1:19925
ports:
- "127.0.0.1:19925:9000"
volumes:
- /mnt/user/backups/restore-lab/mealie/data:/app/data
security_opt:
- no-new-privileges:true
ops/restore-tests/mealie-restore-test.sh
-162
View File
@@ -1,162 +0,0 @@
#!/bin/bash
set -euo pipefail
# Mealie Restore Smoke Test
#
# Borg-Extract der App-Daten + pg_restore des mealie.dump in isoliertes
# Test-Postgres + Mealie-Boot + HTTP-Smoke.
SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
. "$SCRIPT_DIR/common.sh"
WHATIF=0
KEEP_DATA=0
for arg in "$@"; do
case "$arg" in
--what-if) WHATIF=1 ;;
--keep-data) KEEP_DATA=1 ;;
*) echo "Unknown argument: $arg" >&2; exit 1 ;;
esac
done
RESTORE_ROOT="/mnt/user/backups/restore-lab/mealie"
REPORT_ROOT="/mnt/user/backups/restore-reports"
EXTRACT_DIR="$BORG_RESTORE_HOST_ROOT/mealie-extract"
COMPOSE_FILE="$SCRIPT_DIR/mealie-compose.test.yml"
REPORT_FILE="$REPORT_ROOT/mealie-$(date +%F).md"
DUMP_HOST_PATH="/mnt/user/backups/borg/dumps/latest/mealie.dump"
if [ "$WHATIF" -eq 1 ]; then
cat <<EOF
Mealie restore test
Mode: WhatIf
RestoreRoot: $RESTORE_ROOT
Borg source: local/appdata/mealie/data
Host dump: $DUMP_HOST_PATH
Test endpoint: 127.0.0.1:19925
EOF
exit 0
fi
require_cmd docker
require_cmd curl
require_path "$BORG_PASSPHRASE_FILE_DEFAULT"
require_path "$COMPOSE_FILE"
require_path "$DUMP_HOST_PATH"
RESTORE_SUCCESS=0
cleanup() {
cleanup_compose "$COMPOSE_FILE"
if [ "$RESTORE_SUCCESS" -ne 1 ]; then
preserve_on_failure "mealie" "$RESTORE_ROOT"
rm -rf "$EXTRACT_DIR"
return
fi
if [ "$KEEP_DATA" -ne 1 ]; then
rm -rf "$RESTORE_ROOT"
fi
rm -rf "$EXTRACT_DIR"
}
trap cleanup EXIT
rm -rf "$EXTRACT_DIR" "$RESTORE_ROOT"
mkdir -p "$RESTORE_ROOT/data" "$RESTORE_ROOT/postgres"
archive="$(latest_archive_name)"
repo="$(borg_repo_url)"
if [ -z "$archive" ] || [ -z "$repo" ]; then
echo "Could not resolve Borg repo/archive from borg-ui database" >&2
exit 1
fi
# Stufe 1: App-Daten aus Borg
borg_extract "/restore/mealie-extract" "local/appdata/mealie/data"
if [ ! -d "$EXTRACT_DIR/local/appdata/mealie/data" ]; then
echo "Mealie data path missing in Borg archive" >&2
exit 1
fi
cp -a "$EXTRACT_DIR/local/appdata/mealie/data/." "$RESTORE_ROOT/data/"
chmod -R a+rwX "$RESTORE_ROOT/data"
# Stufe 2: Test-Postgres hochfahren + Dump einspielen
docker compose -f "$COMPOSE_FILE" up -d restoretest-mealie-postgres >/dev/null
until docker exec restoretest-mealie-postgres pg_isready -U mealie -d mealie >/dev/null 2>&1; do
sleep 2
done
restore_ok=0
for attempt in $(seq 1 12); do
if docker exec -i restoretest-mealie-postgres \
pg_restore -U mealie -d mealie --clean --if-exists --no-owner --no-privileges \
< "$DUMP_HOST_PATH" 2>/tmp/mealie-pg-restore.err; then
restore_ok=1
break
fi
if grep -qiE "starting up|shutting down|connection refused" /tmp/mealie-pg-restore.err; then
sleep 5
continue
fi
if grep -qiE "FATAL|PANIC" /tmp/mealie-pg-restore.err; then
cat /tmp/mealie-pg-restore.err >&2
exit 1
fi
restore_ok=1
break
done
if [ "$restore_ok" -ne 1 ]; then
cat /tmp/mealie-pg-restore.err >&2
exit 1
fi
# Stufe 3: Mealie starten
docker compose -f "$COMPOSE_FILE" up -d restoretest-mealie >/dev/null
http_status=""
for _ in $(seq 1 60); do
http_status="$(curl -s -o /tmp/mealie-body.html -w '%{http_code}' \
-L http://127.0.0.1:19925/api/app/about || true)"
if [ "$http_status" = "200" ]; then
break
fi
sleep 2
done
if [ "$http_status" != "200" ]; then
echo "Mealie HTTP smoke failed: status=$http_status" >&2
docker logs --tail 80 restoretest-mealie >&2 || true
exit 1
fi
# Rezept-Count als Sanity-Check
recipe_count="$(docker exec restoretest-mealie-postgres \
psql -U mealie -d mealie -tAc \
"SELECT count(*) FROM recipes;" 2>/dev/null | tr -d '[:space:]' || echo "n/a")"
write_report "$REPORT_FILE" <<EOF
# Mealie Restore Test Report - $(date +%F)
- Service: \`mealie\`
- Source repo: \`$repo\`
- Archive: \`$archive\`
- Restore root: \`$RESTORE_ROOT\`
- Test containers: \`restoretest-mealie\`, \`restoretest-mealie-postgres\`
- Test endpoint: \`http://127.0.0.1:19925/api/app/about\`
- Result: \`SUCCESS\`
## Checks
- Borg extract of data: \`ok\`
- Host dump copy: \`ok\`
- Dump import into isolated Postgres: \`ok\`
- HTTP status from /api/app/about: \`$http_status\`
- Recipe count in test DB: \`$recipe_count\`
## Notes
- Productive Mealie secrets were NOT mounted; test uses throwaway DB password.
- Test data was cleaned after success: \`$([ "$KEEP_DATA" -eq 1 ] && echo no || echo yes)\`
EOF
RESTORE_SUCCESS=1
echo "Mealie restore test ok -> $REPORT_FILE"
ops/restore-tests/monthly-random-restore.sh
+1 -1
View File
@@ -3,7 +3,7 @@ set -euo pipefail
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
TOPIC="${TOPIC:-homelab-info}"
TESTS="${TESTS:-vaultwarden gitea paperless authelia}"
TESTS="${TESTS:-vaultwarden gitea paperless}"
pick_random() {
printf '%s\n' $TESTS | awk 'BEGIN { srand() } { items[++count] = $0 } END { print items[int(rand() * count) + 1] }'
ops/restore-tests/negative-freshness-alert-test.sh
-74
View File
@@ -1,74 +0,0 @@
#!/bin/bash
set -euo pipefail
SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
LAB_ROOT="${LAB_ROOT:-/mnt/user/backups/restore-lab/freshness-negative}"
REPORT_ROOT="${REPORT_ROOT:-/mnt/user/backups/restore-reports}"
ALERT_TOPIC="${ALERT_TOPIC:-homelab-alerts}"
INFO_TOPIC="${INFO_TOPIC:-homelab-info}"
SEND_NTFY="${SEND_NTFY:-1}"
stamp="$(date +%F-%H%M%S)"
test_root="$LAB_ROOT/$stamp"
dump_root="$test_root/dumps"
test_report_root="$test_root/reports"
report_file="$REPORT_ROOT/freshness-negative-$stamp.md"
raw_log="$test_root/check-output.md"
mkdir -p "$dump_root" "$test_report_root" "$REPORT_ROOT"
cleanup() {
rm -rf "$test_root"
}
trap cleanup EXIT
set +e
DUMP_ROOT="$dump_root" \
REPORT_ROOT="$test_report_root" \
MAX_DUMP_AGE_HOURS=26 \
MAX_REPORT_AGE_DAYS=45 \
"$SCRIPT_DIR/check-restore-freshness.sh" >"$raw_log" 2>&1
rc=$?
set -e
critical_count="$(awk -F': ' '/^Critical:/ {print $2; exit}' "$raw_log" | tr -d '[:space:]')"
critical_count="${critical_count:-0}"
{
echo "# Restore Freshness Negative Alert Test"
echo
echo "Timestamp: $(date '+%F %T')"
echo "Result: $([ "$rc" -ne 0 ] && [ "$critical_count" -gt 0 ] && echo "ok" || echo "failed")"
echo "Check exit code: $rc"
echo "Critical count: $critical_count"
echo "Synthetic dump root: $dump_root"
echo "Synthetic report root: $test_report_root"
echo "Production dump root touched: no"
echo
echo "## Check Output"
echo
cat "$raw_log"
} >"$report_file"
if [ "$rc" -ne 0 ] && [ "$critical_count" -gt 0 ]; then
if [ "$SEND_NTFY" = "1" ]; then
bash "$SCRIPT_DIR/send-ntfy.sh" \
"$ALERT_TOPIC" \
"TEST: Restore freshness alert path ok" \
"Negativtest erfolgreich: check-restore-freshness.sh meldete ${critical_count} Criticals gegen synthetischen leeren Testpfad. Produktive Dumps wurden nicht veraendert. Report: $report_file" \
high
fi
echo "Negative freshness alert test ok. Report: $report_file"
exit 0
fi
if [ "$SEND_NTFY" = "1" ]; then
bash "$SCRIPT_DIR/send-ntfy.sh" \
"$ALERT_TOPIC" \
"TEST FAILED: Restore freshness alert path" \
"Negativtest fehlgeschlagen: erwarteter Critical-Zustand wurde nicht erkannt. Report: $report_file" \
high || true
fi
echo "Negative freshness alert test failed. Report: $report_file" >&2
exit 1
ops/restore-tests/nextcloud-compose.test.yml
-66
View File
@@ -1,66 +0,0 @@
services:
restoretest-nextcloud-postgres:
# Gleiche Major-Version wie apps/nextcloud/docker-compose.yml in Produktion.
image: postgres:18.4@sha256:8ff36f3c66371cba71d20ceedccfc3de9669a68737607888c4ef0af93abe8e39
container_name: restoretest-nextcloud-postgres
restart: "no"
environment:
TZ: Europe/Berlin
POSTGRES_DB: nextcloud
POSTGRES_USER: nextcloud
POSTGRES_PASSWORD: restoretest-nextcloud-db
PGDATA: /var/lib/postgresql/18/docker
volumes:
- /mnt/user/backups/restore-lab/nextcloud/postgres:/var/lib/postgresql
healthcheck:
test: ["CMD-SHELL", "pg_isready -U nextcloud -d nextcloud"]
interval: 10s
timeout: 5s
retries: 10
security_opt:
- no-new-privileges:true
restoretest-nextcloud-redis:
image: redis:8.8.0-alpine@sha256:09160599abd229764c0fb44cb6be640294e1d360a54b19985ab4843dcf2d90f1
container_name: restoretest-nextcloud-redis
restart: "no"
command: redis-server --save "" --appendonly no
security_opt:
- no-new-privileges:true
restoretest-nextcloud:
# Gleicher Image-Digest wie apps/nextcloud/docker-compose.yml.
image: nextcloud:33.0.4-apache@sha256:caa40b8beaf0057ac213d8dfc515c36ce64f7a8f0825b6a287e6f7cf2f4a095d
container_name: restoretest-nextcloud
restart: "no"
depends_on:
restoretest-nextcloud-postgres:
condition: service_healthy
restoretest-nextcloud-redis:
condition: service_started
environment:
TZ: Europe/Berlin
POSTGRES_HOST: restoretest-nextcloud-postgres
POSTGRES_DB: nextcloud
POSTGRES_USER: nextcloud
POSTGRES_PASSWORD: restoretest-nextcloud-db
REDIS_HOST: restoretest-nextcloud-redis
NEXTCLOUD_ADMIN_USER: restoretest-admin
NEXTCLOUD_ADMIN_PASSWORD: restoretest-nextcloud-admin-pass
NEXTCLOUD_DATA_DIR: /var/www/html/data
# Bewusst keine Trusted-Domain/Proxy-Konfiguration: Smoke prueft
# nur localhost-HTTP, keine Traefik-Route.
ports:
# nur 127.0.0.1, keine Public-Route, keine Traefik-Labels
- "127.0.0.1:18180:80"
volumes:
# Restore-Lab-Pfade: alles isoliert, keine produktiven Mounts.
- /mnt/user/backups/restore-lab/nextcloud/html:/var/www/html
- /mnt/user/backups/restore-lab/nextcloud/data:/var/www/html/data
# KEIN no-new-privileges fuer den Smoke-Test-Container.
# Der Nextcloud-Entrypoint fuehrt intern chown/chmod auf /var/www/html
# und /var/www/html/data aus. Auf Unraid (FUSE/shfs) ignoriert das
# Host-Dateisystem chown-Aufrufe von aussen, deshalb muss der
# Container-Entrypoint die Rechte selbst setzen koennen. Im isolierten
# Smoke-Kontext (127.0.0.1, kein Traefik, Wegwerf-Daten) ist das
# vertretbar. Test-Postgres und Test-Redis behalten no-new-privileges.
ops/restore-tests/nextcloud-restore-test.sh
-327
View File
@@ -1,327 +0,0 @@
#!/bin/bash
set -euo pipefail
# Nextcloud Restore Smoke Test
#
# Nicht-destruktiver Restore-Smoke-Test fuer Nextcloud.
#
# Was dieser Smoke nachweist:
# - Nextcloud-HTML und -Datenpfade koennen aus dem Borg-Archiv extrahiert werden
# - nextcloud.dump kann in eine isolierte Test-Postgres importiert werden
# - Nextcloud startet gegen die restaurierten Daten + Test-Redis und antwortet
# auf HTTP
# - occ status zeigt maintenance:mode = false
#
# Besonderheiten gegenueber den anderen Restore-Tests:
# - Nextcloud hat eine eigene Postgres (nicht shared), mit eigener DB-Rolle
# - Nextcloud nutzt eine eigene Redis-Instanz (Snapshot-Persistenz, kein Passwort)
# - occ maintenance:mode und die Rolle oc_admin sind im DR-Fall relevant;
# im Smoke pruefen wir occ status nach dem Boot
# - Produktive Secrets (admin_user, admin_password, postgres_password) werden
# durch Wegwerf-Werte im Test-Compose ersetzt
#
# Produktive Nextcloud-Container, produktive Postgres-DB, produktive Secrets,
# produktive Nutzdaten unter /mnt/user/documents/nextcloud-data und
# produktiver Traefik-Eintrag werden NICHT angefasst.
SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
. "$SCRIPT_DIR/common.sh"
WHATIF=0
KEEP_DATA=0
for arg in "$@"; do
case "$arg" in
--what-if) WHATIF=1 ;;
--keep-data) KEEP_DATA=1 ;;
*) echo "Unknown argument: $arg" >&2; exit 1 ;;
esac
done
RESTORE_ROOT="/mnt/user/backups/restore-lab/nextcloud"
REPORT_ROOT="/mnt/user/backups/restore-reports"
EXTRACT_DIR="$BORG_RESTORE_HOST_ROOT/nextcloud-extract"
COMPOSE_FILE="$SCRIPT_DIR/nextcloud-compose.test.yml"
REPORT_FILE="$REPORT_ROOT/nextcloud-$(date +%F).md"
if [ "$WHATIF" -eq 1 ]; then
cat <<EOF
Nextcloud restore test
Mode: WhatIf
RestoreRoot: $RESTORE_ROOT
ReportRoot: $REPORT_ROOT
Expected Borg source paths:
- local/appdata/nextcloud/html (aus Borg-Archiv)
Host source paths:
- /mnt/user/backups/borg/dumps/latest/nextcloud.dump (vom Host, taeglich frisch)
Planned isolation:
- Test-Postgres: postgres:18.4 mit Wegwerf-Credentials
- Test-Redis: redis:8.8.0-alpine (rebuildbar, kein Restore)
- Test-Nextcloud: nextcloud:33.0.4-apache (Image-Pin wie Produktion)
- Wegwerf-Admin-Credentials im Test-Compose
- Produktive Secrets und Nutzdaten werden NICHT gemountet
- Test endpoint: 127.0.0.1:18180 (no Traefik, no public domain)
Smoke-Test:
- pg_restore -> nextcloud.dump
- HTTP 200/302/3xx von 127.0.0.1:18180
- occ status: maintenance=false
EOF
exit 0
fi
require_cmd docker
require_cmd curl
require_path "$BORG_PASSPHRASE_FILE_DEFAULT"
require_path "$COMPOSE_FILE"
RESTORE_SUCCESS=0
cleanup() {
cleanup_compose "$COMPOSE_FILE"
if [ "$RESTORE_SUCCESS" -ne 1 ]; then
preserve_on_failure "nextcloud" "$RESTORE_ROOT"
rm -rf "$EXTRACT_DIR"
return
fi
if [ "$KEEP_DATA" -ne 1 ]; then
rm -rf "$RESTORE_ROOT"
fi
rm -rf "$EXTRACT_DIR"
}
trap cleanup EXIT
rm -rf "$EXTRACT_DIR" "$RESTORE_ROOT"
mkdir -p "$RESTORE_ROOT/html" "$RESTORE_ROOT/data" "$RESTORE_ROOT/postgres" "$RESTORE_ROOT/dumps/latest"
archive="$(latest_archive_name)"
repo="$(borg_repo_url)"
if [ -z "$archive" ] || [ -z "$repo" ]; then
echo "Could not resolve Borg repo/archive from borg-ui database" >&2
exit 1
fi
# Stufe 1: Nextcloud-App-Pfade aus Borg, Dump vom Host.
# HTML (App-Code + config) kommt aus dem Borg-Archiv.
# Der Dump liegt frisch auf dem Host unter /mnt/user/backups/borg/dumps/latest/
# (wird taeglich von pre-backup-dumps.sh erzeugt und dann in Borg gesichert).
# Der Borg-Extract des Dumps wuerde dieselbe Datei liefern, braucht aber eine
# eigene Remote-Roundtrip-Zeit; wir nutzen die Host-Kopie direkt.
DUMP_HOST_PATH="/mnt/user/backups/borg/dumps/latest/nextcloud.dump"
borg_extract "/restore/nextcloud-extract" \
"local/appdata/nextcloud/html"
if [ ! -d "$EXTRACT_DIR/local/appdata/nextcloud/html" ]; then
echo "Nextcloud html path missing in Borg archive" >&2
exit 1
fi
if [ ! -f "$DUMP_HOST_PATH" ]; then
echo "nextcloud.dump missing on host at $DUMP_HOST_PATH" >&2
exit 1
fi
# App-Code + Config ins Restore-Lab verschieben
cp -a "$EXTRACT_DIR/local/appdata/nextcloud/html/." "$RESTORE_ROOT/html/"
cp "$DUMP_HOST_PATH" "$RESTORE_ROOT/dumps/latest/nextcloud.dump"
# Nextcloud braucht einen beschreibbaren data-Pfad, auch wenn er leer ist.
# Im Restore-Lab ist das /mnt/user/backups/restore-lab/nextcloud/data.
mkdir -p "$RESTORE_ROOT/data"
# Nextcloud prueft auf einen Marker `.ncdata` mit dem festen Inhalt
# "# Nextcloud data directory" und blockt sonst mit "Your data directory
# is invalid" (HTTP 503). Produktiv liegt der Marker unter
# /mnt/user/documents/nextcloud-data/.ncdata; der Smoke mountet diesen
# Pfad bewusst nicht, also legen wir den Marker hier an. Das ist die
# in der Nextcloud-Doku vorgesehene Form.
echo "# Nextcloud data directory" > "$RESTORE_ROOT/data/.ncdata"
# Unraid (FUSE/shfs) ignoriert chown auf User-Shares. Stattdessen setzen
# wir die Dateien auf world-writable, damit der Nextcloud-Entrypoint
# (der als root startet und intern auf www-data wechselt) die Dateien
# lesen und beschreiben kann. Im isolierten Smoke-Kontext vertretbar.
chmod -R a+rwX "$RESTORE_ROOT/html" "$RESTORE_ROOT/data"
# Falls config.php einen anderen dbuser als das Test-Compose hat, patchen
# wir die DB-Zugangsdaten in der restaurierten config.php fuer den Test.
CONFIG_PHP="$RESTORE_ROOT/html/config/config.php"
if [ -f "$CONFIG_PHP" ]; then
# Backup der Originalkonfig fuer Diagnose
cp "$CONFIG_PHP" "$RESTORE_ROOT/html/config/config.php.original"
# DB-Credentials auf die Test-Werte umbiegen. Nextcloud config.php
# ist PHP; wir patchen die relevanten Zeilen per sed.
sed -i \
-e "s|'dbhost'.*|'dbhost' => 'restoretest-nextcloud-postgres',|" \
-e "s|'dbuser'.*|'dbuser' => 'nextcloud',|" \
-e "s|'dbpassword'.*|'dbpassword' => 'restoretest-nextcloud-db',|" \
-e "s|'dbname'.*|'dbname' => 'nextcloud',|" \
-e "s|'dbport'.*|'dbport' => '',|" \
"$CONFIG_PHP"
# Redis-Host patchen. Die config.php hat ein verschachteltes Array:
# 'redis' => array( 'host' => 'nextcloud-redis', ... )
# Wir ersetzen nur den Host-Wert innerhalb des redis-Blocks.
sed -i "s|'host' => 'nextcloud-redis'|'host' => 'restoretest-nextcloud-redis'|g" "$CONFIG_PHP"
# Zwei Patches in der config.php, beides per PHP-Code-Injection am Ende:
#
# 1. trusted_domains: 127.0.0.1 hinzufuegen, damit der Smoke-Endpunkt
# akzeptiert wird. Nextcloud prueft trusted_domains und blockt sonst
# mit "Access through untrusted domain" (503).
#
# 2. check_data_directory_permissions: false. Hintergrund: Nextcloud
# (OC_Util::checkDataDirectoryPermissions) prueft beim HTTP-Request, ob
# die data-Dir-Permissions in der letzten Stelle 0 sind. Falls nicht,
# versucht es als www-data ein chmod(0770). Auf Unraid (shfs/FUSE)
# lehnt das Filesystem chmod von Non-Root ab, also kann der Container
# das nie korrigieren -> Nextcloud meldet "data directory readable by
# other people" -> HTTP 503. Im isolierten Smoke-Kontext (Wegwerf-
# Daten, kein Public, kein Traefik) ist das Aushebeln dieses Checks
# sauber dokumentiert vorgesehen. Produktiv bleibt der Check an.
php -r "
\$f = '$CONFIG_PHP';
\$c = file_get_contents(\$f);
if (strpos(\$c, \"'127.0.0.1'\") === false || strpos(\$c, 'check_data_directory_permissions') === false) {
include \$f;
if (!in_array('127.0.0.1', \$CONFIG['trusted_domains'])) {
\$CONFIG['trusted_domains'][] = '127.0.0.1';
}
\$CONFIG['check_data_directory_permissions'] = false;
\$out = '<?php' . PHP_EOL . '\$CONFIG = ' . var_export(\$CONFIG, true) . ';' . PHP_EOL;
file_put_contents(\$f, \$out);
}
" 2>/dev/null || {
# Fallback: wenn php nicht auf dem Host ist, per sed versuchen
if ! grep -q "127.0.0.1" "$CONFIG_PHP"; then
sed -i "/'trusted_domains'/,/^ )/s|^ )| 99 => '127.0.0.1',\n )|" "$CONFIG_PHP" || true
fi
if ! grep -q "check_data_directory_permissions" "$CONFIG_PHP"; then
sed -i "s|^);| 'check_data_directory_permissions' => false,\n);|" "$CONFIG_PHP" || true
fi
}
config_patched="ok"
else
config_patched="no config.php found"
fi
# Stufe 2: Test-Postgres + Test-Redis hochfahren
docker compose -f "$COMPOSE_FILE" up -d restoretest-nextcloud-postgres restoretest-nextcloud-redis >/dev/null
until docker exec restoretest-nextcloud-postgres pg_isready -U nextcloud -d nextcloud >/dev/null 2>&1; do
sleep 2
done
# Stufe 3: Dump einspielen (mit Retry wie bei Paperless/Immich)
restore_ok=0
for attempt in $(seq 1 12); do
if docker exec -i restoretest-nextcloud-postgres \
pg_restore -U nextcloud -d nextcloud --clean --if-exists --no-owner --no-privileges \
< "$RESTORE_ROOT/dumps/latest/nextcloud.dump" 2>/tmp/nextcloud-pg-restore.err; then
restore_ok=1
break
fi
if grep -qiE "starting up|shutting down|connection refused|database .* does not exist" /tmp/nextcloud-pg-restore.err; then
sleep 5
continue
fi
# pg_restore mit --clean erzeugt "does not exist"-Warnungen fuer nicht vorhandene
# Objekte beim ersten Import. Diese sind erwartbar und kein echter Fehler.
# Wir pruefen auf harte Fehler.
if grep -qiE "FATAL|PANIC" /tmp/nextcloud-pg-restore.err; then
cat /tmp/nextcloud-pg-restore.err >&2
exit 1
fi
restore_ok=1
break
done
if [ "$restore_ok" -ne 1 ]; then
cat /tmp/nextcloud-pg-restore.err >&2
exit 1
fi
# Stufe 4: Nextcloud starten
docker compose -f "$COMPOSE_FILE" up -d restoretest-nextcloud >/dev/null
# Nextcloud braucht beim ersten Start mit existierender config.php einige
# Sekunden fuer DB-Migrations-Checks. Wir geben bis zu 180s.
http_status=""
for _ in $(seq 1 90); do
http_status="$(curl -s -o /tmp/nextcloud-body.html -w '%{http_code}' \
-L http://127.0.0.1:18180/status.php || true)"
if [ "$http_status" = "200" ]; then
break
fi
sleep 2
done
if [ "$http_status" != "200" ]; then
echo "Nextcloud HTTP smoke failed: status=$http_status" >&2
docker logs --tail 120 restoretest-nextcloud >&2 || true
exit 1
fi
# Stufe 5: occ status pruefen (maintenance mode)
occ_output="$(docker exec -u www-data restoretest-nextcloud php occ status --output=json 2>/dev/null || echo '{}')"
maintenance="$(echo "$occ_output" | grep -o '"maintenance":[a-z]*' | head -1 | cut -d: -f2)"
if [ -z "$maintenance" ]; then
maintenance="unknown"
fi
# DB-Tabellen-Count als fachlicher Sanity-Check
table_count="$(docker exec restoretest-nextcloud-postgres \
psql -U nextcloud -d nextcloud -tAc \
"SELECT count(*) FROM information_schema.tables WHERE table_schema='public';" \
2>/dev/null | tr -d '[:space:]' || echo "n/a")"
write_report "$REPORT_FILE" <<EOF
# Nextcloud Restore Test Report - $(date +%F)
- Service: \`nextcloud\`
- Source repo: \`$repo\`
- Archive: \`$archive\`
- Restore root: \`$RESTORE_ROOT\`
- Test containers:
- \`restoretest-nextcloud\`
- \`restoretest-nextcloud-postgres\`
- \`restoretest-nextcloud-redis\`
- Test endpoint: \`http://127.0.0.1:18180/status.php\`
- Result: \`SUCCESS\`
## Checks
- Borg extract of html: \`ok\`
- Host dump copy: \`ok\`
- config.php patched for test DB: \`$config_patched\`
- Dump import into isolated Postgres: \`ok\`
- HTTP status from /status.php: \`$http_status\`
- occ status maintenance: \`$maintenance\`
- Public table count in test DB: \`$table_count\`
## Scope
Dieser Smoke prueft: Borg-Restore von App-Code + Config + DB-Dump,
Dump-Import in isoliertes Test-Postgres, Nextcloud-Boot mit restaurierter
config.php (DB-Credentials auf Test-Werte gepatcht), HTTP-Status und
occ-Maintenance-Status.
Bewusst NICHT Teil des Smokes:
- Voller Restore der Nutzdaten unter /mnt/user/documents/nextcloud-data
(zu gross fuer regelmaessigen Smoke; Pfad-Existenz im Archiv kann
separat geprueft werden)
- Produktive Secrets (admin_user/password, postgres_password)
- Traefik-Route und produktive Domain cloud.kaleschke.info
- occ maintenance:mode Toggle (der Test-Restore braucht keinen
vorhergehenden maintenance:mode --on, weil er gegen einen Dump laeuft)
## Notes
- Test ran without Traefik and without the productive domain.
- Productive Nextcloud secrets were NOT mounted; test uses throwaway credentials.
- Productive user data under /mnt/user/documents/nextcloud-data was NOT mounted.
- config.php.original preserved for diagnosis.
- Test data was cleaned after success: \`$([ "$KEEP_DATA" -eq 1 ] && echo no || echo yes)\`
EOF
RESTORE_SUCCESS=1
echo "Nextcloud restore test ok -> $REPORT_FILE"
ops/restore-tests/paperless-restore-test.sh
+1 -31
View File
@@ -41,14 +41,8 @@ require_cmd curl
require_path "$BORG_PASSPHRASE_FILE_DEFAULT"
require_path "$COMPOSE_FILE"
RESTORE_SUCCESS=0
cleanup() {
cleanup_compose "$COMPOSE_FILE"
if [ "$RESTORE_SUCCESS" -ne 1 ]; then
preserve_on_failure "paperless" "$RESTORE_ROOT"
rm -rf "$EXTRACT_DIR"
return
fi
if [ "$KEEP_DATA" -ne 1 ]; then
rm -rf "$RESTORE_ROOT"
fi
@@ -76,30 +70,7 @@ mv "$EXTRACT_DIR/local/borg-dumps/latest/postgresql17-paperless.dump" "$RESTORE_
docker compose -f "$COMPOSE_FILE" up -d restoretest-paperless-postgres restoretest-paperless-redis >/dev/null
until docker exec restoretest-paperless-postgres pg_isready -U paperless -d paperless >/dev/null 2>&1; do sleep 2; done
# Postgres-Entrypoint kann kurz nach "ready" noch vom Init- auf den finalen
# Server wechseln. pg_restore toleriert transiente Start-/Shutdown-Fehler und
# retried; harte Fehler (z. B. Dump-Korruption) brechen wie bisher ab.
restore_ok=0
for attempt in $(seq 1 12); do
if docker exec -i restoretest-paperless-postgres \
pg_restore -U paperless -d paperless --clean --if-exists --no-owner --no-privileges \
< "$RESTORE_ROOT/dumps/latest/postgresql17-paperless.dump" 2>/tmp/paperless-pg-restore.err; then
restore_ok=1
break
fi
if grep -qiE "starting up|shutting down|connection refused|database .* does not exist" /tmp/paperless-pg-restore.err; then
sleep 5
continue
fi
cat /tmp/paperless-pg-restore.err >&2
exit 1
done
if [ "$restore_ok" -ne 1 ]; then
cat /tmp/paperless-pg-restore.err >&2
exit 1
fi
cat "$RESTORE_ROOT/dumps/latest/postgresql17-paperless.dump" | docker exec -i restoretest-paperless-postgres pg_restore -U paperless -d paperless --clean --if-exists --no-owner --no-privileges
docker compose -f "$COMPOSE_FILE" up -d restoretest-paperless >/dev/null
sleep 12
@@ -139,5 +110,4 @@ write_report "$REPORT_FILE" <<EOF
- Test data was cleaned after success: \`$([ "$KEEP_DATA" -eq 1 ] && echo no || echo yes)\`
EOF
RESTORE_SUCCESS=1
echo "Paperless restore test ok -> $REPORT_FILE"
ops/restore-tests/paperless-runbook.md
+3 -3
View File
@@ -66,7 +66,7 @@ mv /mnt/user/backups/restore-lab/paperless/local/paperless/consume /mnt/user/bac
3. Test-Postgres und Test-Redis starten
```bash
docker compose -f /mnt/user/services/homelab-infra/ops/restore-tests/paperless-compose.test.yml up -d restoretest-paperless-postgres restoretest-paperless-redis
docker compose -f /mnt/user/services/homelab/ops/restore-tests/paperless-compose.test.yml up -d restoretest-paperless-postgres restoretest-paperless-redis
```
4. Dump in Test-Postgres importieren
@@ -78,7 +78,7 @@ docker exec -i restoretest-paperless-postgres pg_restore -U paperless -d paperle
5. Testinstanz starten
```bash
docker compose -f /mnt/user/services/homelab-infra/ops/restore-tests/paperless-compose.test.yml up -d restoretest-paperless
docker compose -f /mnt/user/services/homelab/ops/restore-tests/paperless-compose.test.yml up -d restoretest-paperless
```
6. Smoke-Test
@@ -98,7 +98,7 @@ Minimal erfolgreich:
7. Testcontainer wieder stoppen
```bash
docker compose -f /mnt/user/services/homelab-infra/ops/restore-tests/paperless-compose.test.yml down
docker compose -f /mnt/user/services/homelab/ops/restore-tests/paperless-compose.test.yml down
```
8. Testdaten nach erfolgreichem Lauf bereinigen
ops/restore-tests/redis-compose.test.yml
-16
View File
@@ -1,16 +0,0 @@
services:
restoretest-redis:
image: redis:8.8.0-alpine@sha256:09160599abd229764c0fb44cb6be640294e1d360a54b19985ab4843dcf2d90f1
container_name: restoretest-redis
restart: "no"
command:
- sh
- -c
- exec redis-server --appendonly yes --requirepass "$$(cat /run/secrets/redis_password)"
ports:
- "127.0.0.1:16379:6379/tcp"
volumes:
- /mnt/user/backups/restore-lab/redis/data:/data
- /mnt/user/backups/restore-lab/redis/secrets/redis_password.txt:/run/secrets/redis_password:ro
security_opt:
- no-new-privileges:true
ops/restore-tests/redis-restore-test.sh
-152
View File
@@ -1,152 +0,0 @@
#!/bin/bash
set -euo pipefail
# Redis 8 Restore Smoke Test
#
# Scope:
# - Restore aus dem dokumentierten shared-redis-pre-redis8-Artefakt
# - Start einer isolierten Redis-8-Testinstanz auf localhost:16379
# - PING, INFO server und DBSIZE ohne Ausgabe des Passworts
SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
. "$SCRIPT_DIR/common.sh"
WHATIF=0
KEEP_DATA=0
for arg in "$@"; do
case "$arg" in
--what-if) WHATIF=1 ;;
--keep-data) KEEP_DATA=1 ;;
*) echo "Unknown argument: $arg" >&2; exit 1 ;;
esac
done
RESTORE_ROOT="/mnt/user/backups/restore-lab/redis"
REPORT_ROOT="/mnt/user/backups/restore-reports"
PRE_CUTOVER_ROOT="/mnt/user/backups/borg/dumps/latest"
SECRET_FILE="/mnt/user/appdata/secrets/redis_password.txt"
COMPOSE_FILE="$SCRIPT_DIR/redis-compose.test.yml"
REPORT_FILE="$REPORT_ROOT/redis-$(date +%F).md"
if [ "$WHATIF" -eq 1 ]; then
cat <<EOF
Redis 8 restore test
Mode: WhatIf
RestoreRoot: $RESTORE_ROOT
Restore source: newest $PRE_CUTOVER_ROOT/shared-redis-pre-redis8-*
Secret source: $SECRET_FILE
Test endpoint: 127.0.0.1:16379
Scope: Data restore + isolated Redis boot + PING/INFO/DBSIZE smoke
EOF
exit 0
fi
require_cmd docker
require_path "$PRE_CUTOVER_ROOT"
require_path "$SECRET_FILE"
require_path "$COMPOSE_FILE"
RESTORE_SUCCESS=0
cleanup() {
cleanup_compose "$COMPOSE_FILE"
if [ "$RESTORE_SUCCESS" -ne 1 ]; then
preserve_on_failure "redis" "$RESTORE_ROOT"
return
fi
if [ "$KEEP_DATA" -ne 1 ]; then
rm -rf "$RESTORE_ROOT"
fi
}
trap cleanup EXIT
rm -rf "$RESTORE_ROOT"
mkdir -p "$RESTORE_ROOT/data" "$RESTORE_ROOT/secrets"
restore_source="$(find "$PRE_CUTOVER_ROOT" -maxdepth 1 -type d -name 'shared-redis-pre-redis8-*' | sort | tail -1)"
if [ -z "$restore_source" ]; then
echo "No shared-redis-pre-redis8-* restore source found under $PRE_CUTOVER_ROOT" >&2
exit 1
fi
if [ ! -d "$restore_source" ]; then
echo "Redis restore source is not a directory: $restore_source" >&2
exit 1
fi
cp -a "$restore_source/." "$RESTORE_ROOT/data/"
cp "$SECRET_FILE" "$RESTORE_ROOT/secrets/redis_password.txt"
chmod -R a+rwX "$RESTORE_ROOT/data"
chmod a+r "$RESTORE_ROOT/secrets/redis_password.txt"
data_files="$(find "$RESTORE_ROOT/data" -type f | wc -l | tr -d ' ')"
data_bytes="$(du -sb "$RESTORE_ROOT/data" | awk '{print $1}')"
docker compose -f "$COMPOSE_FILE" up -d restoretest-redis >/dev/null
ping_result=""
for _ in $(seq 1 60); do
ping_result="$(docker exec restoretest-redis sh -lc \
'p=$(cat /run/secrets/redis_password); redis-cli -a "$p" --no-auth-warning PING' 2>/dev/null || true)"
if [ "$ping_result" = "PONG" ]; then
break
fi
sleep 1
done
if [ "$ping_result" != "PONG" ]; then
echo "Redis PING smoke failed: $ping_result" >&2
docker logs --tail 80 restoretest-redis >&2 || true
exit 1
fi
redis_version="$(docker exec restoretest-redis sh -lc \
'p=$(cat /run/secrets/redis_password); redis-cli -a "$p" --no-auth-warning INFO server | awk -F: "/^redis_version:/ {gsub(/\r/, \"\", \$2); print \$2}"')"
dbsize="$(docker exec restoretest-redis sh -lc \
'p=$(cat /run/secrets/redis_password); redis-cli -a "$p" --no-auth-warning DBSIZE' | tr -d '\r')"
aof_enabled="$(docker exec restoretest-redis sh -lc \
'p=$(cat /run/secrets/redis_password); redis-cli -a "$p" --no-auth-warning INFO persistence | awk -F: "/^aof_enabled:/ {gsub(/\r/, \"\", \$2); print \$2}"')"
case "$redis_version" in
8.*) ;;
*)
echo "Unexpected Redis version: $redis_version" >&2
exit 1
;;
esac
if [ "${dbsize:-0}" -lt 1 ]; then
echo "Unexpected Redis DBSIZE: $dbsize" >&2
exit 1
fi
write_report "$REPORT_FILE" <<EOF
# Redis 8 Restore Test Report - $(date +%F)
- Service: \`redis\`
- Restore source: \`$restore_source\`
- Restore root: \`$RESTORE_ROOT\`
- Test container: \`restoretest-redis\`
- Test endpoint: \`127.0.0.1:16379\`
- Result: \`SUCCESS\`
## Checks
- Data restore from pre-Redis8 artifact: \`ok\`
- Secret file mounted from host secret path: \`ok\`
- Restored data files: \`$data_files\`
- Restored data bytes: \`$data_bytes\`
- PING: \`$ping_result\`
- Redis version: \`$redis_version\`
- AOF enabled: \`$aof_enabled\`
- DBSIZE: \`$dbsize\`
## Notes
- Productive Redis port 6379 and productive data path were NOT used.
- Test port was bound to localhost only: \`127.0.0.1:16379\`.
- Redis password value was used from the restored secret file and was not printed.
- Test data was cleaned after success: \`$([ "$KEEP_DATA" -eq 1 ] && echo no || echo yes)\`
EOF
RESTORE_SUCCESS=1
echo "Redis restore test ok -> $REPORT_FILE"
ops/restore-tests/run-restore-checks.sh
+1 -64
View File
@@ -10,9 +10,6 @@ case "$MODE" in
freshness)
exec "$SCRIPT_DIR/check-restore-freshness.sh"
;;
freshness-negative)
exec "$SCRIPT_DIR/negative-freshness-alert-test.sh"
;;
vaultwarden)
if [ "$WHATIF" = "--what-if" ]; then
exec "$SCRIPT_DIR/vaultwarden-restore-test.sh" --what-if
@@ -37,68 +34,8 @@ case "$MODE" in
fi
exec "$SCRIPT_DIR/immich-restore-test.sh"
;;
authelia)
if [ "$WHATIF" = "--what-if" ]; then
exec "$SCRIPT_DIR/authelia-restore-test.sh" --what-if
fi
exec "$SCRIPT_DIR/authelia-restore-test.sh"
;;
adguard)
if [ "$WHATIF" = "--what-if" ]; then
exec "$SCRIPT_DIR/adguard-restore-test.sh" --what-if
fi
exec "$SCRIPT_DIR/adguard-restore-test.sh"
;;
redis)
if [ "$WHATIF" = "--what-if" ]; then
exec "$SCRIPT_DIR/redis-restore-test.sh" --what-if
fi
exec "$SCRIPT_DIR/redis-restore-test.sh"
;;
nextcloud)
if [ "$WHATIF" = "--what-if" ]; then
exec "$SCRIPT_DIR/nextcloud-restore-test.sh" --what-if
fi
exec "$SCRIPT_DIR/nextcloud-restore-test.sh"
;;
komodo-bootstrap)
if [ "$WHATIF" = "--what-if" ]; then
exec "$SCRIPT_DIR/komodo-bootstrap-test.sh" --what-if
fi
exec "$SCRIPT_DIR/komodo-bootstrap-test.sh"
;;
komodo-mongo-restore)
if [ "$WHATIF" = "--what-if" ]; then
exec "$SCRIPT_DIR/komodo-mongo-restore-test.sh" --what-if
fi
exec "$SCRIPT_DIR/komodo-mongo-restore-test.sh"
;;
traefik)
if [ "$WHATIF" = "--what-if" ]; then
exec "$SCRIPT_DIR/traefik-restore-test.sh" --what-if
fi
exec "$SCRIPT_DIR/traefik-restore-test.sh"
;;
mailarchiver)
if [ "$WHATIF" = "--what-if" ]; then
exec "$SCRIPT_DIR/mailarchiver-restore-test.sh" --what-if
fi
exec "$SCRIPT_DIR/mailarchiver-restore-test.sh"
;;
mealie)
if [ "$WHATIF" = "--what-if" ]; then
exec "$SCRIPT_DIR/mealie-restore-test.sh" --what-if
fi
exec "$SCRIPT_DIR/mealie-restore-test.sh"
;;
shared-pg-cluster)
if [ "$WHATIF" = "--what-if" ]; then
exec "$SCRIPT_DIR/shared-pg-cluster-restore-test.sh" --what-if
fi
exec "$SCRIPT_DIR/shared-pg-cluster-restore-test.sh"
;;
*)
echo "Usage: $0 {freshness|freshness-negative|vaultwarden|gitea|paperless|immich|authelia|adguard|redis|nextcloud|komodo-bootstrap|komodo-mongo-restore|traefik|mailarchiver|mealie|shared-pg-cluster} [--what-if]" >&2
echo "Usage: $0 {freshness|vaultwarden|gitea|paperless|immich} [--what-if]" >&2
exit 1
;;
esac
ops/restore-tests/run-restore-job-with-ntfy.sh
+4 -9
View File
@@ -7,29 +7,24 @@ SUCCESS_TOPIC="${2:-${RESTORE_SUCCESS_TOPIC:-homelab-info}}"
FAILURE_TOPIC="${RESTORE_FAILURE_TOPIC:-homelab-alerts}"
if [ -z "$MODE" ]; then
echo "Usage: $0 <freshness|vaultwarden|gitea|paperless|immich|authelia|nextcloud|komodo-bootstrap> [success_topic]" >&2
echo "Usage: $0 <freshness|vaultwarden|gitea|paperless|immich> [success_topic]" >&2
exit 1
fi
REPORT_ROOT="/mnt/user/backups/restore-reports"
REPORT_FILE="$REPORT_ROOT/${MODE}-$(date +%F).md"
WRAPPER_LOG="$REPORT_ROOT/_wrapper-${MODE}-$(date +%F).log"
mkdir -p "$REPORT_ROOT"
echo "Running restore job: $MODE"
echo "Inner report (written by restore script): $REPORT_FILE"
echo "Wrapper log (stdout/stderr of dispatcher): $WRAPPER_LOG"
echo "Report target: $REPORT_FILE"
# Der Restore-Job schreibt seinen Markdown-Report selbst nach $REPORT_FILE.
# Wir leiten stdout/stderr in eine separate Wrapper-Log-Datei, damit hier
# kein zweiter Schreiber denselben Pfad ueberschreibt.
if "$SCRIPT_DIR/run-restore-checks.sh" "$MODE" >"$WRAPPER_LOG" 2>&1; then
if "$SCRIPT_DIR/run-restore-checks.sh" "$MODE" > "$REPORT_FILE"; then
echo "Restore job succeeded, sending ntfy..."
"$SCRIPT_DIR/send-ntfy.sh" "$SUCCESS_TOPIC" "Restore job ok: $MODE" "Restore job succeeded. Report: $REPORT_FILE" default || true
echo "Done"
else
echo "Restore job failed, sending ntfy..."
"$SCRIPT_DIR/send-ntfy.sh" "$FAILURE_TOPIC" "Restore job failed: $MODE" "Restore job failed. Wrapper log: $WRAPPER_LOG (Report if written: $REPORT_FILE)" high || true
"$SCRIPT_DIR/send-ntfy.sh" "$FAILURE_TOPIC" "Restore job failed: $MODE" "Restore job failed. Report: $REPORT_FILE" high || true
exit 1
fi
ops/restore-tests/schedule.md
+12 -24
View File
@@ -28,8 +28,6 @@ Quartalsweise:
- Restore-/DR-Sanity-Check
- `immich` Restore-Smoke-Test (DB + UI, ohne produktive Foto-Mounts; Erstlauf 2026-05-27 erfolgreich)
- `adguard` Restore-Smoke-Test (Config + HTTP/DNS, nach DNS-Aenderungen auch ausserhalb des Quartals)
- `redis` Restore-Smoke-Test (Pre-Cutover-Artefakt + Redis 8, vor/nach Major-Aenderungen auch ausserhalb des Quartals)
- pruefen:
- Restore-Lab-Struktur
- Reports
@@ -46,10 +44,7 @@ Quartals-Belegung:
| Q4 | `vaultwarden` oder `gitea` | Externe Abhaengigkeiten, Hetzner, GitHub-Mirror |
Bestaetigte Mini-Restores: Vaultwarden, Gitea und Paperless am 2026-05-07;
Immich am 2026-05-27; Paperless erneut am 2026-05-31; Authelia am
2026-06-03 (Config-Smoke ohne produktiven Dump-Restore); AdGuard Home am
2026-06-06 (Config + HTTP/DNS-Smoke); Redis 8 am 2026-06-06
(Pre-Cutover-Artefakt + PING/INFO/DBSIZE-Smoke).
Immich am 2026-05-27; Paperless erneut am 2026-05-31.
## Konkreter Kalender
@@ -61,8 +56,6 @@ Immich am 2026-05-27; Paperless erneut am 2026-05-31; Authelia am
- `gitea`
- Jeden 2. Samstag in ungeraden Monaten, 08:00:
- `paperless`
- Jeden 2. Samstag in geraden Monaten, 07:30:
- `authelia`
- Jeden 1. des Monats, 09:00:
- `monthly-random-restore.sh`
- Quartalsweise am 1. Werktag des Quartals:
@@ -72,29 +65,24 @@ Immich am 2026-05-27; Paperless erneut am 2026-05-31; Authelia am
## Unraid User Scripts Cron
Vixie-Cron (Unraid) verknuepft `day-of-month` und `day-of-week` mit **OR**, sobald beide gesetzt sind. "n-ter Samstag im Monat" laesst sich deshalb nicht direkt im Cron-Ausdruck ausdruecken. Wir triggern stattdessen an **jedem** Samstag/Sonntag und filtern den Monatstag im User-Script per Shell-Guard.
| Script | Cron | Shell-Guard (zusaetzlich) | Bedeutung |
|---|---|---|---|
| `restore-freshness-weekly` | `30 6 * * 1` | - | jeden Montag 06:30 |
| `restore-vaultwarden-monthly` | `0 7 * * 6` | `[ "$(date +%-d)" -le 7 ]` | erster Samstag im Monat 07:00 |
| `restore-gitea-monthly` | `15 7 * * 6` | `d=$(date +%-d); [ "$d" -ge 15 ] && [ "$d" -le 21 ]` | dritter Samstag im Monat 07:15 |
| `restore-paperless-bimonthly` | `0 8 * * 6` | `m=$(date +%-m); d=$(date +%-d); case "$m" in 1\|3\|5\|7\|9\|11) [ "$d" -ge 8 ] && [ "$d" -le 14 ];; *) false;; esac` | zweiter Samstag in ungeraden Monaten 08:00 |
| `restore-authelia-bimonthly` | `30 7 * * 6` | `m=$(date +%-m); d=$(date +%-d); case "$m" in 2\|4\|6\|8\|10\|12) [ "$d" -ge 8 ] && [ "$d" -le 14 ];; *) false;; esac` | zweiter Samstag in geraden Monaten 07:30 |
| `restore-immich-quarterly` | `30 8 * * 0` | `m=$(date +%-m); d=$(date +%-d); case "$m" in 2\|5\|8\|11) [ "$d" -ge 8 ] && [ "$d" -le 14 ];; *) false;; esac` | zweiter Sonntag in Feb/Mai/Aug/Nov 08:30 |
| `monthly-random-restore` | `0 9 1 * *` | - | erster Kalendertag im Monat 09:00 |
**Warum so**: ein frueheres Schema wie `0 7 1-7 * 6` haette in Vixie-Cron die OR-Semantik ausgeloest und an jedem Tag 1-7 zusaetzlich zu jedem Samstag gefeuert (~11 Laeufe statt 1 pro Monat). Die obige Trennung Cron-Trigger + Shell-Guard ist die einzige robuste Loesung in Standard-Cron.
| Script | Cron | Bedeutung |
|---|---|---|
| `restore-freshness-weekly` | `30 6 * * 1` | jeden Montag 06:30 |
| `restore-vaultwarden-monthly` | `0 7 1-7 * 6` | erster Samstag im Monat 07:00 |
| `restore-gitea-monthly` | `15 7 15-21 * 6` | dritter Samstag im Monat 07:15 |
| `restore-paperless-bimonthly` | `0 8 8-14 1,3,5,7,9,11 *` | zweiter Samstag in ungeraden Monaten 08:00 |
| `restore-immich-quarterly` | `30 8 8-14 2,5,8,11 0` | zweiter Sonntag in Feb/Mai/Aug/Nov 08:30 |
| `monthly-random-restore` | `0 9 1 * *` | erster Kalendertag im Monat 09:00 |
## Betriebsmodus
- V1:
- Bash-Jobs laufen hostseitig manuell oder per User Script
- `ntfy`-Wrapper ist vorhanden; Erfolg geht nach `homelab-info`, Fehler nach `homelab-alerts`
- Hermes wertet spaeter optional Reports aus
- `ntfy` ist optional und folgt nach stabiler Basis
- Hermes wertet spaeter nur Reports aus
- V2:
- fester Host-Schedule
- `ntfy` bei Erfolg/Fehler ueber `run-restore-job-with-ntfy.sh`
- `ntfy` bei Erfolg/Fehler
- Hermes erzeugt Zusammenfassungen und Overviews
## Automatisierung
ops/restore-tests/shared-pg-cluster-compose.test.yml
-19
View File
@@ -1,19 +0,0 @@
services:
restoretest-shared-pg:
image: postgres:18.4@sha256:8ff36f3c66371cba71d20ceedccfc3de9669a68737607888c4ef0af93abe8e39
container_name: restoretest-shared-pg
restart: "no"
environment:
TZ: Europe/Berlin
POSTGRES_USER: postgres
POSTGRES_PASSWORD: restoretest-shared-pg-superuser
PGDATA: /var/lib/postgresql/18/docker
volumes:
- /mnt/user/backups/restore-lab/shared-pg-cluster/data:/var/lib/postgresql
healthcheck:
test: ["CMD-SHELL", "pg_isready -U postgres"]
interval: 10s
timeout: 5s
retries: 10
security_opt:
- no-new-privileges:true
ops/restore-tests/shared-pg-cluster-restore-test.sh
-239
View File
@@ -1,239 +0,0 @@
#!/bin/bash
set -euo pipefail
# Shared PostgreSQL 18 Cluster Restore Drill
#
# Beweist, dass der komplette Shared-Postgres-Cluster aus den Dump-Artefakten
# wiederhergestellt werden kann:
# 1. Globals (Rollen) aus pg_dumpall --globals-only
# 2. Per-DB Custom-Format-Dumps: paperless, mailarchiver, authelia,
# nextcloud, mealie
#
# Bekannter Sonderfall (docs/RESTORE_MATRIX.md):
# - CREATE ROLE mailarchiver scheitert, weil der User gleichzeitig der
# Dump-Admin-User ist. Das ALTER ROLE danach muss trotzdem durchlaufen.
# Der Test toleriert diesen spezifischen Fehler.
#
# Produktive PostgreSQL-Container und -Datenpfade werden NICHT angefasst.
SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
. "$SCRIPT_DIR/common.sh"
WHATIF=0
KEEP_DATA=0
for arg in "$@"; do
case "$arg" in
--what-if) WHATIF=1 ;;
--keep-data) KEEP_DATA=1 ;;
*) echo "Unknown argument: $arg" >&2; exit 1 ;;
esac
done
RESTORE_ROOT="/mnt/user/backups/restore-lab/shared-pg-cluster"
REPORT_ROOT="/mnt/user/backups/restore-reports"
COMPOSE_FILE="$SCRIPT_DIR/shared-pg-cluster-compose.test.yml"
REPORT_FILE="$REPORT_ROOT/shared-pg-cluster-$(date +%F).md"
DUMP_ROOT="/mnt/user/backups/borg/dumps/latest"
# Alle erwarteten Dumps
GLOBALS_DUMP="$DUMP_ROOT/postgresql17-globals.sql"
PAPERLESS_DUMP="$DUMP_ROOT/postgresql17-paperless.dump"
MAILARCHIVER_DUMP="$DUMP_ROOT/postgresql17-mailarchiver.dump"
AUTHELIA_DUMP="$DUMP_ROOT/postgresql17-authelia.dump"
NEXTCLOUD_DUMP="$DUMP_ROOT/nextcloud.dump"
MEALIE_DUMP="$DUMP_ROOT/mealie.dump"
if [ "$WHATIF" -eq 1 ]; then
cat <<EOF
Shared PostgreSQL 18 Cluster Restore Drill
Mode: WhatIf
RestoreRoot: $RESTORE_ROOT
Dumps from: $DUMP_ROOT
Steps:
1. Frisches postgres:18.4 mit Superuser hochfahren
2. Globals einspielen (pg_dumpall --globals-only)
-> bekannter mailarchiver-Rollenkonflikt wird toleriert
3. DBs anlegen: paperless, mailarchiver, authelia, nextcloud, mealie
4. Per-DB pg_restore fuer jede DB
5. Tabellen-Count pro DB als Sanity-Check
6. Report schreiben
EOF
exit 0
fi
require_cmd docker
require_path "$COMPOSE_FILE"
require_path "$GLOBALS_DUMP"
require_path "$PAPERLESS_DUMP"
require_path "$MAILARCHIVER_DUMP"
# Authelia/Nextcloud/Mealie-Dumps sind optional (koennen fehlen)
OPTIONAL_DUMPS=""
RESTORE_SUCCESS=0
cleanup() {
docker compose -f "$COMPOSE_FILE" down -v >/dev/null 2>&1 || true
if [ "$RESTORE_SUCCESS" -ne 1 ]; then
preserve_on_failure "shared-pg-cluster" "$RESTORE_ROOT"
return
fi
if [ "$KEEP_DATA" -ne 1 ]; then
rm -rf "$RESTORE_ROOT"
fi
}
trap cleanup EXIT
rm -rf "$RESTORE_ROOT"
mkdir -p "$RESTORE_ROOT/data"
# Stufe 1: Test-Postgres hochfahren
docker compose -f "$COMPOSE_FILE" up -d restoretest-shared-pg >/dev/null
until docker exec restoretest-shared-pg pg_isready -U postgres >/dev/null 2>&1; do
sleep 2
done
# Extra Wartezeit fuer Entrypoint-Init
sleep 3
# Stufe 2: Globals einspielen
# Der Globals-Dump enthaelt CREATE ROLE fuer alle DB-User. Der bekannte
# Konflikt ist, dass CREATE ROLE mailarchiver scheitern kann wenn dieser
# User auch der Dump-Admin ist. Wir tolerieren das und pruefen nur auf
# FATAL/PANIC.
globals_status="ok"
docker exec -i -e PGPASSWORD=restoretest-shared-pg-superuser restoretest-shared-pg \
psql -U postgres -f - < "$GLOBALS_DUMP" >/tmp/shared-pg-globals.log 2>&1 || true
if grep -qiE "FATAL|PANIC" /tmp/shared-pg-globals.log; then
globals_status="failed (FATAL/PANIC)"
cat /tmp/shared-pg-globals.log >&2
exit 1
fi
# Stufe 3: DBs anlegen und Dumps einspielen
declare -A DB_STATUS
declare -A TABLE_COUNTS
restore_db() {
local dbname="$1"
local dbuser="$2"
local dump_path="$3"
local optional="${4:-no}"
if [ ! -f "$dump_path" ]; then
if [ "$optional" = "yes" ]; then
DB_STATUS[$dbname]="skipped (dump missing)"
TABLE_COUNTS[$dbname]="n/a"
return 0
fi
DB_STATUS[$dbname]="failed (dump missing)"
TABLE_COUNTS[$dbname]="n/a"
return 1
fi
# Rolle anlegen falls nicht durch Globals erzeugt (idempotent)
docker exec -i -e PGPASSWORD=restoretest-shared-pg-superuser restoretest-shared-pg \
psql -U postgres -c "DO \$\$ BEGIN CREATE ROLE $dbuser WITH LOGIN PASSWORD 'restoretest-$dbuser'; EXCEPTION WHEN duplicate_object THEN NULL; END \$\$;" >/dev/null 2>&1 || true
# DB anlegen
docker exec -i -e PGPASSWORD=restoretest-shared-pg-superuser restoretest-shared-pg \
psql -U postgres -c "SELECT 1 FROM pg_database WHERE datname='$dbname'" 2>/dev/null | grep -q 1 || \
docker exec -i -e PGPASSWORD=restoretest-shared-pg-superuser restoretest-shared-pg \
createdb -U postgres -O "$dbuser" "$dbname" 2>/dev/null || true
# pg_restore mit Retry
local restore_ok=0
for attempt in $(seq 1 5); do
if docker exec -i -e PGPASSWORD=restoretest-shared-pg-superuser restoretest-shared-pg \
pg_restore -U postgres -d "$dbname" --clean --if-exists --no-owner --no-privileges \
< "$dump_path" 2>/tmp/shared-pg-restore-${dbname}.err; then
restore_ok=1
break
fi
if grep -qiE "starting up|shutting down|connection refused" /tmp/shared-pg-restore-${dbname}.err; then
sleep 5
continue
fi
# --clean erzeugt "does not exist" Warnungen beim ersten Import -> ignorieren
if grep -qiE "FATAL|PANIC" /tmp/shared-pg-restore-${dbname}.err; then
DB_STATUS[$dbname]="failed"
TABLE_COUNTS[$dbname]="n/a"
cat /tmp/shared-pg-restore-${dbname}.err >&2
return 1
fi
restore_ok=1
break
done
if [ "$restore_ok" -ne 1 ]; then
DB_STATUS[$dbname]="failed (timeout)"
TABLE_COUNTS[$dbname]="n/a"
return 1
fi
DB_STATUS[$dbname]="ok"
# Tabellen zaehlen
TABLE_COUNTS[$dbname]="$(docker exec -i -e PGPASSWORD=restoretest-shared-pg-superuser restoretest-shared-pg \
psql -U postgres -d "$dbname" -tAc \
"SELECT count(*) FROM information_schema.tables WHERE table_schema='public';" \
2>/dev/null | tr -d '[:space:]' || echo "n/a")"
}
restore_db "paperless" "paperless" "$PAPERLESS_DUMP"
restore_db "mailarchiver" "mailarchiver" "$MAILARCHIVER_DUMP"
restore_db "authelia" "authelia" "$AUTHELIA_DUMP" "yes"
restore_db "nextcloud" "nextcloud" "$NEXTCLOUD_DUMP" "yes"
restore_db "mealie" "mealie" "$MEALIE_DUMP" "yes"
# Stufe 4: data_checksums pruefen
checksums="$(docker exec -i -e PGPASSWORD=restoretest-shared-pg-superuser restoretest-shared-pg \
psql -U postgres -tAc "SHOW data_checksums;" 2>/dev/null | tr -d '[:space:]' || echo "n/a")"
# Stufe 5: DB-Liste
db_list="$(docker exec -i -e PGPASSWORD=restoretest-shared-pg-superuser restoretest-shared-pg \
psql -U postgres -tAc "SELECT datname FROM pg_database WHERE NOT datistemplate ORDER BY datname;" \
2>/dev/null | tr '\n' ', ' | sed 's/,$//' || echo "n/a")"
# Report bauen
report_body="# Shared PostgreSQL 18 Cluster Restore Drill - $(date +%F)
- Dump source: \`$DUMP_ROOT\`
- Restore root: \`$RESTORE_ROOT\`
- Result: \`SUCCESS\`
## Checks
- Test-Postgres healthy: \`ok\`
- Globals import: \`$globals_status\`
- data_checksums: \`$checksums\`
- Databases: \`$db_list\`
## Per-DB Restore
| Database | Restore | Tables |
|---|---|---|
| paperless | \`${DB_STATUS[paperless]}\` | \`${TABLE_COUNTS[paperless]}\` |
| mailarchiver | \`${DB_STATUS[mailarchiver]}\` | \`${TABLE_COUNTS[mailarchiver]}\` |
| authelia | \`${DB_STATUS[authelia]}\` | \`${TABLE_COUNTS[authelia]}\` |
| nextcloud | \`${DB_STATUS[nextcloud]}\` | \`${TABLE_COUNTS[nextcloud]}\` |
| mealie | \`${DB_STATUS[mealie]}\` | \`${TABLE_COUNTS[mealie]}\` |
## Scope
Dieser Drill beweist, dass der gesamte Shared-PostgreSQL-18-Cluster aus
den taeglichen Dump-Artefakten wiederhergestellt werden kann: Globals
(Rollen) + per-DB Custom-Format-Dumps. Der bekannte mailarchiver-
Bootstrap-Rollenkonflikt wird toleriert.
## Notes
- Produktive PostgreSQL-Container und -Datenpfade wurden nicht beruehrt.
- Test-Postgres nutzt Wegwerf-Superuser-Passwort.
- Test-Daten wurden \`$([ "$KEEP_DATA" -eq 1 ] && echo behalten || echo bereinigt)\`.
"
write_report "$REPORT_FILE" <<EOF
$report_body
EOF
RESTORE_SUCCESS=1
echo "Shared PG cluster restore drill ok -> $REPORT_FILE"
ops/restore-tests/traefik-compose.test.yml
-29
View File
@@ -1,29 +0,0 @@
services:
restoretest-traefik:
image: traefik:v3.7@sha256:6b9cbca6fac42ab0075f5437d8dc1685cfd188626d8d515839ea94f8b6271c42
container_name: restoretest-traefik
restart: "no"
command:
# Minimale Config fuer den Smoke: kein Docker-Provider (kein docker.sock),
# kein ACME (kein CF-Token), kein TLS-Entrypoint. Nur:
# - File-Provider mit restauriertem dynamic/-Verzeichnis
# - HTTP-Entrypoint auf Test-Port
# - Ping-Endpoint fuer Health-Check
- --ping=true
- --ping.entrypoint=web
- --providers.file.directory=/dynamic
- --providers.file.watch=false
- --entrypoints.web.address=:80
- --api.dashboard=false
- --log.level=INFO
ports:
- "127.0.0.1:18880:80"
volumes:
# Restauriertes dynamic/-Verzeichnis aus Borg (read-only)
- /mnt/user/backups/restore-lab/traefik/dynamic:/dynamic:ro
# Restauriertes letsencrypt/ fuer Existenz-Nachweis (read-only)
- /mnt/user/backups/restore-lab/traefik/letsencrypt:/letsencrypt:ro
# KEIN docker.sock — Test-Traefik darf keine produktiven Container discovern
# KEIN CF-Token — keine DNS-Challenge im Smoke
security_opt:
- no-new-privileges:true
ops/restore-tests/traefik-restore-test.sh
-153
View File
@@ -1,153 +0,0 @@
#!/bin/bash
set -euo pipefail
# Traefik Restore Smoke Test
#
# Beweist, dass die restaurierten Traefik-Dateien (dynamic/, letsencrypt/)
# aus dem Borg-Archiv einen funktionsfaehigen Traefik-Start ermoeglichen.
#
# Scope:
# - Borg-Extract von dynamic/ und letsencrypt/
# - Traefik startet mit File-Provider gegen restauriertes dynamic/
# - /ping Health-Endpoint antwortet
# - acme.json aus letsencrypt/ ist vorhanden und nicht leer
#
# Bewusst NICHT Teil des Smokes:
# - Docker-Provider (kein docker.sock im Test — wuerde produktive Container discovern)
# - ACME/DNS-Challenge (kein CF-Token im Test)
# - TLS-Terminierung (kein Cert-Test)
# - Produktive Ports 80/443
SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
. "$SCRIPT_DIR/common.sh"
WHATIF=0
KEEP_DATA=0
for arg in "$@"; do
case "$arg" in
--what-if) WHATIF=1 ;;
--keep-data) KEEP_DATA=1 ;;
*) echo "Unknown argument: $arg" >&2; exit 1 ;;
esac
done
RESTORE_ROOT="/mnt/user/backups/restore-lab/traefik"
REPORT_ROOT="/mnt/user/backups/restore-reports"
EXTRACT_DIR="$BORG_RESTORE_HOST_ROOT/traefik-extract"
COMPOSE_FILE="$SCRIPT_DIR/traefik-compose.test.yml"
REPORT_FILE="$REPORT_ROOT/traefik-$(date +%F).md"
if [ "$WHATIF" -eq 1 ]; then
cat <<EOF
Traefik restore test
Mode: WhatIf
RestoreRoot: $RESTORE_ROOT
Borg source: local/appdata/traefik
Test endpoint: 127.0.0.1:18880/ping
Scope: File-Provider + Ping, kein Docker-Provider, kein ACME, kein CF-Token
EOF
exit 0
fi
require_cmd docker
require_cmd curl
require_path "$BORG_PASSPHRASE_FILE_DEFAULT"
require_path "$COMPOSE_FILE"
RESTORE_SUCCESS=0
cleanup() {
cleanup_compose "$COMPOSE_FILE"
if [ "$RESTORE_SUCCESS" -ne 1 ]; then
preserve_on_failure "traefik" "$RESTORE_ROOT"
rm -rf "$EXTRACT_DIR"
return
fi
if [ "$KEEP_DATA" -ne 1 ]; then
rm -rf "$RESTORE_ROOT"
fi
rm -rf "$EXTRACT_DIR"
}
trap cleanup EXIT
rm -rf "$EXTRACT_DIR" "$RESTORE_ROOT"
mkdir -p "$RESTORE_ROOT"
archive="$(latest_archive_name)"
repo="$(borg_repo_url)"
if [ -z "$archive" ] || [ -z "$repo" ]; then
echo "Could not resolve Borg repo/archive from borg-ui database" >&2
exit 1
fi
# Stufe 1: Traefik-Dateien aus Borg (dynamic/ + letsencrypt/)
# Secrets/ wird bewusst NICHT extrahiert (enthaelt CF-Token)
borg_extract "/restore/traefik-extract" \
"local/appdata/traefik/dynamic" \
"local/appdata/traefik/letsencrypt"
if [ ! -d "$EXTRACT_DIR/local/appdata/traefik/dynamic" ]; then
echo "Traefik dynamic/ path missing in Borg archive" >&2
exit 1
fi
cp -a "$EXTRACT_DIR/local/appdata/traefik/dynamic" "$RESTORE_ROOT/dynamic"
cp -a "$EXTRACT_DIR/local/appdata/traefik/letsencrypt" "$RESTORE_ROOT/letsencrypt"
chmod -R a+rX "$RESTORE_ROOT/dynamic" "$RESTORE_ROOT/letsencrypt"
# Stufe 2: Datei-Checks
dynamic_files="$(find "$RESTORE_ROOT/dynamic" -type f | wc -l)"
acme_size="$(stat -c %s "$RESTORE_ROOT/letsencrypt/acme.json" 2>/dev/null || echo 0)"
# Stufe 3: Traefik starten
docker compose -f "$COMPOSE_FILE" up -d restoretest-traefik >/dev/null
http_status=""
for _ in $(seq 1 30); do
http_status="$(curl -s -o /dev/null -w '%{http_code}' \
http://127.0.0.1:18880/ping || true)"
if [ "$http_status" = "200" ]; then
break
fi
sleep 2
done
if [ "$http_status" != "200" ]; then
echo "Traefik /ping smoke failed: status=$http_status" >&2
docker logs --tail 60 restoretest-traefik >&2 || true
exit 1
fi
write_report "$REPORT_FILE" <<EOF
# Traefik Restore Test Report - $(date +%F)
- Service: \`traefik\`
- Source repo: \`$repo\`
- Archive: \`$archive\`
- Restore root: \`$RESTORE_ROOT\`
- Test container: \`restoretest-traefik\`
- Test endpoint: \`http://127.0.0.1:18880/ping\`
- Result: \`SUCCESS\`
## Checks
- Borg extract of dynamic/: \`ok\` ($dynamic_files files)
- Borg extract of letsencrypt/: \`ok\` (acme.json ${acme_size} bytes)
- Traefik /ping health: \`$http_status\`
## Scope
Config-Restore + File-Provider-Boot + Ping-Health. Kein Docker-Provider
(docker.sock nicht gemountet), kein ACME/DNS-Challenge (CF-Token nicht
im Test), keine produktiven Ports.
## Notes
- Productive CF-Token under /mnt/user/appdata/traefik/secrets/ was NOT extracted or mounted.
- dynamic/ contains middlewares.yml and usersfile — Traefik loads them via File-Provider.
- acme.json is present and non-empty; TLS cert validity not tested in smoke.
- Test data was cleaned after success: \`$([ "$KEEP_DATA" -eq 1 ] && echo no || echo yes)\`
EOF
RESTORE_SUCCESS=1
echo "Traefik restore test ok -> $REPORT_FILE"
ops/restore-tests/unraid-user-scripts.md
+45 -105
View File
@@ -10,22 +10,18 @@ Host-Repo-Pfad:
/mnt/user/services/homelab-infra
```
**Wichtig - Cron-Semantik**: Vixie-Cron verknuepft `day-of-month` und `day-of-week` mit **OR**, sobald beide gesetzt sind. Wir triggern daher an jedem Samstag/Sonntag und filtern den Monatstag per Shell-Guard im User-Script. Siehe `ops/restore-tests/schedule.md`.
**Wichtig - keine doppelten Schreiber**: die Restore-Skripte schreiben ihren Markdown-Report **selbst** nach `/mnt/user/backups/restore-reports/<service>-YYYY-MM-DD.md`. User-Scripts duerfen den Job-Output **nicht** in dieselbe Datei umleiten, sonst gewinnt der letzte Writer. Wrapper-Output landet stattdessen in `/mnt/user/backups/restore-reports/_wrapper-<mode>-YYYY-MM-DD.log`.
## Script 1 - `restore-freshness-weekly`
Cron:
Zeit:
- `30 6 * * 1` (Montag 06:30)
- Montag, 06:30
Inhalt:
```bash
#!/bin/bash
exec /mnt/user/services/homelab-infra/ops/restore-tests/run-restore-job-with-ntfy.sh \
freshness homelab-info
bash /mnt/user/services/homelab-infra/ops/restore-tests/run-restore-checks.sh freshness \
> /mnt/user/backups/restore-reports/freshness-$(date +%F).md
```
Erwartung:
@@ -36,133 +32,77 @@ Erwartung:
## Script 2 - `restore-vaultwarden-monthly`
Cron:
Zeit:
- `0 7 * * 6` (jeden Samstag 07:00)
- 1. Samstag im Monat, 07:00
Guard: nur am ersten Samstag im Monat ausfuehren.
V1-Inhalt:
```bash
#!/bin/bash
# Guard: nur 1.-7. Tag im Monat, damit "1. Samstag" eindeutig getroffen wird.
day=$(date +%-d)
if [ "$day" -lt 1 ] || [ "$day" -gt 7 ]; then
exit 0
fi
exec /mnt/user/services/homelab-infra/ops/restore-tests/run-restore-job-with-ntfy.sh \
vaultwarden homelab-info
bash /mnt/user/services/homelab-infra/ops/restore-tests/run-restore-checks.sh vaultwarden \
> /mnt/user/backups/restore-reports/vaultwarden-$(date +%F).md
```
## Script 3 - `restore-gitea-monthly`
Cron:
Zeit:
- `15 7 * * 6` (jeden Samstag 07:15)
- 3. Samstag im Monat, 07:00
Guard: nur am dritten Samstag im Monat ausfuehren.
V1-Inhalt:
```bash
#!/bin/bash
day=$(date +%-d)
if [ "$day" -lt 15 ] || [ "$day" -gt 21 ]; then
exit 0
fi
exec /mnt/user/services/homelab-infra/ops/restore-tests/run-restore-job-with-ntfy.sh \
gitea homelab-info
bash /mnt/user/services/homelab-infra/ops/restore-tests/run-restore-checks.sh gitea \
> /mnt/user/backups/restore-reports/gitea-$(date +%F).md
```
## Script 4 - `restore-paperless-bimonthly`
Cron:
Zeit:
- `0 8 * * 6` (jeden Samstag 08:00)
- jeder 2. Monat, 2. Samstag, 08:00
Guard: nur am zweiten Samstag in ungeraden Monaten ausfuehren.
V1-Inhalt:
```bash
#!/bin/bash
month=$(date +%-m)
day=$(date +%-d)
case "$month" in
1|3|5|7|9|11) ;;
*) exit 0 ;;
esac
if [ "$day" -lt 8 ] || [ "$day" -gt 14 ]; then
exit 0
fi
exec /mnt/user/services/homelab-infra/ops/restore-tests/run-restore-job-with-ntfy.sh \
paperless homelab-info
```
## Script 5 - `restore-immich-quarterly`
Cron:
- `30 8 * * 0` (jeden Sonntag 08:30)
Guard: nur am zweiten Sonntag in Feb/Mai/Aug/Nov ausfuehren.
```bash
#!/bin/bash
month=$(date +%-m)
day=$(date +%-d)
case "$month" in
2|5|8|11) ;;
*) exit 0 ;;
esac
if [ "$day" -lt 8 ] || [ "$day" -gt 14 ]; then
exit 0
fi
exec /mnt/user/services/homelab-infra/ops/restore-tests/run-restore-job-with-ntfy.sh \
immich homelab-info
```
## Script 6 - `restore-authelia-bimonthly`
Cron:
- `30 7 * * 6` (jeden Samstag 07:30)
Guard: nur am zweiten Samstag in geraden Monaten ausfuehren.
```bash
#!/bin/bash
month=$(date +%-m)
day=$(date +%-d)
case "$month" in
2|4|6|8|10|12) ;;
*) exit 0 ;;
esac
if [ "$day" -lt 8 ] || [ "$day" -gt 14 ]; then
exit 0
fi
exec /mnt/user/services/homelab-infra/ops/restore-tests/run-restore-job-with-ntfy.sh \
authelia homelab-info
```
## Script 7 - `monthly-random-restore`
Cron:
- `0 9 1 * *` (erster Kalendertag im Monat 09:00) - kein Guard noetig.
```bash
#!/bin/bash
exec /mnt/user/services/homelab-infra/ops/restore-tests/monthly-random-restore.sh
bash /mnt/user/services/homelab-infra/ops/restore-tests/run-restore-checks.sh paperless \
> /mnt/user/backups/restore-reports/paperless-$(date +%F).md
```
## Stand
- die ersten Bash-Jobs wurden am 2026-05-07 hostseitig erfolgreich verifiziert
- `freshness`, `vaultwarden`, `gitea`, `paperless`, `immich` und `authelia` sind als Host-Jobs verfuegbar
- ntfy-Wrapper schreibt Erfolg/Fehler-Meldungen an die definierten Topics
- die Bash-Jobs wurden am 2026-05-07 hostseitig erfolgreich verifiziert
- `freshness`, `vaultwarden`, `gitea` und `paperless` laufen damit prinzipiell automatisch
- `ntfy` kann jetzt optional per Wrapper-Skript ergaenzt werden
## Fehler-Topic
## V2 Zielbild
Fehler gehen unabhaengig vom Erfolgstopic nach `homelab-alerts` (siehe `RESTORE_FAILURE_TOPIC` im Wrapper), damit Restore-Probleme auf demselben Handy-Topic landen wie Prometheus-, Docker-, Borg- und Posture-Alarme.
Als naechster Ausbau kommen dazu:
## Verwendete Hilfsskripte
1. Restore aus Borg
2. Testcontainer starten
3. Smoke-Test
4. Report schreiben
5. optional `ntfy`
6. Bereinigung
## Optionales `ntfy` Wrapper-Muster
Wenn `ntfy` genutzt wird, soll der Host-Job nur Erfolg/Fehler referenzieren, nicht den ganzen Report in die Nachricht kippen.
Beispiel:
```bash
#!/bin/bash
bash /mnt/user/services/homelab-infra/ops/restore-tests/run-restore-job-with-ntfy.sh freshness homelab-info
```
Fehler gehen unabhaengig vom Erfolgstopic nach `homelab-alerts`, damit Restore-Probleme auf dem gleichen Handy-Topic landen wie Prometheus-, Docker-, Borg- und Posture-Alarme.
Verwendete Hilfsskripte:
- `ops/restore-tests/send-ntfy.sh`
- `ops/restore-tests/run-restore-job-with-ntfy.sh`
- `ops/restore-tests/run-restore-checks.sh`
ops/restore-tests/vaultwarden-compose.test.yml
+2 -6
View File
@@ -10,12 +10,7 @@ services:
WEBSOCKET_ENABLED: "true"
SIGNUPS_ALLOWED: "false"
INVITATIONS_ALLOWED: "false"
# Wegwerf-Admin-Token nur fuer den isolierten Smoke-Test.
# Bewusst KEIN Mount des produktiven vaultwarden_admin_token.txt,
# damit das echte Admin-Token nie in einem Test-Container-Lebenszyklus
# auftaucht. Smoke-Test prueft nur Login-Seite, das Token wird nicht
# zur Authentifizierung gebraucht.
ADMIN_TOKEN: restoretest-vaultwarden-admin-token-placeholder
ADMIN_TOKEN_FILE: /run/secrets/admin_token
ROCKET_PORT: 80
ROCKET_ADDRESS: 0.0.0.0
@@ -24,6 +19,7 @@ services:
volumes:
- /mnt/user/backups/restore-lab/vaultwarden/data:/data
- /mnt/user/appdata/secrets/vaultwarden_admin_token.txt:/run/secrets/admin_token:ro
security_opt:
- no-new-privileges:true

Some files were not shown because too many files have changed in this diff Show More