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

backup: windows image baseline for baerchen

Browse Source
This commit is contained in:
Micha
2026-06-05 22:19:27 +02:00
parent 88a42f3f78
commit bc3ecad45a
20 changed files with 1392 additions and 61 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/AI_CONTEXT.md
+20 -2
View File
@@ -1,6 +1,6 @@
# AI Context
Stand: 2026-06-02
Stand: 2026-06-05
Kurzer Kontext fuer KI-Agenten. Nicht als Ersatz fuer die echten Runbooks lesen.
@@ -43,14 +43,32 @@ Kurzer Kontext fuer KI-Agenten. Nicht als Ersatz fuer die echten Runbooks lesen.
## Aktuelle Restpunkte
Authoritativ: `docs/AUDIT_2026-05-25_TODO.md`.
Authoritativ: `docs/MASTER_TODO.md`.
Kurzfassung:
- 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.
docs/AUDIT_2026-05-25_TODO.md
+4
View File
@@ -3,6 +3,10 @@
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 |
docs/DISASTER_RECOVERY.md
+36
View File
@@ -522,6 +522,40 @@ 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
@@ -531,6 +565,8 @@ Smoke-Test: `hermes-gateway` healthcheck ist gruen, `hermes.kaleschke.info` leit
- 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/FAMILY_ONBOARDING.md
+58 -12
View File
@@ -193,20 +193,66 @@ Michi laesst es dich wissen, wenn ein Wartungsfenster geplant ist.
---
## Onboarding-Checkliste fuer Michi
## Erster Onboarding-Termin - Ablauf fuer Michi
Diese Punkte gehoeren in das erste echte Familien-Onboarding. Keine Secret-Werte
in diese Datei schreiben.
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.
| 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 |
> 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").
## Bewusst nicht versprochen
docs/HARDWARE_INVENTORY.md
+29 -8
View File
@@ -3,8 +3,20 @@
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 | **Operator-Entscheidung offen: Messgeraet beschaffen.** Aktuell kein Smart-Plug/Messgeraet vorhanden, daher keine Messwerte. | Beschaffung eines USB-/Smart-Plug-Messgeraets (z. B. schaltbare Mess-Steckdose) |
## 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.
@@ -96,7 +108,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 | TBD | TBD | TBD | TBD | TBD | Externe Rotation | offen |
| 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 |
Pruefkommando:
@@ -138,18 +150,27 @@ Bewertung:
- Aktueller Befund 2026-05-26: keine funktionierende USV-Absicherung nachgewiesen.
- `apcupsd` ist zwar auf dem System vorhanden, aber nicht aktiv.
- Operator-Entscheidung 2026-05-26: aktuell keine USV-Anschaffung.
- **Operator-Entscheidung 2026-06-05: USV-Anschaffung bewusst auf Q3/2026 geparkt.** Keine Beschaffung in diesem Quartal.
- Power-Loss bleibt damit ein bewusst akzeptiertes Risiko fuer Docker-/DB-State und laufende Writes.
- Review-Ausloeser: Hardware-Erweiterung, wiederholte Stromausfaelle, Datenkorruption oder Veraenderung der Betreiber-Prioritaet.
- 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.
## Stromverbrauch
**Operator-Entscheidung offen: Messgeraet beschaffen.** Stand 2026-06-05 ist kein
Smart-Plug/Messgeraet vorhanden, daher liegen keine Messwerte vor. Die Werte
bleiben bewusst offen, bis ein messfaehiges Geraet beschafft ist. Erst danach
werden Idle/Normal/Backup/Last in einem Durchlauf erfasst.
| Zustand | Verbrauch | Messmethode | Datum |
|---|---:|---|---|
| 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 |
| 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.
## Ersatzteil- und Lifecycle-Plan
@@ -160,7 +181,7 @@ Bewertung:
| 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 | Risiko am 2026-05-26 bewusst akzeptiert; bei Review erneut bewerten |
| USV | keine funktionierende USV-Abschaltung | Anschaffung 2026-06-05 bewusst auf Q3/2026 geparkt; Trigger: Hardware-Upgrade, realer Stromausfall mit Datenfolge, oder Q3-Review |
## Audit-Kommandos
docs/MASTER_TODO.md
+109
View File
@@ -0,0 +1,109 @@
# Master To-do - KalliLab CORE
Stand: 2026-06-05 (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 |
|---|---|---|---|
| DR-Workstation Bare-Metal-Kit | Operator | Auf dem Gaming-PC `wsl --install -d Ubuntu`, dann `sudo apt install borgbackup`, dann Smoke `borg list ssh://u565255@u565255.your-storagebox.de/./hetzner_borg_appdata_critical` mit offline gesichertem Key + Passphrase | `docs/AUDIT_2026-05-25_TODO.md`, `docs/DR_WORKSTATION_SETUP.md`, `docs/EXTERNAL_DEPENDENCIES.md` |
| 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` |
| Home Assistant -> InfluxDB Token | Operator | `influxdb3_homeassistant_token` in InfluxDB 3 erzeugen, in HA `secrets.yaml` ablegen, einen Write-Pfad-Test fahren; nur Variablennamen/Pfade dokumentieren, kein Wert ins Repo | `docs/SECRETS_MAP.md`, `docs/HOME_ASSISTANT_INFLUXDB_ECOWITT.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 AdGuard Home | Operator | Runbook-Stub abarbeiten: Config nach `/mnt/user/backups/restore-lab/adguard` extrahieren, Testcontainer auf Port `5353`/`3001`, DNS-Smoke | `docs/RESTORE_MATRIX.md` Abschnitt "AdGuard Home" |
| 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" |
| Restore-Test Redis 8 | Operator | Runbook-Stub abarbeiten: Pre-Cutover-Backup in isolierte Instanz auf Port `16379`, `PING` + `INFO server` (8.x) + `DBSIZE` pruefen | `docs/RESTORE_MATRIX.md` Abschnitt "Redis 8 (Shared)" |
| Manuelle App-/Lizenzchecks `baerchen` | Codex/Operator | Passwortmanager/2FA-Recovery-Codes, Banking4, WISO, Microsoft/M365/OneDrive im laufenden System bestaetigen | `ops/windows-reinstall/docs/windows-neuaufsetzen-masterplan.md` |
---
## Operator-Entscheidung
| Thema | Entscheidungsfrage | Quelle |
|---|---|---|
| BitLocker-Entscheidung `baerchen` | C: (und ggf. D:) aktivieren oder bewusst deaktiviert lassen? Bei Ja: Recovery-Key vorher nach `D:\30_Finanzen\...`, Vaultwarden und physisch sichern. (Claude fasst BitLocker bewusst nicht an.) | `docs/SECRETS_MAP.md`, `ops/windows-reinstall/docs/laufwerks-neustruktur-2026-06-04.md` |
| Veeam Storage Encryption `baerchen` | Reicht der erste unverschluesselte Full-Lauf, oder soll Veeam Storage Encryption aktiviert werden? Bei Ja: Passwort in Vaultwarden anlegen, Job umstellen und neues Full-Backup erzeugen | `ops/windows-reinstall/docs/windows-image-backup-baseline.md`, `docs/SECRETS_MAP.md` |
| Stromverbrauch messen | Messgeraet/Smart-Plug beschaffen? Ohne Geraet bleiben Idle/Normal/Backup/Last bewusst offen. **Status 2026-06-05: kein Geraet vorhanden.** | `docs/HARDWARE_INVENTORY.md` Abschnitt "Stromverbrauch" |
| Tailscale ACL-Policy | **Jetzt sicherheitsrelevanter:** Messung 2026-06-05 zeigt, dass der Host das ganze LAN `192.168.178.0/24` als Subnet-Route ins Tailnet bringt — jedes Tailnet-Geraet kann darueber LAN-/Admin-Dienste erreichen. Entscheidung: Default-Allow belassen oder Tag-basierte ACL (`tag:operator`/`tag:family`) einfuehren? Aktuelle Policy read-only aus Admin-Konsole sichten, kein Wert ins Repo | `docs/NETWORK_INVENTORY.md` Abschnitt "Tailscale" / "ACL-Policy" |
| Nextcloud 2FA / Brute-Force-Haertung | Operator-TOTP (`twofactor_totp`) jetzt aktivieren? Familien-/OIDC-weite Policy separat | `docs/AUDIT_2026-05-25_TODO.md` |
| Authelia Rest-2FA | Weitere Admin-UIs (`monitoring`, `glances`, `glance`, `speedtest`, `pdf`, `mail`, `sp` ...) von `one_factor` auf `two_factor` heben oder bewusst belassen? | `docs/AUDIT_2026-05-25_TODO.md` |
| Authelia OIDC fuer Apps | App-uebergreifendes SSO einfuehren - haengt an Familien-/SSO-Grundsatzentscheidung | `docs/AUDIT_2026-05-25_TODO.md` |
| Gast-/IoT-Netz | Bewusst kein Gast-WLAN/IoT-Netz aktivieren, solange nicht gebraucht. Vorbedingung bei spaeterer Aktivierung: LAN-Admin-Ports vorher per FRITZ!Box-Filter gegen das Gastsegment sperren | `docs/NETWORK_INVENTORY.md` |
---
## 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` |
| Home Assistant InfluxDB Bind | Aktuell `127.0.0.1:8181`, validiert. Nur wenn HA nicht lokal auf den Host schreibt, bewusste Bind-Aenderung planen | `docs/NETWORK_INVENTORY.md` |
| Docker Critical Events Watcher | Optional als Unraid User-Script `at array start` aktivieren und ntfy-Smoke; kein Pflicht-Pfad | `docs/SERVICE_CATALOG.md`, `services/posture-check/docker-critical-events.sh` |
| Negativ-Test Backup-Frische | Quartalsweise: bewusst kaputten/fehlenden Dump in Testpfad simulieren, pruefen ob `homelab-alerts` feuert | `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` |
| 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 |
|---|---|---|---|
| `baerchen` Recovery-Test ohne Restore | Haengt am physischen USB-Boot-Test | Von USB `VEEAMRE` booten, SMB-Ziel mounten, Restore Point anzeigen, vor echtem Restore abbrechen. **Owner: Codex/Operator** | `ops/windows-reinstall/docs/windows-image-backup-baseline.md`, `docs/RESTORE_MATRIX.md` |
| 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` |
| Stromverbrauch-Messwerte | Kein Messgeraet beschafft | Nach Beschaffung einer schaltbaren Mess-Steckdose einen Messdurchlauf Idle/Normal/Backup/Last fahren | `docs/HARDWARE_INVENTORY.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 (Operator-Entscheidung offen) 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.
---
## 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
+58 -11
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.
Letzte Pruefung: 2026-06-01
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)
## Zweck
@@ -44,23 +44,70 @@ Dieses Dokument beschreibt Router, DNS, Tailscale, Portfreigaben und Netztrennun
## Tailscale
| Feld | Wert |
Gemessen am 2026-06-05 per read-only SSH auf den Host (`tailscale status`,
`tailscale status --json`, `tailscale ip -4/-6`).
| Feld | Wert / Status |
|---|---|
| Node-Name | Kallilabcore |
| Tailscale IPv4 | 100.80.98.33 |
| Tailscale IPv6 | TBD |
| Exit Node | TBD |
| Subnet Router | TBD |
| ACL-Policy extern dokumentiert | TBD |
| 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 | **Operator-Entscheidung offen** — siehe eigener Block unten; durch den aktiven Subnet-Router ist die ACL-Frage sicherheitsrelevanter als zuvor angenommen. |
Pruefkommando:
### 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 | gelistet, kein aktiver Verkehr — **moeglicher Alt-/Dubletten-Node**, separat pruefen |
> Hygiene-Hinweis (kein Secret): Es existieren zwei linux-Nodes mit aehnlichem
> Namen (`kallilabcore` und `kallilab-core`) sowie zwei `baerchen`-Nodes
> (`baerchen-1` aktiv, `baerchen` offline). Bei Gelegenheit in der
> Tailscale-Admin-Konsole pruefen, ob die inaktiven Eintraege stillgelegt werden
> koennen. Das ist Aufraeumarbeit, kein akutes Risiko.
### 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):
```bash
tailscale status
tailscale status --json | jq '{exitNode: .Self.ExitNodeOption, primaryRoutes: .Self.PrimaryRoutes, allowedIPs: .Self.AllowedIPs}'
tailscale ip -4
tailscale ip -6
```
### ACL-Policy (Operator-Entscheidung offen)
Die Tailnet-ACL ist aktuell nicht im Repo gespiegelt. Sie wird in der
Tailscale-Admin-Konsole unter `Access controls` verwaltet (kein Wert/Secret
gehoert ins Repo). Offene Entscheidung:
- Default-Allow belassen (jedes Tailnet-Geraet darf alles, inkl. der
LAN-Subnet-Route), **oder**
- restriktivere, Tag-basierte ACL einfuehren: nur Operator-Geraete duerfen die
Subnet-Route `192.168.178.0/24` und die Admin-Ports nutzen, Familien-/Mobil-
geraete nur die explizit benoetigten Dienste.
Empfehlung (zur Entscheidung, nicht umgesetzt): Da der Subnet-Router das ganze
LAN ins Tailnet bringt, ist eine restriktive ACL der wirksamste Hebel. Naechster
Schritt waere, die aktuelle Policy read-only aus der Admin-Konsole zu sichten
und dann eine Tag-Struktur (`tag:operator`, `tag:family`) zu entwerfen.
## Portfreigaben und Exposure
### FRITZ!Box (WAN -> Host)
@@ -154,7 +201,7 @@ docker network inspect backend_net | jq '.[0].Internal'
| 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 | 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 |
| Gast-/IoT-Zugriff auf Admin-Ports | **Entscheidungspunkt: kein Gast-/IoT-Netz aktivieren, solange nicht gebraucht** | Aktuell entschaerft, weil Gast-WLAN inaktiv ist und kein IoT-VLAN existiert. Risiko entsteht erst bei Aktivierung. Harte Vorbedingung fuer eine spaetere Aktivierung: **vor** dem Einschalten von Gast-WLAN/IoT muessen `192.168.178.58:8082` (AdGuard-Admin, ohnehin Tailscale-gebunden), `192.168.178.58:8181` (InfluxDB, bereits `127.0.0.1`-bound) und alle weiteren LAN-Admin-Ports per FRITZ!Box-Netzwerkfilter/Kindersicherung gegen das Gastsegment gesperrt sein. Bis dahin bewusst kein Gastnetz. |
| 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 | bewusst nicht eingerichtet | Mobilfunk-Stick-Failover an FRITZ!Box ist nicht aktiv; Internet-Ausfall = ACME/DDNS pausieren, lokale Apps laufen weiter |
| 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. |
| 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. |
docs/README.md
+4 -1
View File
@@ -1,6 +1,6 @@
# Documentation Index
Stand: 2026-06-01
Stand: 2026-06-05
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.
@@ -52,6 +52,9 @@ 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/RESTORE_MATRIX.md
+159 -7
View File
@@ -40,6 +40,14 @@ Sie ist die fachliche Ergaenzung zu `docs/DISASTER_RECOVERY.md`.
---
## 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 | Von `VEEAMRE` booten, SMB-Ziel oeffnen, Restore Point anzeigen, vor echtem Restore abbrechen; Runbook `ops/windows-reinstall/docs/windows-image-backup-baseline.md` |
---
## Tier 2 - Wichtige Anwendungen
| Dienst | Fuehrende Quelle | Datei-Restore | Dump / DB | Secrets / ENV | Abhaengigkeiten | Smoke-Test |
@@ -127,7 +135,7 @@ Die Dump-Erzeugung ist host-seitig ueber `ops/borg-ui/scripts/pre-backup-dumps.s
## Restore-Test-Reifegrad
Stand 2026-06-03. Pro Dienst auf einen Blick: Wurde der Restore schon einmal real getestet?
Stand 2026-06-05. Pro Dienst auf einen Blick: Wurde der Restore schon einmal real getestet?
| Dienst | Tier | Letzter Restore-Test | Typ | Naechster Lauf |
|---|---|---|---|---|
@@ -137,7 +145,7 @@ Stand 2026-06-03. Pro Dienst auf einen Blick: Wurde der Restore schon einmal rea
| 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 | - | noch kein Test | - |
| 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 | - | noch kein Test | - |
| Tailscale | 1 | - | noch kein Test | - |
@@ -151,13 +159,157 @@ Stand 2026-06-03. Pro Dienst auf einen Blick: Wurde der Restore schon einmal rea
| ntfy | 2 | - | rebuildbar, kein Test noetig | - |
| Borg UI | 3 | - | rebuildbar | - |
| Filebrowser | 3 | - | rebuildbar | - |
| baerchen Windows Image | Workstation | 2026-06-05 | Full-Backup geschrieben; Recovery USB + SMB-Mount noch offen | Recovery-USB-Test |
---
## Naechste Restore-Test-Kandidaten (priorisiert)
1. **Shared PostgreSQL 18 Cluster** - globals + per-DB-Dumps, Bootstrap-Konflikt `mailarchiver`
3. **Komodo Mongo Daten** - echtes `mongorestore` aus `komodo-mongo.archive.gz` (Quelle fuer `KOMODO_*`-Stack-ENVs im DR)
4. **Mailarchiver** - Tier 2, shared Postgres + Authelia ForwardAuth
5. **Mealie** - Tier 2, eigene Postgres
6. **Traefik** - Tier 1, aber komplex (dynamic/, LE-State, CF-Token-Mount)
Stand 2026-06-05. 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. **AdGuard Home** - Config-Restore in Testpfad oder Wegwerf-Instanz pruefen
3. **Tailscale** - State-/Reconnect-Pfad dokumentiert testen
4. **Redis 8 (Shared)** - Restore aus Datenpfad oder Pre-Cutover-Backup in isolierter Testinstanz pruefen
---
## 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
**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
**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. `5353`):
```yaml
ports:
- "5353:53/udp"
- "3001:3000/tcp"
volumes:
- /mnt/user/backups/restore-lab/adguard/conf:/opt/adguardhome/conf
```
4. `http://localhost:3001` erreichbar, Login moeglich
5. DNS-Aufloesung: `dig @127.0.0.1 -p 5353 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)
**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
**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.
docs/SECRETS_MAP.md
+9
View File
@@ -59,6 +59,9 @@ Dieses Dokument listet sensible Daten, deren Ablageorte und die vorgesehene Einb
| 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: | geplant: `D:\30_Finanzen\BitLocker-RecoveryKey-baerchen-<DATUM>.txt` + Vaultwarden Secure Note + physischer Ausdruck; aktuell BitLocker noch nicht aktiv | geplant |
---
@@ -108,6 +111,12 @@ 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/WEEKEND_EXECUTION_PLAN_2026-06-05.md
+151
View File
@@ -0,0 +1,151 @@
# 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
@@ -0,0 +1,41 @@
# 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.