Compare commits
10 Commits
9ca6e47472
...
2f3d184a3b
| Author | SHA1 | Date | |
|---|---|---|---|
| 2f3d184a3b | |||
| bc3ecad45a | |||
| 88a42f3f78 | |||
| af2c6ee533 | |||
| f382c25696 | |||
| d710a506e8 | |||
| 2ea65e906d | |||
| 2d438cf02b | |||
| 7ba10c893b | |||
| fb948ac951 |
@@ -28,3 +28,5 @@ Thumbs.db
|
||||
*.tmp
|
||||
*.log
|
||||
.serena/
|
||||
.claude/settings.local.json
|
||||
memory/
|
||||
|
||||
@@ -0,0 +1,22 @@
|
||||
### 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]
|
||||
@@ -0,0 +1,52 @@
|
||||
### 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
|
||||
@@ -0,0 +1,63 @@
|
||||
### 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.
|
||||
@@ -0,0 +1,58 @@
|
||||
### 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.
|
||||
@@ -0,0 +1,66 @@
|
||||
### 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]
|
||||
@@ -0,0 +1,45 @@
|
||||
### 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)
|
||||
+20
-2
@@ -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.
|
||||
|
||||
+4
-2
@@ -1,6 +1,6 @@
|
||||
# Alert Rules
|
||||
|
||||
Stand: 2026-05-31
|
||||
Stand: 2026-06-05
|
||||
|
||||
Diese Datei beschreibt die produktiven Alarmwege und wichtigsten Regeln. Die
|
||||
Konfiguration selbst liegt in `monitoring/prometheus/alerts.yml` und in den
|
||||
@@ -49,4 +49,6 @@ 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 bereits ueber `docker-critical-events.sh` gemeldet.
|
||||
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`.
|
||||
|
||||
@@ -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 |
|
||||
|
||||
@@ -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
|
||||
|
||||
---
|
||||
|
||||
|
||||
+58
-12
@@ -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
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
@@ -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 | Aktivierung vorbereitet: `services/posture-check/docker-critical-events-supervisor.sh` kapselt Start/Stop/Status/Smoke fuer das Unraid User Script. Optional spaeter in der Unraid-UI `at array start` aktivieren und ntfy-Smoke fahren; kein Pflicht-Pfad | `docs/SERVICE_CATALOG.md`, `services/posture-check/docker-critical-events.sh`, `services/posture-check/unraid-user-scripts.md` |
|
||||
| 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.
|
||||
+58
-11
@@ -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. |
|
||||
|
||||
+4
-1
@@ -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/`.
|
||||
|
||||
+159
-7
@@ -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.
|
||||
|
||||
@@ -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.
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -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` | 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` |
|
||||
| `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` |
|
||||
|
||||
## Backup- und Restore-Hinweise
|
||||
|
||||
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -0,0 +1,303 @@
|
||||
# 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.
|
||||
Executable
+125
@@ -0,0 +1,125 @@
|
||||
#!/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
|
||||
@@ -6,5 +6,6 @@ Diese Skripte sind bewusst versionierte Operator-Hilfen fuer den Windows-Neuaufs
|
||||
- `repair-disk0-boot-to-new-windows.ps1` repariert EFI/Bootdateien fuer das neue Windows auf der Intel-SSD und verlangt Adminrechte.
|
||||
- `cleanup-dualboot-bcd.ps1` bereinigt BCD-Bootmenueeintraege und verlangt eine explizite Textbestaetigung.
|
||||
- `ops/windows-reinstall/docs/windows-neuaufsetzen-masterplan.md` und `ops/windows-reinstall/docs/postinstall-erstes-ziel-codex.md` enthalten die zugehoerigen Operator-Notizen.
|
||||
- `ops/windows-reinstall/docs/postdelta-2026-06-04.md` dokumentiert den PostDelta-Stand vom 2026-06-04: aktuellster Banking4-Tresor, WISO-Ergaenzungen, Overwatch-2-Config, iCUE/Corsair-Maussettings und `D:\Users\michi`-Admincheck.
|
||||
|
||||
Die Skripte enthalten keine Secrets, arbeiten aber mit lokalen Windows-Datentraegern und duerfen nur interaktiv und mit vorheriger Sichtpruefung ausgefuehrt werden.
|
||||
|
||||
@@ -0,0 +1,81 @@
|
||||
param(
|
||||
[string]$BackupPath = "\\kallilabcore\backups\windows-images\baerchen",
|
||||
[string]$JobName = "baerchen-c-image",
|
||||
[string]$LogRoot = "C:\ProgramData\Veeam\Endpoint"
|
||||
)
|
||||
|
||||
$ErrorActionPreference = "Stop"
|
||||
|
||||
function Write-Section {
|
||||
param([string]$Title)
|
||||
Write-Host ""
|
||||
Write-Host "== $Title =="
|
||||
}
|
||||
|
||||
$result = [ordered]@{
|
||||
ComputerName = $env:COMPUTERNAME
|
||||
Timestamp = (Get-Date).ToString("s")
|
||||
JobName = $JobName
|
||||
BackupPath = $BackupPath
|
||||
VeeamService = $null
|
||||
BackupPathReachable = $false
|
||||
BackupFiles = @()
|
||||
LatestBackupFile = $null
|
||||
LatestJobEvidence = @()
|
||||
}
|
||||
|
||||
Write-Section "Veeam service"
|
||||
$service = Get-Service -Name VeeamEndpointBackupSvc -ErrorAction SilentlyContinue
|
||||
if ($service) {
|
||||
$result.VeeamService = $service.Status.ToString()
|
||||
$service | Select-Object Status,Name,DisplayName | Format-Table -AutoSize
|
||||
} else {
|
||||
$result.VeeamService = "missing"
|
||||
Write-Warning "VeeamEndpointBackupSvc not found"
|
||||
}
|
||||
|
||||
Write-Section "Backup target"
|
||||
if (Test-Path -LiteralPath $BackupPath) {
|
||||
$result.BackupPathReachable = $true
|
||||
$files = Get-ChildItem -LiteralPath $BackupPath -File -Recurse |
|
||||
Sort-Object LastWriteTime -Descending |
|
||||
Select-Object FullName,Length,LastWriteTime
|
||||
$result.BackupFiles = $files
|
||||
$result.LatestBackupFile = $files | Select-Object -First 1
|
||||
$files | Select-Object -First 20 | Format-Table -AutoSize
|
||||
} else {
|
||||
Write-Warning "Backup path is not reachable from this Windows session. This can be normal when Veeam uses stored job credentials and the interactive user has no active SMB session."
|
||||
}
|
||||
|
||||
Write-Section "Veeam job evidence"
|
||||
if (Test-Path -LiteralPath $LogRoot) {
|
||||
$logFiles = @(
|
||||
(Join-Path $LogRoot "Svc.VeeamEndpointBackup.log"),
|
||||
(Join-Path $LogRoot "UI.BackupJobWizard.log"),
|
||||
(Join-Path $LogRoot "UI.Tray-michi.log")
|
||||
) | Where-Object { Test-Path -LiteralPath $_ }
|
||||
|
||||
$patterns = @(
|
||||
[regex]::Escape("Job [$JobName] was started"),
|
||||
'Session result: "Success", job type: "EndpointBackup"',
|
||||
[regex]::Escape("Name: [$JobName]"),
|
||||
'Result: \[Success\]',
|
||||
'StorageEncryptionEnabled:\s+0',
|
||||
[regex]::Escape("Starting endpoint backup, job name = $JobName")
|
||||
) -join "|"
|
||||
|
||||
$evidence = Select-String -Path $logFiles -Pattern $patterns -CaseSensitive:$false -ErrorAction SilentlyContinue |
|
||||
Sort-Object Path,LineNumber |
|
||||
Select-Object -Last 30 @{Name = "File"; Expression = { Split-Path -Leaf $_.Path } },LineNumber,Line
|
||||
$result.LatestJobEvidence = $evidence
|
||||
$evidence | Format-List
|
||||
|
||||
if (-not ($evidence | Where-Object { $_.Line -match 'Result: \[Success\]|Session result: "Success"' })) {
|
||||
Write-Warning "No successful EndpointBackup session was found in the selected Veeam logs."
|
||||
}
|
||||
} else {
|
||||
Write-Warning "Veeam log root not found: $LogRoot"
|
||||
}
|
||||
|
||||
Write-Section "Summary"
|
||||
[pscustomobject]$result | Select-Object ComputerName,Timestamp,JobName,BackupPath,VeeamService,BackupPathReachable,LatestBackupFile | Format-List
|
||||
@@ -0,0 +1,132 @@
|
||||
# Boot-Cleanup-Plan 2026-06-04
|
||||
|
||||
## Ziel
|
||||
|
||||
`F:` ist das alte Windows und soll spaeter verschwinden. Vor Loeschen/Formatieren/Resize muss das neue Windows beweisen, dass es ohne `F:` bootet und keine BCD-/Resume-Abhaengigkeit mehr auf `F:` zeigt.
|
||||
|
||||
Noch keine Partition wird geloescht, formatiert oder erweitert.
|
||||
|
||||
## Aktueller Befund
|
||||
|
||||
- Neues Windows: `C:\WINDOWS`
|
||||
- Alter Loader: `Windows 11 Alt`
|
||||
- Alter Loader zeigt auf `partition=F:`
|
||||
- Alter Resume-Eintrag zeigt auf `partition=F:` und `F:\hiberfil.sys`
|
||||
- Boot Manager referenziert aktuell noch den alten Resume-Eintrag.
|
||||
- Aktives Pagefile ist nur `C:\pagefile.sys`.
|
||||
- `D:\pagefile.sys` und `E:\pagefile.sys` sind inaktive Altlasten, lassen sich aber ohne Adminrechte nicht entfernen.
|
||||
|
||||
## Vorbereitete Skripte
|
||||
|
||||
Im Arbeitsordner `C:\Users\michi\Documents\Neues Windows`:
|
||||
|
||||
- `boot-cleanup-freigabe-f-vorbereitung.ps1`
|
||||
- `start-boot-cleanup-admin.cmd`
|
||||
|
||||
Der Syntaxcheck des PowerShell-Skripts wurde ausgefuehrt. Es laedt korrekt und stoppt ohne Adminrechte erwartbar mit:
|
||||
|
||||
```text
|
||||
Dieses Skript muss als Administrator laufen.
|
||||
```
|
||||
|
||||
## Geplanter Admin-Block
|
||||
|
||||
Das Skript fuehrt mit Adminrechten aus:
|
||||
|
||||
1. Backupordner unter `C:\Temp\boot_cleanup_<timestamp>` anlegen.
|
||||
2. BCD, WinRE, Volumes, Partitionen und Pagefiles vor der Aenderung protokollieren.
|
||||
3. BCD exportieren nach `BCD-before-cleanup.bak`.
|
||||
4. `{bootmgr}` `resumeobject` auf den aktuellen C:-Resume-Eintrag setzen.
|
||||
5. Alten Loader `Windows 11 Alt` aus der Boot-Anzeige entfernen.
|
||||
6. Alten Loader loeschen.
|
||||
7. Alten F:-Resume-Eintrag loeschen.
|
||||
8. Inaktive Alt-Pagefiles `D:\pagefile.sys` und `E:\pagefile.sys` entfernen.
|
||||
9. BCD, WinRE und Pagefiles danach erneut protokollieren.
|
||||
|
||||
## Nicht enthalten
|
||||
|
||||
- Kein Loeschen von `F:`.
|
||||
- Kein Formatieren von `E:`.
|
||||
- Kein Resize von Partitionen.
|
||||
- Kein Entfernen von Recovery-Partitionen.
|
||||
- Kein Veraendern von `G:` / Homelab / EFI-Systempartition.
|
||||
|
||||
## Danach notwendig
|
||||
|
||||
1. Neustart.
|
||||
2. Pruefen, ob Windows sauber bootet.
|
||||
3. `bcdedit /enum all` pruefen: keine `partition=F:` Referenz mehr.
|
||||
4. Pagefiles pruefen: nur `C:\pagefile.sys` aktiv, `D:\pagefile.sys` und `E:\pagefile.sys` weg.
|
||||
5. Erst danach `F:` als technisch freigegeben markieren.
|
||||
|
||||
## Ausgefuehrt 2026-06-04 17:25
|
||||
|
||||
Der Admin-Block wurde ausgefuehrt. Log-/Backup-Ordner:
|
||||
|
||||
- `C:\Temp\boot_cleanup_20260604_172547`
|
||||
- BCD-Backup: `C:\Temp\boot_cleanup_20260604_172547\BCD-before-cleanup.bak`
|
||||
- Log: `C:\Temp\boot_cleanup_20260604_172547\boot_cleanup_log.txt`
|
||||
|
||||
Ergebnis laut Admin-Log:
|
||||
|
||||
- `{bootmgr}` `resumeobject` wurde auf den aktuellen C:-Resume-Eintrag `{f6daf1c6-6f16-11f0-992f-bc6ee2f9d6ec}` gesetzt.
|
||||
- `Windows 11 Alt` wurde aus `displayorder` entfernt.
|
||||
- Alter Loader `{f6daf1bd-6f16-11f0-992f-bc6ee2f9d6ec}` wurde geloescht.
|
||||
- Alter F:-Resume-Eintrag `{f6daf1bc-6f16-11f0-992f-bc6ee2f9d6ec}` war nach dem Loader-Cleanup bereits nicht mehr auffindbar.
|
||||
- `D:\pagefile.sys` wurde entfernt.
|
||||
- `E:\pagefile.sys` wurde entfernt.
|
||||
|
||||
After-BCD aus Admin-Log:
|
||||
|
||||
- `displayorder` enthaelt nur noch `{current}`.
|
||||
- `Windows 11 Neu` zeigt auf `device partition=C:` und `osdevice partition=C:`.
|
||||
- Resume zeigt auf `partition=C:`.
|
||||
- Im After-BCD-Log sind keine `partition=F:`-Eintraege mehr sichtbar.
|
||||
|
||||
After-Pagefiles:
|
||||
|
||||
- Aktiv: `C:\pagefile.sys`
|
||||
- Vorhanden: `C:\hiberfil.sys`, `C:\pagefile.sys`, `C:\swapfile.sys`
|
||||
- Alte Dateien auf `D:` und `E:` sind weg.
|
||||
- Auf `F:` liegen weiterhin alte `hiberfil.sys`/`swapfile.sys` des alten Windows; diese bleiben bis zur finalen F:-Bereinigung unangetastet.
|
||||
|
||||
Unabhaengige Nachpruefung aus normaler Codex-Shell:
|
||||
|
||||
- `D:` frei: ca. 126.3 GB
|
||||
- `E:` frei: ca. 629.5 GB
|
||||
- `Get-CimInstance Win32_PageFileUsage` meldet nur `C:\pagefile.sys`
|
||||
|
||||
Verbleibend nach Neustarttest:
|
||||
|
||||
- `F:` ist nach erfolgreichem Neustarttest technisch von der Boot-Konfiguration entkoppelt.
|
||||
- WinRE war nach dem Cleanup `Disabled`. **Erledigt 2026-06-05:** WinRE wurde im Admin-Nachlauf (siehe `laufwerks-neustruktur-2026-06-04.md` Abschnitt "Admin-Nachlauf 2026-06-05") mit `reagentc /setreimage` und `reagentc /enable` repariert und aktiviert. `Windows RE-Status: Enabled`, Version `10.0.26100.8455`.
|
||||
|
||||
## Neustarttest 2026-06-04 17:27
|
||||
|
||||
Nach dem Cleanup wurde Windows erfolgreich neu gestartet.
|
||||
|
||||
Post-Reboot-Status:
|
||||
|
||||
- `LastBootUpTime`: 2026-06-04 17:27:56
|
||||
- Neues Windows laeuft weiter von `C:\WINDOWS`.
|
||||
- `D:\pagefile.sys` und `E:\pagefile.sys` sind weiterhin weg.
|
||||
- Aktives Pagefile: `C:\pagefile.sys`
|
||||
|
||||
Post-Reboot-Bootreport:
|
||||
|
||||
- `C:\Temp\bcd_post_reboot_latest.txt`
|
||||
- `C:\Temp\winre_post_reboot_latest.txt`
|
||||
|
||||
Ergebnis:
|
||||
|
||||
- Keine sichtbare `partition=F:`-Referenz im BCD-Post-Reboot-Report.
|
||||
- `displayorder` enthaelt nur `{current}`.
|
||||
- `Windows 11 Neu` zeigt auf `device partition=C:` und `osdevice partition=C:`.
|
||||
- Resume zeigt auf `partition=C:`.
|
||||
- Historischer Post-Reboot-Stand war: WinRE blieb `Disabled`. Nachlauf
|
||||
2026-06-05: WinRE ist `Enabled`; siehe Erledigt-Hinweis oben.
|
||||
|
||||
Bewertung:
|
||||
|
||||
- `F:` ist aus Boot-/Resume-Sicht technisch freigegeben.
|
||||
- Partitionen wurden weiterhin nicht geloescht, formatiert oder erweitert.
|
||||
@@ -0,0 +1,325 @@
|
||||
# Laufwerks-Neustruktur 2026-06-04
|
||||
|
||||
## Ausgangslage
|
||||
|
||||
Neues Windows:
|
||||
|
||||
- SystemDrive: `C:`
|
||||
- Windows: `C:\WINDOWS`
|
||||
- Benutzer: `baerchen\michi`
|
||||
|
||||
Backup-Pfade wurden gefunden:
|
||||
|
||||
- `H:\Windows-Neuaufsetzen-Backup`
|
||||
- `H:\Windows-Neuaufsetzen-Backup\_PostDelta_2026-06-04_100146`
|
||||
|
||||
## Zielbild
|
||||
|
||||
| Laufwerk | Rolle |
|
||||
|---|---|
|
||||
| `C:` | Windows + kleine Programme |
|
||||
| `D:` | Daten & Projekte |
|
||||
| `E:` | Games |
|
||||
| `F:` | Altes Windows, spaeter loeschen und Platz an `E:` anhaengen |
|
||||
| `G:` | Arbeits-SSD, Homelab/Dev bleibt |
|
||||
| `H:` | Externe Backup-HDD, unveraendert |
|
||||
|
||||
## Phase 0: Read-only Status
|
||||
|
||||
Volumestatus nach nicht-destruktivem Umbau:
|
||||
|
||||
| Laufwerk | Label | Dateisystem | Groesse | Frei |
|
||||
|---|---|---|---:|---:|
|
||||
| `C:` | | NTFS | 166.9 GB | 63.1 GB |
|
||||
| `D:` | `Daten-Projekte` | NTFS | 167.7 GB | 116.8 GB |
|
||||
| `E:` | `Games` | NTFS | 638.5 GB | 602.5 GB |
|
||||
| `F:` | | NTFS | 292.1 GB | 45.6 GB |
|
||||
| `G:` | `M2 SSD` | NTFS | 930.9 GB | 121.5 GB |
|
||||
| `H:` | `Externe HDD` | NTFS | 7452.0 GB | 3801.3 GB |
|
||||
|
||||
Physische Datentraeger:
|
||||
|
||||
| Disk | Modell | Bus | Groesse | Partitionsstil | Status |
|
||||
|---:|---|---|---:|---|---|
|
||||
| 0 | INTEL SSDSC2BW180A3L | SATA | 168 GB | GPT | Healthy |
|
||||
| 1 | INTEL SSDSC2BW180A3L | SATA | 168 GB | GPT | Healthy |
|
||||
| 2 | Samsung SSD 980 PRO 1TB | NVMe | 932 GB | GPT | Healthy |
|
||||
| 3 | WDC WDS100T2B0C | NVMe | 932 GB | GPT | Healthy |
|
||||
| 4 | asmedia ASM235 | USB | 7452 GB | GPT | Healthy |
|
||||
|
||||
Partitionen:
|
||||
|
||||
| Disk | Partition | Laufwerk | Groesse | Typ |
|
||||
|---:|---:|---|---:|---|
|
||||
| 0 | 1 | | 0.0 GB | Reserved |
|
||||
| 0 | 2 | `C:` | 166.9 GB | Basic |
|
||||
| 0 | 3 | | 0.8 GB | Recovery |
|
||||
| 1 | 1 | | 0.0 GB | Reserved |
|
||||
| 1 | 2 | `D:` | 167.7 GB | Basic |
|
||||
| 2 | 1 | | 0.0 GB | Reserved |
|
||||
| 2 | 2 | `E:` | 638.5 GB | Basic |
|
||||
| 2 | 3 | `F:` | 292.1 GB | Basic |
|
||||
| 2 | 4 | | 0.9 GB | Recovery |
|
||||
| 3 | 1 | | 0.1 GB | System |
|
||||
| 3 | 2 | | 0.0 GB | Reserved |
|
||||
| 3 | 3 | `G:` | 930.9 GB | Basic |
|
||||
| 3 | 4 | | 0.5 GB | Recovery |
|
||||
| 4 | 1 | | 0.0 GB | Reserved |
|
||||
| 4 | 2 | `H:` | 7452.0 GB | Basic |
|
||||
|
||||
## Phase 1: Gate `F -> E`
|
||||
|
||||
Technische Lage:
|
||||
|
||||
- `E:` und `F:` liegen beide auf Disk 2, Samsung SSD 980 PRO 1TB.
|
||||
- `F:` ist Partition 3 und liegt direkt hinter `E:` Partition 2.
|
||||
- Danach folgt noch eine Recovery-Partition.
|
||||
- Rein vom Layout her waere `F loeschen, E erweitern` grundsaetzlich moeglich.
|
||||
|
||||
Blocker:
|
||||
|
||||
- BCD enthaelt noch den Booteintrag `Windows 11 Alt` mit `device partition=F:` und `osdevice partition=F:`.
|
||||
- BCD enthaelt auch einen Resume-Eintrag fuer `F:`.
|
||||
|
||||
Entscheidung:
|
||||
|
||||
- `F:` wurde nicht geloescht.
|
||||
- Keine Formatierung, kein Resize, kein BCD-Cleanup.
|
||||
- Destruktive Phase bleibt gesperrt bis zur ausdruecklichen Bestaetigung und einem separaten Boot-Cleanup-Plan.
|
||||
|
||||
## Phase 2: Spiele-/Launcher-Bestand
|
||||
|
||||
| Name | Quelle | Groesse | Dateien |
|
||||
|---|---|---:|---:|
|
||||
| Battle.net | `D:\Battle.net` | 1.99 GB | 1162 |
|
||||
| Hearthstone | `D:\Hearthstone` | 11.75 GB | 5148 |
|
||||
| Overwatch | `D:\Overwatch` | 0.20 GB | 22 |
|
||||
| Steam2 | `D:\Steam2` | 22.83 GB | 14992 |
|
||||
| World of Warcraft II | `D:\World of Warcraft II` | 0.13 GB | 7882 |
|
||||
| WOW INTERFACE | `D:\WOW INTERFACE` | 0.46 GB | 28198 |
|
||||
| Games | `G:\Games` | 298.06 GB | 20675 |
|
||||
| SteamLibrary | `G:\SteamLibrary` | 446.26 GB | 39228 |
|
||||
|
||||
Noch nicht verschoben:
|
||||
|
||||
- Battle.net / Overwatch wird spaeter separat behandelt.
|
||||
- Docker Desktop wird spaeter separat behandelt.
|
||||
- `G:\Gitea_Clone\homelab-infra` bleibt unangetastet.
|
||||
|
||||
## Phase 3: Nicht-destruktiver Umbau
|
||||
|
||||
Angelegt auf `D:`:
|
||||
|
||||
- `D:\00_Inbox`
|
||||
- `D:\10_Dokumente`
|
||||
- `D:\11_Bilder`
|
||||
- `D:\12_Videos`
|
||||
- `D:\13_Musik`
|
||||
- `D:\14_Downloads`
|
||||
- `D:\20_Projekte\aktiv`
|
||||
- `D:\20_Projekte\archiv`
|
||||
- `D:\30_Finanzen\Banking4`
|
||||
- `D:\30_Finanzen\WISO_Steuer`
|
||||
- `D:\90_Archiv`
|
||||
|
||||
Angelegt auf `E:`:
|
||||
|
||||
- `E:\Steam\steamapps`
|
||||
- `E:\BattleNet`
|
||||
- `E:\EpicGames`
|
||||
- `E:\EA`
|
||||
- `E:\Riot`
|
||||
- `E:\Ubisoft`
|
||||
- `E:\_Standalone`
|
||||
|
||||
Angelegt auf `G:`:
|
||||
|
||||
- `G:\repos`
|
||||
- `G:\tools`
|
||||
|
||||
Windows-Bekanntordner:
|
||||
|
||||
| Known Folder | Ziel |
|
||||
|---|---|
|
||||
| Desktop | `D:\00_Inbox\Desktop` |
|
||||
| Dokumente | `D:\10_Dokumente` |
|
||||
| Downloads | `D:\14_Downloads` |
|
||||
| Bilder | `D:\11_Bilder` |
|
||||
| Musik | `D:\13_Musik` |
|
||||
| Videos | `D:\12_Videos` |
|
||||
|
||||
Kopiert, ohne Quellen zu loeschen:
|
||||
|
||||
- `D:\Micha\Dokumente` nach `D:\10_Dokumente`
|
||||
- `D:\Micha\Bilder` nach `D:\11_Bilder`
|
||||
- `D:\Micha\Videos` nach `D:\12_Videos`
|
||||
- `D:\Micha\Musik` nach `D:\13_Musik`
|
||||
- `D:\Micha\Downloads` nach `D:\14_Downloads`
|
||||
- `D:\Micha\Finanzen` nach `D:\30_Finanzen`
|
||||
- Aktueller Banking4-Tresor aus PostDelta nach `D:\30_Finanzen\Banking4`
|
||||
|
||||
Labels:
|
||||
|
||||
- `D:` von `Blizzard Games` auf `Daten-Projekte`
|
||||
- `E:` von `980SSD` auf `Games`
|
||||
- `H:` unveraendert
|
||||
|
||||
## Log-Dateien
|
||||
|
||||
- `C:\Temp\disk_report.txt`
|
||||
- `C:\Temp\disk_report_after_latest.txt`
|
||||
- `C:\Temp\bcd_report.txt`
|
||||
- `C:\Temp\bcd_report_after_latest.txt`
|
||||
- `C:\Temp\winre_report_after_latest.txt`
|
||||
- `C:\Temp\spiele_inventory_2026-06-04.csv`
|
||||
- `C:\Temp\laufwerks_neustruktur_log_2026-06-04.txt`
|
||||
|
||||
## Review-Abgleich nach Claude-Hinweis
|
||||
|
||||
Am 2026-06-04 wurde nach dem externen Review ein frischer Nachher-Snapshot erzeugt:
|
||||
|
||||
- `C:\Temp\disk_report_after_20260604_143928.txt`
|
||||
- `C:\Temp\disk_report_after_latest.txt`
|
||||
- `C:\Temp\bcd_report_after_latest.txt`
|
||||
- `C:\Temp\winre_report_after_latest.txt`
|
||||
|
||||
Damit ist die vorherige Doku-Luecke geschlossen: Der urspruengliche `disk_report.txt` war vor der Label-Aenderung entstanden. Der neue Report bestaetigt:
|
||||
|
||||
- `D:` Label `Daten-Projekte`
|
||||
- `E:` Label `Games`
|
||||
- `C:`, `D:`, `E:`, `F:`, `G:` und `H:` sind `Healthy`
|
||||
- Known Folders zeigen auf die neue Struktur:
|
||||
- Desktop: `D:\00_Inbox\Desktop`
|
||||
- Dokumente: `D:\10_Dokumente`
|
||||
- Downloads: `D:\14_Downloads`
|
||||
- Bilder: `D:\11_Bilder`
|
||||
- Musik: `D:\13_Musik`
|
||||
- Videos: `D:\12_Videos`
|
||||
|
||||
Desktop-Befund:
|
||||
|
||||
- Der Desktop wurde nach dem Review bewusst auf `D:\00_Inbox\Desktop` gelegt.
|
||||
- `D:\Micha\Desktop` ist veraltet und soll nicht mehr als Known-Folder-Ziel verwendet werden.
|
||||
|
||||
Zusatzbefund Boot/Resume:
|
||||
|
||||
- `F:` haengt nicht nur am Loader `Windows 11 Alt`, sondern auch am Resume-Eintrag `{f6daf1bc-6f16-11f0-992f-bc6ee2f9d6ec}`.
|
||||
- Der Windows-Start-Manager referenziert diesen alten Resume-Eintrag ebenfalls als `resumeobject`.
|
||||
- Der Stop fuer alle destruktiven Schritte an `F:` bleibt dadurch noch staerker begruendet.
|
||||
|
||||
WinRE-Befund:
|
||||
|
||||
- `reagentc /info` meldet: `Windows RE-Status: Disabled`.
|
||||
- WinRE wird separat in der Windows-Idealkonfiguration behandelt, bevor Boot-/Partitionsbereinigung freigegeben wird.
|
||||
|
||||
Kopier-/Doppelbestand:
|
||||
|
||||
- Die Inhalte aus `D:\Micha\*` wurden abgeglichen und in die neue Nummernstruktur ueberfuehrt.
|
||||
- Es besteht kein gewollter Doppelbestand mehr.
|
||||
- `D:\Micha\Videos\NVIDIA` kann von NVIDIA/Overlay-Komponenten leer neu angelegt werden und ist kein Datenbestand.
|
||||
|
||||
## Offene Punkte
|
||||
|
||||
- ~~WinRE/Secure Boot/TPM Admin-Check~~ **Erledigt 2026-06-05** (siehe Abschnitt "Admin-Nachlauf 2026-06-05"): WinRE aktiviert, Secure Boot `True`, TPM ready/enabled.
|
||||
- **BitLocker-Entscheidung offen:** Alle Laufwerke `FullyDecrypted`, Protection `Off`. Vor Aktivierung: Recovery Keys fuer mindestens `C:` und `D:` an drei Orten sichern (Vaultwarden, `D:\30_Finanzen\BitLocker-RecoveryKey-baerchen-<DATUM>.txt`, physisch). Verweis: `docs/MASTER_TODO.md` Abschnitt "Windows / Workstation baerchen".
|
||||
- Optional: `D:\11_Bilder` ReadOnly-Attribut beobachten; fuer Windows-Shell-Ordner ist das in der Praxis meist unkritisch.
|
||||
- Optional: `D:\13_Musik` bleibt leer, solange aus dem Backup keine Musikdaten nachgezogen werden muessen.
|
||||
- Optional: `G:\Apps`, `G:\Workspace`, `D:\WSL` in der Homelab-/Dev-Doku ergaenzen.
|
||||
|
||||
## E/F-Finalisierung 2026-06-04 17:33
|
||||
|
||||
Nach erfolgreichem Boot-Cleanup und Neustarttest wurde die E/F-Phase ausgefuehrt.
|
||||
|
||||
Vor dem Formatieren von `E:` wurden dort gefundene Nicht-Games-Daten nach `D:` gesichert:
|
||||
|
||||
- Quelle: `E:\BMW Leasing`
|
||||
- Quelle: `E:\Marina Handy 2025`
|
||||
- Quelle: `E:\Marina Handy Backup`
|
||||
- Ziel: `D:\90_Archiv\E_vor_Format_20260604_173209`
|
||||
|
||||
Der Datei-/Groessenabgleich war stimmig:
|
||||
|
||||
- `BMW Leasing`: 9 Dateien, ca. 0.01 GB
|
||||
- `Marina Handy 2025`: 7119 Dateien, ca. 8.83 GB
|
||||
- `Marina Handy Backup`: 0 Dateien
|
||||
|
||||
Admin-Log:
|
||||
|
||||
- `C:\Temp\final_ef_partition_20260604_173349\final_ef_partition_log.txt`
|
||||
|
||||
Durchgefuehrt:
|
||||
|
||||
- `E:` schnell formatiert als NTFS mit Label `Games`
|
||||
- `F:` Partition entfernt
|
||||
- `E:` auf den frei gewordenen Bereich erweitert
|
||||
- Games-Struktur auf `E:` neu angelegt
|
||||
|
||||
Finaler Stand:
|
||||
|
||||
| Laufwerk | Label | Groesse | Frei | Status |
|
||||
|---|---|---:|---:|---|
|
||||
| `E:` | `Games` | 930.6 GB | 930.5 GB | Healthy |
|
||||
|
||||
`F:` ist nicht mehr als Volume vorhanden.
|
||||
|
||||
Aktuelles Disk-2-Layout:
|
||||
|
||||
| Disk | Partition | Laufwerk | Groesse | Typ |
|
||||
|---:|---:|---|---:|---|
|
||||
| 2 | 1 | | 0.0 GB | Reserved |
|
||||
| 2 | 2 | `E:` | 930.6 GB | Basic |
|
||||
| 2 | 4 | | 0.9 GB | Recovery |
|
||||
|
||||
Overwatch-Config wurde zurueckkopiert:
|
||||
|
||||
- Quelle: `H:\Windows-Neuaufsetzen-Backup\_PostDelta_2026-06-04_100146\16_Overwatch2_Config\Documents_Overwatch`
|
||||
- Ziel: `D:\10_Dokumente\Overwatch`
|
||||
- `D:\10_Dokumente\Overwatch\Settings\Settings_v0.ini` vorhanden
|
||||
|
||||
Battle.net:
|
||||
|
||||
- Offizieller Blizzard-Installer wurde geladen nach `D:\Software\Installer\BattleNet\Battle.net-Setup.exe`
|
||||
- Authenticode-Signatur: gueltig, Herausgeber `Blizzard Entertainment, Inc.`
|
||||
- Installer wurde gestartet; Installation/Anmeldung laeuft per GUI.
|
||||
|
||||
## Abschluss-Audit 2026-06-05
|
||||
|
||||
Nach dem Abschluss-Audit wurden folgende Punkte bereinigt oder festgehalten:
|
||||
|
||||
- `E:\_Standalone` wurde angelegt.
|
||||
- `D:\Micha` enthaelt keinen migrierten Datenbestand mehr. Ein leerer Pfad `D:\Micha\Videos\NVIDIA` kann durch NVIDIA/Overlay-Komponenten neu entstehen.
|
||||
- Known Folders:
|
||||
- Desktop: `D:\00_Inbox\Desktop`
|
||||
- Dokumente: `D:\10_Dokumente`
|
||||
- Downloads: `D:\14_Downloads`
|
||||
- Bilder: `D:\11_Bilder`
|
||||
- Musik: `D:\13_Musik`
|
||||
- Videos: `D:\12_Videos`
|
||||
- Energieplan wurde auf `Ultimative Leistung` gesetzt.
|
||||
- SSH-Key-Rechte fuer `C:\Users\michi\.ssh\id_ed25519` wurden auf `BAERCHEN\michi:(F)` reduziert.
|
||||
- OneDrive-Benutzer-Tasks `Reporting` und `Startup` wurden deaktiviert. Der globale Per-Machine-Updater benoetigt Adminrechte.
|
||||
- `SoftLanding\CreativeManagementTask` war beim Nachcheck nicht vorhanden.
|
||||
- Docker Desktop laeuft; Docker-WSL-Daten liegen physisch unter `G:\tools\ai\docker\wsl`. Der alte Pfad `C:\Users\michi\AppData\Local\Docker\wsl` ist eine Junction auf diesen Zielpfad.
|
||||
- Ollama nutzt `G:\tools\ai\ollama`; Open WebUI-Daten liegen unter `G:\tools\ai\open-webui`.
|
||||
- Open WebUI laeuft unter `http://localhost:3000` und sieht die Ollama-Modelle.
|
||||
|
||||
Admin-Nachlauf 2026-06-05:
|
||||
|
||||
- WinRE wurde repariert und aktiviert:
|
||||
- `Winre.wim` gefunden unter `C:\Windows\System32\Recovery\Winre.wim`
|
||||
- `reagentc /setreimage /path C:\Windows\System32\Recovery /target C:\Windows`
|
||||
- `reagentc /enable`
|
||||
- Ergebnis: `Windows RE-Status: Enabled`, Version `10.0.26100.8455`
|
||||
- Secure Boot: `True`
|
||||
- TPM: vorhanden, ready, enabled, activated, owned
|
||||
- BitLocker-Status geprueft:
|
||||
- `C:`, `D:`, `E:`, `G:`, `H:` sind `FullyDecrypted`, Protection `Off`
|
||||
- BitLocker wurde nicht automatisch aktiviert, weil dafuer eine bewusste Recovery-Key- und Lockout-Entscheidung noetig ist.
|
||||
- OneDrive Per-Machine Standalone Update Task wurde deaktiviert.
|
||||
- SSH-Aliases angelegt und getestet:
|
||||
- `kallilabcore` -> `root@100.80.98.33`
|
||||
- `kallilabcore-lan` -> `root@192.168.178.58`
|
||||
|
||||
Weiter offen:
|
||||
|
||||
- BitLocker-Entscheidung fuer mindestens `C:` und `D:` treffen. Vor Aktivierung Recovery Keys extern sichern.
|
||||
@@ -0,0 +1,148 @@
|
||||
# PostDelta 2026-06-04
|
||||
|
||||
Diese Datei dokumentiert das Delta, das nach dem urspruenglichen Windows-Neuaufsetzen-Plan und nach `_Delta_2026-05-19` entstanden ist.
|
||||
|
||||
Sie ist die Git-Repo-Kopie von:
|
||||
|
||||
```text
|
||||
H:\Windows-Neuaufsetzen-Backup\HANDOFF_2026-06-04.md
|
||||
```
|
||||
|
||||
## Kontext
|
||||
|
||||
- Der Benutzer war am 2026-06-04 noch im alten Windows gebootet.
|
||||
- Aus Sicht des alten Windows war:
|
||||
- altes Windows = `C:\WINDOWS`
|
||||
- neues Windows vermutlich = `D:\Windows`
|
||||
- Nach Boot ins neue Windows koennen sich Laufwerksbuchstaben aendern.
|
||||
- Vor jedem Restore oder Cleanup zuerst `Get-Volume`, `Get-Disk`, `Get-Partition`, `$env:SystemDrive` und `$env:windir` pruefen.
|
||||
|
||||
## Relevante Backup-Schichten
|
||||
|
||||
```text
|
||||
H:\Windows-Neuaufsetzen-Backup
|
||||
H:\Windows-Neuaufsetzen-Backup\_Delta_2026-05-19
|
||||
H:\Windows-Neuaufsetzen-Backup\_PostDelta_2026-06-04_100146
|
||||
```
|
||||
|
||||
Das PostDelta ist fuer aktuelle Daten zwingend mitzuberuecksichtigen.
|
||||
|
||||
## PostDelta-Inhalte
|
||||
|
||||
PostDelta-Ziel:
|
||||
|
||||
```text
|
||||
H:\Windows-Neuaufsetzen-Backup\_PostDelta_2026-06-04_100146
|
||||
```
|
||||
|
||||
Wichtige Unterordner:
|
||||
|
||||
- `00_Kritisch_Direkt`
|
||||
- `01_Desktop`
|
||||
- `02_Dokumente`
|
||||
- `03_Bilder`
|
||||
- `05_Downloads`
|
||||
- `09_Programme_Settings_Lizenzen`
|
||||
- `16_Overwatch2_Config`
|
||||
- `17_Maus_Settings`
|
||||
- `18_D_Users_michi_AdminCheck`
|
||||
|
||||
## Banking4
|
||||
|
||||
Aktuellster bekannter Tresor:
|
||||
|
||||
```text
|
||||
H:\Windows-Neuaufsetzen-Backup\_PostDelta_2026-06-04_100146\00_Kritisch_Direkt\Mein Datentresor.sub
|
||||
H:\Windows-Neuaufsetzen-Backup\_PostDelta_2026-06-04_100146\00_Kritisch_Direkt\.Mein Datentresor.sub.att
|
||||
```
|
||||
|
||||
Hash-verifiziert:
|
||||
|
||||
```text
|
||||
Mein Datentresor.sub
|
||||
SHA256 F22224B7A765046D4B76D71C1E296DA59D8D8A849A41A12E5C10254DF0EC71AD
|
||||
|
||||
.Mein Datentresor.sub.att
|
||||
SHA256 3FC5D0BD8B673975F9C42F4ED53278CFF434ED21E266B8B60589288A2FF9F4D8
|
||||
```
|
||||
|
||||
Der aeltere Banking4-Tresor aus Hauptbackup/Delta ist nicht mehr der neueste Stand.
|
||||
|
||||
Lizenz:
|
||||
|
||||
```text
|
||||
H:\Windows-Neuaufsetzen-Backup\09_Programme_Settings_Lizenzen\keys_exporte\banking4_license_private.txt
|
||||
```
|
||||
|
||||
## WISO Steuer
|
||||
|
||||
Hauptbackup:
|
||||
|
||||
```text
|
||||
H:\Windows-Neuaufsetzen-Backup\07_Banking_Finanzen\WISO_Steuer_Dokumente
|
||||
```
|
||||
|
||||
PostDelta:
|
||||
|
||||
```text
|
||||
H:\Windows-Neuaufsetzen-Backup\_PostDelta_2026-06-04_100146\02_Dokumente\steuer
|
||||
```
|
||||
|
||||
PostDelta enthaelt 8 Steuerdateien inklusive einer Pia-Marie-Datei.
|
||||
|
||||
## Overwatch 2
|
||||
|
||||
PostDelta:
|
||||
|
||||
```text
|
||||
H:\Windows-Neuaufsetzen-Backup\_PostDelta_2026-06-04_100146\16_Overwatch2_Config
|
||||
```
|
||||
|
||||
Wichtig:
|
||||
|
||||
```text
|
||||
16_Overwatch2_Config\Documents_Overwatch\Settings\Settings_v0.ini
|
||||
```
|
||||
|
||||
Beim Backup war nur `Overwatch.log` gesperrt; das ist eine Logdatei.
|
||||
|
||||
## Maus / iCUE
|
||||
|
||||
PostDelta:
|
||||
|
||||
```text
|
||||
H:\Windows-Neuaufsetzen-Backup\_PostDelta_2026-06-04_100146\17_Maus_Settings
|
||||
```
|
||||
|
||||
Enthaelt Corsair/iCUE-bezogene AppData/ProgramData, Registry-Exports und Windows-Mauswerte.
|
||||
|
||||
## D:\Users\michi Admincheck
|
||||
|
||||
Bericht:
|
||||
|
||||
```text
|
||||
H:\Windows-Neuaufsetzen-Backup\_PostDelta_2026-06-04_100146\18_D_Users_michi_AdminCheck
|
||||
```
|
||||
|
||||
Ergebnis:
|
||||
|
||||
- 6565 Dateien
|
||||
- 2950 Ordner
|
||||
- ca. 1.58 GB
|
||||
- 0 rekursive Zugriffsfehler
|
||||
- Standardordner praktisch leer
|
||||
- fast alles AppData/Windows-Package-Kram
|
||||
|
||||
Interpretation: aus alter Windows-Sicht keine wichtigen persoenlichen Daten in `D:\Users\michi`.
|
||||
|
||||
## Reihenfolge im neuen Windows
|
||||
|
||||
1. Laufwerksbuchstaben und gebootetes Windows pruefen.
|
||||
2. Alle drei Backup-Schichten pruefen.
|
||||
3. Banking4 mit PostDelta-Tresor wiederherstellen.
|
||||
4. WISO mit Hauptbackup plus PostDelta pruefen.
|
||||
5. Dokumente/Desktop/Bilder/Downloads migrieren.
|
||||
6. Overwatch 2 und iCUE/Corsair gezielt wiederherstellen.
|
||||
7. SSH/Git/Homelab wiederherstellen.
|
||||
8. Erst danach Windows-Idealkonfiguration, Bootcleanup und Formatierungen.
|
||||
|
||||
@@ -0,0 +1,255 @@
|
||||
# Programme-Entscheidungs-Checkliste fuer den Windows-Wiederaufbau
|
||||
|
||||
Stand: 2026-06-04
|
||||
Quelle: `H:\Windows-Neuaufsetzen-Backup\12_Exportierte_Listen\installierte_programme.csv` (161 Eintraege, Registry-Export vom 2026-05-07)
|
||||
Winget-Abdeckung: `H:\Windows-Neuaufsetzen-Backup\12_Exportierte_Listen\winget-export.json`
|
||||
Uebergeordneter Kontext: [HANDOFF_2026-06-04.md](../../../../H:/Windows-Neuaufsetzen-Backup/HANDOFF_2026-06-04.md) sowie [postdelta-2026-06-04.md](postdelta-2026-06-04.md)
|
||||
|
||||
## Wofuer ist diese Datei
|
||||
|
||||
Vorgefilterte Sortierung aller 161 installierten Programme in drei Toepfe, damit der Wiederaufbau im neuen Windows nicht 161 Einzelentscheidungen braucht.
|
||||
|
||||
**So nutzt sie der neue Codex/Claude:**
|
||||
|
||||
1. **Auto-Ja** (18 Eintraege): alle winget-IDs werden in einem Skript-Lauf installiert, ein User-OK reicht.
|
||||
2. **Einzelfrage** (38 Eintraege): jeden Eintrag mit Micha durchgehen, pro Eintrag `j` / `n` / `spaeter`. Hier sitzen die Lizenzen, Logins und Config-Restores.
|
||||
3. **Auto-Skip** (105 Eintraege): nur Sichtkontrolle, default ueberspringen. Sind Treiber-Bundles, Runtimes, Duplikate, Bloatware.
|
||||
|
||||
Summe: 161 == 161, keine Duplikate doppelt klassifiziert (Registry-Hive-Duplikate landen automatisch in Auto-Skip).
|
||||
|
||||
---
|
||||
|
||||
## 1. Auto-Ja (18)
|
||||
|
||||
Standard-Tools ohne Login/Lizenz, alle ueber `winget` installierbar. Im neuen Windows als Sammel-Befehl ausfuehrbar:
|
||||
|
||||
```powershell
|
||||
winget install --exact --id Brave.Brave --source winget --accept-package-agreements --accept-source-agreements
|
||||
winget install --exact --id CPUID.CPU-Z.MSI --source winget --accept-package-agreements --accept-source-agreements
|
||||
winget install --exact --id CPUID.HWMonitor --source winget --accept-package-agreements --accept-source-agreements
|
||||
winget install --exact --id CrystalDewWorld.CrystalDiskInfo --source winget --accept-package-agreements --accept-source-agreements
|
||||
winget install --exact --id Futuremark.3DMark --source winget --accept-package-agreements --accept-source-agreements
|
||||
winget install --exact --id Git.Git --source winget --accept-package-agreements --accept-source-agreements
|
||||
winget install --exact --id GoLang.Go --source winget --accept-package-agreements --accept-source-agreements
|
||||
winget install --exact --id Governikus.AusweisApp --source winget --accept-package-agreements --accept-source-agreements
|
||||
winget install --exact --id Guru3D.RTSS --source winget --accept-package-agreements --accept-source-agreements
|
||||
winget install --exact --id HulubuluSoftware.AdvancedRenamer --source winget --accept-package-agreements --accept-source-agreements
|
||||
winget install --exact --id LimeTechnology.UnraidUSBCreator --source winget --accept-package-agreements --accept-source-agreements
|
||||
winget install --exact --id MaxCut.MaxCut --source winget --accept-package-agreements --accept-source-agreements
|
||||
winget install --exact --id OpenJS.NodeJS.LTS --source winget --accept-package-agreements --accept-source-agreements
|
||||
winget install --exact --id Python.Launcher --source winget --accept-package-agreements --accept-source-agreements
|
||||
winget install --exact --id Python.Python.3.13 --source winget --accept-package-agreements --accept-source-agreements
|
||||
winget install --exact --id buchen.portfolio --source winget --accept-package-agreements --accept-source-agreements
|
||||
winget install --exact --id den4b.ReNamer --source winget --accept-package-agreements --accept-source-agreements
|
||||
winget install --exact --id fjsoft.MyPhoneExplorer --source winget --accept-package-agreements --accept-source-agreements
|
||||
```
|
||||
|
||||
| DisplayName | Version | Publisher | winget-ID | Begruendung |
|
||||
|---|---|---|---|---|
|
||||
| 3DMark | 2.22.7359.0 | UL | Futuremark.3DMark | Benchmark, kein Login |
|
||||
| Advanced Renamer | 3.95 | Hulubulu Software | HulubuluSoftware.AdvancedRenamer | Free Rename-Tool |
|
||||
| AusweisApp | 2.4.0 | Governikus GmbH & Co. KG | Governikus.AusweisApp | Online-Ausweis, kein Login |
|
||||
| Brave | 147.1.89.145 | Die Brave-Autoren | Brave.Brave | Browser (Sync optional spaeter) |
|
||||
| CPUID CPU-Z MSI 2.03 | 2.03 | CPUID, Inc. | CPUID.CPU-Z.MSI | System-Info-Tool |
|
||||
| CPUID HWMonitor 1.60 | 1.60 | CPUID, Inc. | CPUID.HWMonitor | Hardware-Monitor |
|
||||
| CrystalDiskInfo 9.8.0 | 9.8.0 | Crystal Dew World | CrystalDewWorld.CrystalDiskInfo | SSD/HDD-Health-Check |
|
||||
| Git | 2.53.0.2 | The Git Development Community | Git.Git | Dev-Tool (SSH-Key wird separat aus Backup zurueckgeholt) |
|
||||
| Go Programming Language amd64 go1.26.1 | 1.26.1 | https://go.dev | GoLang.Go | Dev-Tool |
|
||||
| MaxCut | 2.9.3.9 | MaxCut Software Ltd | MaxCut.MaxCut | Plattenoptimierungs-Tool, free |
|
||||
| MyPhoneExplorer | 2.3 | F.J. Wechselberger | fjsoft.MyPhoneExplorer | Android-Sync-Tool |
|
||||
| Node.js | 24.15.0 | Node.js Foundation | OpenJS.NodeJS.LTS | Dev-Tool |
|
||||
| Portfolio Performance | 0.76.3 | Andreas Buchen | buchen.portfolio | Open Source, Daten aus Backup |
|
||||
| Python 3.13.3 Core Interpreter (64-bit) | 3.13.3150.0 | Python Software Foundation | Python.Python.3.13 | Python 3.13 — Python.Python.3.13 deckt das gesamte Bundle ab |
|
||||
| Python Launcher | 3.13.3150.0 | Python Software Foundation | Python.Launcher | Dev-Tool |
|
||||
| ReNamer | 7.7.0.0 | den4b Team | den4b.ReNamer | Free Rename-Tool |
|
||||
| RivaTuner Statistics Server 7.3.7 | 7.3.7 | Unwinder | Guru3D.RTSS | OSD fuer Spiele (kommt mit MSI Afterburner) |
|
||||
| Unraid USB Creator | 1.1.0 | Lime Technology, Inc | LimeTechnology.UnraidUSBCreator | Homelab-Tool |
|
||||
|
||||
---
|
||||
|
||||
## 2. Einzelfrage (38)
|
||||
|
||||
Brauchen Lizenz, Login, Konfig-Restore oder explizite Ja/Nein-Entscheidung. **Pro Eintrag mit Micha klaeren.** Die "KRITISCH"-Eintraege haben Vorrang.
|
||||
|
||||
Reihenfolge-Empfehlung (aus `HANDOFF_2026-06-04.md`):
|
||||
|
||||
1. NVIDIA App (zuerst — bringt alle NVIDIA-Komponenten im Bundle)
|
||||
2. Microsoft 365 (M-Konto)
|
||||
3. Banking4 + Tresor aus PostDelta
|
||||
4. WISO Steuer 2026 + Steuerdateien aus PostDelta
|
||||
5. WSL + Distros (Ubuntu.tar / docker-desktop.tar)
|
||||
6. Tailscale (Login)
|
||||
7. Browser (Google Chrome / Brave mit Sync)
|
||||
8. Corsair iCUE (Mausprofile aus PostDelta)
|
||||
9. Battle.net + Overwatch 2 Config aus PostDelta
|
||||
10. Rest in beliebiger Reihenfolge
|
||||
|
||||
| DisplayName | Version | Publisher | winget-ID | Begruendung |
|
||||
|---|---|---|---|---|
|
||||
| Adobe Acrobat (64-bit) | 26.001.21529 | Adobe | Adobe.Acrobat.Pro | Adobe-Lizenz/Subscription pruefen |
|
||||
| Adobe Refresh Manager | 1.8.0 | Adobe Systems Incorporated | | Adobe-Komponente, nur falls Acrobat installiert |
|
||||
| AIDA64 Extreme v6.85 | 6.85 | FinalWire Ltd. | FinalWire.AIDA64.Extreme | Kostenpflichtige Lizenz |
|
||||
| Android Studio | 2024.3 | Google LLC | Google.AndroidStudio | Sehr gross — nur falls Android-Dev gebraucht |
|
||||
| Ant Movie Catalog | 4.2.2.2 | Ant Software | | Spezial-Tool, kein winget |
|
||||
| Banking4 Home | | Subsembly GmbH | | KRITISCH: Lizenz aus 09_Programme_Settings_Lizenzen\keys_exporte\banking4_license_private.txt + Tresor aus _PostDelta_2026-06-04_100146\00_Kritisch_Direkt |
|
||||
| Battle.net | | Blizzard Entertainment | | Launcher fuer Blizzard-Spiele (Overwatch 2 + WoW + Hearthstone). Overwatch-Config aus _PostDelta\16_Overwatch2_Config |
|
||||
| Corsair iCUE5 Software | 5.44.55 | Corsair | Corsair.iCUE.5 | Mausprofile aus _PostDelta_2026-06-04_100146\17_Maus_Settings |
|
||||
| Docker Desktop | 4.67.0 | Docker Inc. | Docker.DockerDesktop | WSL2-basiert, viele Configs. Bewusste Entscheidung ob noetig |
|
||||
| EMDB Version 3.72 | 3.72 | Wicked & Wild Inc | | Spezial-Tool, kein winget |
|
||||
| Epic Games Launcher | 1.3.155.0 | Epic Games, Inc. | EpicGames.EpicGamesLauncher | Login + Spiele-Bibliothek |
|
||||
| FileBot | 5.1.5 | Point Planck Limited | PointPlanck.FileBot | Kostenpflichtige Lizenz |
|
||||
| Google Chrome | 147.0.7727.138 | Google LLC | Google.Chrome.EXE | Sync-Login (Lesezeichen/Passwords/Profile aus Backup) |
|
||||
| HP Scan - Grundlegende Software für das Gerät | 63.6.6364.25288 | HP Inc. | | HP-Drucker-Software (LAN/Netzwerk-Setup) — nur installieren wenn HP-Drucker noch da |
|
||||
| Microsoft 365 - de-de | 16.0.19929.20136 | Microsoft Corporation | Microsoft.Office | KRITISCH: ueber Microsoft-Konto / Office.com installieren |
|
||||
| Microsoft OneDrive | 26.063.0405.0002 | Microsoft Corporation | Microsoft.OneDrive | Microsoft-Konto-Login; vorher Sync-Konflikte mit altem OneDrive bedenken |
|
||||
| Movienizer 10.3 | | Movienizer.com | | Kostenpflichtig, kein winget |
|
||||
| MSI Afterburner 4.6.6 | 4.6.6 | MSI Co., LTD | Guru3D.Afterburner | Nur falls GPU-OC/Monitoring noch gebraucht wird |
|
||||
| NVIDIA App 11.0.7.237 | 11.0.7.237 | NVIDIA Corporation | Nvidia.GeForceExperience | KRITISCH ZUERST: NVIDIA-App-Bundle installiert ALLE NVIDIA-Komponenten in einem Rutsch (Treiber + Container) |
|
||||
| Octoparse 8.7.2 | 8.7.2 | Octopus Data Inc. | OctopusData.Octoparse | Web-Scraper, Account-bezogen, optional |
|
||||
| PingPlotter 5 | 5.18.0.7997 | Pingman Tools, LLC | Pingman.PingPlotter | Kostenpflichtige Lizenz, optional |
|
||||
| Plex Media Server | 1.40.3555 | Plex, Inc. | Plex.PlexMediaServer | Server-Komponente + Plex-Konto. Hinweis: am Homelab laeuft separater Plex; Desktop-Installation nur falls bewusst gewollt |
|
||||
| Razer Chroma | 4.0.662 | Razer Inc. | | Razer-Komponente — kommt mit Synapse |
|
||||
| Razer Synapse | 4.0.662 | Razer Inc. | | Hardware-Konfig (Mauspad/Beleuchtung) |
|
||||
| Rename Expert 5.31.6 | 5.31.6 | Gillmeister Software | | Kostenpflichtig, manuelle Installation |
|
||||
| Tailscale | 1.96.3 | Tailscale Inc. | Tailscale.Tailscale | Login + Tailscale-Konto (gleicher Account wie Homelab) |
|
||||
| Tesseract-OCR - open source OCR engine | 5.5.0.20241111 | Tesseract-OCR community | UB-Mannheim.TesseractOCR | OCR-Engine, open source — entscheiden ob noch genutzt |
|
||||
| WD Discovery | 4.4.407 | Western Digital Technologies, Inc. | | NAS-Discovery-Tool, nur falls WD NAS noch in Nutzung |
|
||||
| WD Drive Utilities | 2.1.0.142 | Western Digital Technologies, Inc. | | WD-HDD-Tool, nur falls WD-Platte noch in Nutzung |
|
||||
| WD My Cloud | 1.0.2.34 | Western Digital Technologies, Inc. | | WD My Cloud Login, nur falls Geraet noch in Nutzung |
|
||||
| Windows Subsystem for Linux | 2.6.3.0 | Microsoft Corporation | Microsoft.WSL | KRITISCH: WSL aktivieren, dann Distros per `wsl --import` aus 09_Programme_Settings_Lizenzen\Ubuntu.tar + docker-desktop.tar |
|
||||
| WinRAR 7.11 (64-Bit) | 7.11.0 | win.rar GmbH | RARLab.WinRAR | Lizenz (technisch Shareware) |
|
||||
| WISO Steuer 2023 | 30.10.3890 | Buhl Data Service GmbH | | Alte Version — nur falls noch reaktiviert werden soll. Steuerdateien aus 07_Banking_Finanzen\WISO_Steuer_Dokumente |
|
||||
| WISO Steuer 2024 | 31.02.3430 | Buhl Data Service GmbH | | Alte Version — nur falls noch reaktiviert werden soll |
|
||||
| WISO Steuer 2025 | 32.03.2120 | Buhl Data Service GmbH | | Alte Version — nur falls noch reaktiviert werden soll |
|
||||
| WISO Steuer 2026 | 33.05.3220 | Buhl Data Service GmbH | | KRITISCH aktuellste Version: Buhl-Konto + Steuerdateien aus _PostDelta\02_Dokumente\steuer (8 Dateien) |
|
||||
| Wondershare Recoverit(Build 14.0.13.3) | 14.0.13.3 | Wondershare Software Co.,Ltd. | | Kostenpflichtig, Datenrettungs-Tool |
|
||||
| WoodWorks 1.8.7 | 1.8.7 | Robert Denk | | Spezial-Tool, manuelle Installation |
|
||||
|
||||
---
|
||||
|
||||
## 3. Auto-Skip (105)
|
||||
|
||||
Treiber-Bundles, Runtimes, Dependencies, Duplikate, Bloatware, Spiele (kommen ueber Launcher). **Nur Sichtkontrolle, default ueberspringen.** Wenn Micha ein Item hier wider Erwarten doch will, in Einzelfrage verschieben.
|
||||
|
||||
| DisplayName | Version | Publisher | winget-ID | Begruendung |
|
||||
|---|---|---|---|---|
|
||||
| 3DMark | 2.22.7359.0 | UL | | Duplikat (zweiter Registry-Hive-Eintrag desselben Programms, siehe oben) |
|
||||
| Apex Legends | | Respawn Entertainment | | Game — Reinstall ueber Battle.net/Steam/Epic Launcher (Einzelfrage betrifft nur den Launcher) |
|
||||
| ARC Raiders | | Embark Studios | | Game — Reinstall ueber Battle.net/Steam/Epic Launcher (Einzelfrage betrifft nur den Launcher) |
|
||||
| Bonjour | 2.0.2.0 | Apple Inc. | | Apple Bonjour — Dependency (z. B. HP), wird bei Bedarf nachgezogen |
|
||||
| Bonjour-Druckdienste | 2.0.2.0 | Apple Inc. | | Apple Bonjour — Dependency (z. B. HP), wird bei Bedarf nachgezogen |
|
||||
| Documentation Manager | 23.40.0.4 | Intel Corporation | | Intel Treiber/Engine — kommt mit Intel Chipset-Driver-Bundle |
|
||||
| Dynamic Application Loader Host Interface Service | 1.0.0.0 | Intel Corporation | | Intel Treiber/Engine — kommt mit Intel Chipset-Driver-Bundle |
|
||||
| Epic Games Launcher Prerequisites (x64) | 1.0.0.0 | Epic Games, Inc. | | Epic Games Prerequisite — kommt mit Epic Games Launcher |
|
||||
| Epic Online Services | 4.0.1 | Epic Games, Inc. | | Epic Online Services — kommt mit Epic Games Launcher |
|
||||
| Futuremark SystemInfo | 5.49.1085.0 | Futuremark | | Dependency von 3DMark — wird mit installiert |
|
||||
| Hearthstone | | Blizzard Entertainment | | Game — Reinstall ueber Battle.net/Steam/Epic Launcher (Einzelfrage betrifft nur den Launcher) |
|
||||
| HELLDIVERS™ 2 | | Arrowhead Game Studios | | Game — Reinstall ueber Battle.net/Steam/Epic Launcher (Einzelfrage betrifft nur den Launcher) |
|
||||
| HP EmailSMTP Plugin | 56.0.517.0 | HP | | HP Drucker-Plugin — kommt mit HP-Treiber/HP Smart |
|
||||
| HP OCR | 1.0.1020.0 | HP Inc. | | HP Drucker-Plugin — kommt mit HP-Treiber/HP Smart |
|
||||
| HP SFTP Plugin | 56.0.517.0 | HP Inc. | | HP Drucker-Plugin — kommt mit HP-Treiber/HP Smart |
|
||||
| HP SharePoint Plugin | 56.0.517.0 | HP | | HP Drucker-Plugin — kommt mit HP-Treiber/HP Smart |
|
||||
| Intel(R) Chipset Device Software | 10.1.19899.8597 | Intel(R) Corporation | | Intel Treiber/Engine — kommt mit Intel Chipset-Driver-Bundle |
|
||||
| Intel(R) Chipset Device Software | 10.1.19899.8597 | Intel Corporation | | Duplikat (zweiter Registry-Hive-Eintrag desselben Programms, siehe oben) |
|
||||
| Intel(R) Icls | 1.0.0.0 | Intel Corporation | | Intel Treiber/Engine — kommt mit Intel Chipset-Driver-Bundle |
|
||||
| Intel(R) Management Engine Components | 1.0.0.0 | Intel Corporation | | Intel Treiber/Engine — kommt mit Intel Chipset-Driver-Bundle |
|
||||
| Intel(R) Management Engine Components | 2425.6.26.0 | Intel Corporation | | Duplikat (zweiter Registry-Hive-Eintrag desselben Programms, siehe oben) |
|
||||
| Intel(R) Management Engine Driver | 1.0.0.0 | Intel Corporation | | Intel Treiber/Engine — kommt mit Intel Chipset-Driver-Bundle |
|
||||
| Intel(R) ME WMI Provider | 1.0.0.0 | Intel Corporation | | Intel Treiber/Engine — kommt mit Intel Chipset-Driver-Bundle |
|
||||
| Intel(R) Serial IO | 30.100.2131.26 | Intel Corporation | | Intel Treiber/Engine — kommt mit Intel Chipset-Driver-Bundle |
|
||||
| Intel(R) Serial IO | 30.100.2131.26 | Intel Corporation | | Duplikat (zweiter Registry-Hive-Eintrag desselben Programms, siehe oben) |
|
||||
| Intel(R) Wireless Bluetooth(R) | 23.40.0.2 | Intel Corporation | | Intel Treiber/Engine — kommt mit Intel Chipset-Driver-Bundle |
|
||||
| Intel® Software Installer | 23.40.0.4 | Intel Corporation | | Intel Treiber/Engine — kommt mit Intel Chipset-Driver-Bundle |
|
||||
| Launcher Prerequisites (x64) | 1.0.0.0 | Epic Games, Inc. | | Epic Games Prerequisite — kommt mit Epic Games Launcher |
|
||||
| MaxCut | 2.9.3.9 | MaxCut Software (Pty) Ltd | | Duplikat (zweiter Registry-Hive-Eintrag desselben Programms, siehe oben) |
|
||||
| Microsoft Edge | 147.0.3912.98 | Microsoft Corporation | | Microsoft Edge / WebView2 — Bestandteil von Windows 11 |
|
||||
| Microsoft Edge WebView2-Laufzeit | 147.0.3912.98 | Microsoft Corporation | | Microsoft Edge / WebView2 — Bestandteil von Windows 11 |
|
||||
| Microsoft Teams Meeting Add-in for Microsoft Office | 1.26.08901 | Microsoft | | Office-Add-in — kommt mit Microsoft 365 / Teams |
|
||||
| Microsoft Update Health Tools | 5.72.0.0 | Microsoft Corporation | | Windows-Component — Windows Update |
|
||||
| Microsoft Visual C++ 2008 Redistributable - x64 9.0.30729.6161 | 9.0.30729.6161 | Microsoft Corporation | | VC++ Redistributable/Runtime — Dependency, wird mit Apps gezogen |
|
||||
| Microsoft Visual C++ 2008 Redistributable - x86 9.0.30729.6161 | 9.0.30729.6161 | Microsoft Corporation | | VC++ Redistributable/Runtime — Dependency, wird mit Apps gezogen |
|
||||
| Microsoft Visual C++ 2010 x86 Redistributable - 10.0.30319 | 10.0.30319 | Microsoft Corporation | | VC++ Redistributable/Runtime — Dependency, wird mit Apps gezogen |
|
||||
| Microsoft Visual C++ 2012 Redistributable (x64) - 11.0.61030 | 11.0.61030.0 | Microsoft Corporation | | VC++ Redistributable/Runtime — Dependency, wird mit Apps gezogen |
|
||||
| Microsoft Visual C++ 2012 Redistributable (x86) - 11.0.61030 | 11.0.61030.0 | Microsoft Corporation | | VC++ Redistributable/Runtime — Dependency, wird mit Apps gezogen |
|
||||
| Microsoft Visual C++ 2012 x64 Additional Runtime - 11.0.61030 | 11.0.61030 | Microsoft Corporation | | VC++ Redistributable/Runtime — Dependency, wird mit Apps gezogen |
|
||||
| Microsoft Visual C++ 2012 x64 Minimum Runtime - 11.0.61030 | 11.0.61030 | Microsoft Corporation | | VC++ Redistributable/Runtime — Dependency, wird mit Apps gezogen |
|
||||
| Microsoft Visual C++ 2012 x86 Additional Runtime - 11.0.61030 | 11.0.61030 | Microsoft Corporation | | VC++ Redistributable/Runtime — Dependency, wird mit Apps gezogen |
|
||||
| Microsoft Visual C++ 2012 x86 Minimum Runtime - 11.0.61030 | 11.0.61030 | Microsoft Corporation | | VC++ Redistributable/Runtime — Dependency, wird mit Apps gezogen |
|
||||
| Microsoft Visual C++ 2013 Redistributable (x64) - 12.0.30501 | 12.0.30501.0 | Microsoft Corporation | | VC++ Redistributable/Runtime — Dependency, wird mit Apps gezogen |
|
||||
| Microsoft Visual C++ 2013 Redistributable (x86) - 12.0.30501 | 12.0.30501.0 | Microsoft Corporation | | VC++ Redistributable/Runtime — Dependency, wird mit Apps gezogen |
|
||||
| Microsoft Visual C++ 2013 x64 Additional Runtime - 12.0.21005 | 12.0.21005 | Microsoft Corporation | | VC++ Redistributable/Runtime — Dependency, wird mit Apps gezogen |
|
||||
| Microsoft Visual C++ 2013 x64 Minimum Runtime - 12.0.21005 | 12.0.21005 | Microsoft Corporation | | VC++ Redistributable/Runtime — Dependency, wird mit Apps gezogen |
|
||||
| Microsoft Visual C++ 2013 x86 Additional Runtime - 12.0.21005 | 12.0.21005 | Microsoft Corporation | | VC++ Redistributable/Runtime — Dependency, wird mit Apps gezogen |
|
||||
| Microsoft Visual C++ 2013 x86 Minimum Runtime - 12.0.21005 | 12.0.21005 | Microsoft Corporation | | VC++ Redistributable/Runtime — Dependency, wird mit Apps gezogen |
|
||||
| Microsoft Visual C++ 2015-2022 Redistributable (x64) - 14.44.35211 | 14.44.35211.0 | Microsoft Corporation | | VC++ Redistributable/Runtime — Dependency, wird mit Apps gezogen |
|
||||
| Microsoft Visual C++ 2015-2022 Redistributable (x86) - 14.44.35211 | 14.44.35211.0 | Microsoft Corporation | | VC++ Redistributable/Runtime — Dependency, wird mit Apps gezogen |
|
||||
| Microsoft Visual C++ 2022 X64 Additional Runtime - 14.44.35211 | 14.44.35211 | Microsoft Corporation | | VC++ Redistributable/Runtime — Dependency, wird mit Apps gezogen |
|
||||
| Microsoft Visual C++ 2022 X64 Minimum Runtime - 14.44.35211 | 14.44.35211 | Microsoft Corporation | | VC++ Redistributable/Runtime — Dependency, wird mit Apps gezogen |
|
||||
| Microsoft Visual C++ 2022 X86 Additional Runtime - 14.44.35211 | 14.44.35211 | Microsoft Corporation | | VC++ Redistributable/Runtime — Dependency, wird mit Apps gezogen |
|
||||
| Microsoft Visual C++ 2022 X86 Minimum Runtime - 14.44.35211 | 14.44.35211 | Microsoft Corporation | | VC++ Redistributable/Runtime — Dependency, wird mit Apps gezogen |
|
||||
| MSI Center SDK | 3.2026.0123.01 | MSI | | MSI Komponente — wird mit MSI Center nachgezogen |
|
||||
| NvCpl | 1.0 | NVIDIA Corporation | | NVIDIA Driver-Komponente — wird mit dem NVIDIA-App-/Treiber-Bundle installiert |
|
||||
| NVIDIA AIUser Container | 1.48 | NVIDIA Corporation | | NVIDIA Driver-Komponente — wird mit dem NVIDIA-App-/Treiber-Bundle installiert |
|
||||
| NVIDIA Backend | 11.0.7.237 | NVIDIA Corporation | | NVIDIA Driver-Komponente — wird mit dem NVIDIA-App-/Treiber-Bundle installiert |
|
||||
| NVIDIA Container | 1.48 | NVIDIA Corporation | | NVIDIA Driver-Komponente — wird mit dem NVIDIA-App-/Treiber-Bundle installiert |
|
||||
| NVIDIA FrameView SDK 1.7.12227.37421622 | 1.7.12227.37421622 | NVIDIA Corporation | | NVIDIA Driver-Komponente — wird mit dem NVIDIA-App-/Treiber-Bundle installiert |
|
||||
| NVIDIA Grafiktreiber 596.21 | 596.21 | NVIDIA Corporation | | NVIDIA Driver-Komponente — wird mit dem NVIDIA-App-/Treiber-Bundle installiert |
|
||||
| NVIDIA HD-Audiotreiber 1.4.5.7 | 1.4.5.7 | NVIDIA Corporation | | NVIDIA Driver-Komponente — wird mit dem NVIDIA-App-/Treiber-Bundle installiert |
|
||||
| NVIDIA Install Application | 2.1002.442.0 | NVIDIA Corporation | | NVIDIA Driver-Komponente — wird mit dem NVIDIA-App-/Treiber-Bundle installiert |
|
||||
| NVIDIA LocalSystem Container | 1.48 | NVIDIA Corporation | | NVIDIA Driver-Komponente — wird mit dem NVIDIA-App-/Treiber-Bundle installiert |
|
||||
| NVIDIA MessageBus 3 for NvApp | 3.21 | NVIDIA Corporation | | NVIDIA Driver-Komponente — wird mit dem NVIDIA-App-/Treiber-Bundle installiert |
|
||||
| NVIDIA NvDLISR | 1.0 | NVIDIA Corporation | | NVIDIA Driver-Komponente — wird mit dem NVIDIA-App-/Treiber-Bundle installiert |
|
||||
| NVIDIA PhysX-Systemsoftware 9.23.1019 | 9.23.1019 | NVIDIA Corporation | | NVIDIA Driver-Komponente — wird mit dem NVIDIA-App-/Treiber-Bundle installiert |
|
||||
| NVIDIA Session Container | 1.48 | NVIDIA Corporation | | NVIDIA Driver-Komponente — wird mit dem NVIDIA-App-/Treiber-Bundle installiert |
|
||||
| NVIDIA ShadowPlay 11.0.7.0 | 11.0.7.0 | NVIDIA Corporation | | NVIDIA Driver-Komponente — wird mit dem NVIDIA-App-/Treiber-Bundle installiert |
|
||||
| NVIDIA Telemetry Client | 19.5.13.0 | NVIDIA Corporation | | NVIDIA Driver-Komponente — wird mit dem NVIDIA-App-/Treiber-Bundle installiert |
|
||||
| NVIDIA User Container | 1.48 | NVIDIA Corporation | | NVIDIA Driver-Komponente — wird mit dem NVIDIA-App-/Treiber-Bundle installiert |
|
||||
| NVIDIA Virtual Audio 4.65.0.12 | 4.65.0.12 | NVIDIA Corporation | | NVIDIA Driver-Komponente — wird mit dem NVIDIA-App-/Treiber-Bundle installiert |
|
||||
| NVIDIA Watchdog Plugin for NvContainer | 1.48 | NVIDIA Corporation | | NVIDIA Driver-Komponente — wird mit dem NVIDIA-App-/Treiber-Bundle installiert |
|
||||
| Office 16 Click-to-Run Extensibility Component | 16.0.19929.20136 | Microsoft Corporation | | Office-Komponente — kommt mit Microsoft 365 |
|
||||
| Office 16 Click-to-Run Localization Component | 16.0.19929.20062 | Microsoft Corporation | | Office-Komponente — kommt mit Microsoft 365 |
|
||||
| Overwatch | | Blizzard Entertainment | | Game — Reinstall ueber Battle.net/Steam/Epic Launcher (Einzelfrage betrifft nur den Launcher) |
|
||||
| PingPlotter 5 | 5.18.0.7997 | Pingman Tools, LLC | | Duplikat (zweiter Registry-Hive-Eintrag desselben Programms, siehe oben) |
|
||||
| Plex Media Server | 1.40.3.8555 | Plex, Inc. | | Duplikat (zweiter Registry-Hive-Eintrag desselben Programms, siehe oben) |
|
||||
| PUBG: BATTLEGROUNDS | | KRAFTON, Inc. | | Game — Reinstall ueber Battle.net/Steam/Epic Launcher (Einzelfrage betrifft nur den Launcher) |
|
||||
| Python 3.13.3 Add to Path (64-bit) | 3.13.3150.0 | Python Software Foundation | | Sub-Komponente von Python 3.13 — wird mit dem Python-Hauptpaket nachgezogen |
|
||||
| Python 3.13.3 Development Libraries (64-bit) | 3.13.3150.0 | Python Software Foundation | | Sub-Komponente von Python 3.13 — wird mit dem Python-Hauptpaket nachgezogen |
|
||||
| Python 3.13.3 Documentation (64-bit) | 3.13.3150.0 | Python Software Foundation | | Sub-Komponente von Python 3.13 — wird mit dem Python-Hauptpaket nachgezogen |
|
||||
| Python 3.13.3 Executables (64-bit) | 3.13.3150.0 | Python Software Foundation | | Sub-Komponente von Python 3.13 — wird mit dem Python-Hauptpaket nachgezogen |
|
||||
| Python 3.13.3 pip Bootstrap (64-bit) | 3.13.3150.0 | Python Software Foundation | | Sub-Komponente von Python 3.13 — wird mit dem Python-Hauptpaket nachgezogen |
|
||||
| Python 3.13.3 Standard Library (64-bit) | 3.13.3150.0 | Python Software Foundation | | Sub-Komponente von Python 3.13 — wird mit dem Python-Hauptpaket nachgezogen |
|
||||
| Python 3.13.3 Tcl/Tk Support (64-bit) | 3.13.3150.0 | Python Software Foundation | | Sub-Komponente von Python 3.13 — wird mit dem Python-Hauptpaket nachgezogen |
|
||||
| Python 3.13.3 Test Suite (64-bit) | 3.13.3150.0 | Python Software Foundation | | Sub-Komponente von Python 3.13 — wird mit dem Python-Hauptpaket nachgezogen |
|
||||
| Realtek USB Audio | 6.4.0.2422 | Realtek Semiconductor Corp. | | Realtek Audio-Treiber — kommt mit Chipset-/Audio-Driver-Bundle |
|
||||
| Stopping Plex | 1.40.3555 | Plex, Inc. | | Artefakt, kein echtes Programm |
|
||||
| THX Spatial Audio USB 1532-0555 | 3.2.3.0 | THX | | THX Audio-Komponente — kommt mit Audio-/Headset-Treiber |
|
||||
| THX Spatial Audio USB 1532-0555 | 3.2.3.0 | THX | | Duplikat (zweiter Registry-Hive-Eintrag desselben Programms, siehe oben) |
|
||||
| THX V3 APO Presets | 3.2.11.0 | THX | | THX Audio-Komponente — kommt mit Audio-/Headset-Treiber |
|
||||
| THX V3 APO Presets | 3.2.11.0 | THX | | Duplikat (zweiter Registry-Hive-Eintrag desselben Programms, siehe oben) |
|
||||
| THX V3 APO Presets | 3.2.14.0 | THX | | Duplikat (zweiter Registry-Hive-Eintrag desselben Programms, siehe oben) |
|
||||
| THX V3 APO Presets | 3.2.12.0 | THX | | Duplikat (zweiter Registry-Hive-Eintrag desselben Programms, siehe oben) |
|
||||
| THX V3 APO Presets | 3.2.12.0 | THX | | Duplikat (zweiter Registry-Hive-Eintrag desselben Programms, siehe oben) |
|
||||
| THX V3 APO Presets | 3.2.11.0 | THX | | Duplikat (zweiter Registry-Hive-Eintrag desselben Programms, siehe oben) |
|
||||
| THX V3 APO Presets | 3.2.14.0 | THX | | Duplikat (zweiter Registry-Hive-Eintrag desselben Programms, siehe oben) |
|
||||
| THX V3 APO Presets | 3.2.11.0 | THX | | Duplikat (zweiter Registry-Hive-Eintrag desselben Programms, siehe oben) |
|
||||
| WD Desktop App 2.1.0.335 | 2.1.0.335 | Western Digital Corporation | | WD Desktop App (legacy) — durch WD Discovery abgeloest |
|
||||
| WD Desktop App 2.1.0.335 (x64) | 2.1.0.335 | Western Digital Corporation | | WD Desktop App (legacy) — durch WD Discovery abgeloest |
|
||||
| WD Drive Utilities | 2.1.0.142 | Western Digital Technologies, Inc. | | Duplikat (zweiter Registry-Hive-Eintrag desselben Programms, siehe oben) |
|
||||
| WD SES Driver Setup | 2.1.0 | Western Digital | | Altes WD-Driver-Setup — wird durch aktuelle WD-Tools ersetzt |
|
||||
| World of Warcraft | | Blizzard Entertainment | | Game — Reinstall ueber Battle.net/Steam/Epic Launcher (Einzelfrage betrifft nur den Launcher) |
|
||||
| World of Warcraft Classic Era | | Blizzard Entertainment | | Game — Reinstall ueber Battle.net/Steam/Epic Launcher (Einzelfrage betrifft nur den Launcher) |
|
||||
|
||||
---
|
||||
|
||||
## Verifikations-Block
|
||||
|
||||
- Eintraege total: 161
|
||||
- Auto-Ja: 18
|
||||
- Einzelfrage: 38
|
||||
- Auto-Skip: 105
|
||||
- Quelle: 161 Eintraege in `installierte_programme.csv`
|
||||
- Stimmt: 18 + 38 + 105 == 161 == 161
|
||||
|
||||
## Aenderungs-Workflow
|
||||
|
||||
Falls Micha vor der Neuinstallation noch Eintraege umsortieren will: direkt in diesem Markdown-File die Zeile zwischen den Sektionen verschieben und Begruendung anpassen. Diese Datei ist die Wahrheit fuer den Wiederaufbau-Schritt.
|
||||
@@ -0,0 +1,183 @@
|
||||
# Windows Image Backup Baseline - baerchen
|
||||
|
||||
Stand: 2026-06-05
|
||||
|
||||
Dieses Runbook beschreibt den Windows-Image-Backup-Workflow fuer den frisch
|
||||
aufgesetzten Windows-11-Rechner `baerchen`. Ziel ist ein schneller Bare-Metal-
|
||||
Restore von C: ueber Veeam Recovery Media und ein Image auf dem bestehenden
|
||||
Unraid-SMB-Share `backups`.
|
||||
|
||||
## Zielbild
|
||||
|
||||
| Feld | Wert |
|
||||
|---|---|
|
||||
| Workstation | `baerchen` |
|
||||
| OS | Windows 11 Pro, Build 26200 |
|
||||
| Backup-Tool | Veeam Agent for Microsoft Windows |
|
||||
| Installierte Version | `13.0.2.1102` |
|
||||
| Backup-Art | Volume-level image backup |
|
||||
| Gesicherte Volumes | C: plus EFI-/Recovery-Partitionen, keine Datenlaufwerke D:/G:/H: |
|
||||
| Primaeres Ziel | `\\kallilabcore\backups\windows-images\baerchen` |
|
||||
| Linux-Pfad auf Unraid | `/mnt/user/backups/windows-images/baerchen/` |
|
||||
| Share-Modell | bestehender Unraid-Share `backups`, kein neuer Share |
|
||||
| SMB-User | `micha` (bestehender Unraid-User mit Read/Write auf `backups`) |
|
||||
| Veeam Job | `baerchen-c-image` |
|
||||
| Verschluesselung | Stand erster Lauf: Veeam Storage Encryption **nicht aktiv** (`StorageEncryptionEnabled=False` im Job-Log); optional separat aktivieren und neues Full-Backup erzeugen |
|
||||
| Recovery Media | USB-Stick `VEEAMRE` auf Laufwerk F: erstellt |
|
||||
|
||||
## Bewusste Entscheidungen
|
||||
|
||||
- Es wurde kein neuer Unraid-Share angelegt. Der Zielpfad lebt unter dem
|
||||
bestehenden Share `backups`, weil dieser laut `docs/STORAGE_LAYOUT.md` fuer
|
||||
lokale Backup-Daten vorgesehen ist.
|
||||
- Es wurde vorerst kein dedizierter SMB-User `veeam-baerchen` angelegt, um
|
||||
keine Unraid-Share-/User-Aenderung zu erzwingen. Der produktive Job nutzt
|
||||
den bestehenden User `micha`.
|
||||
- BitLocker wurde am 2026-06-05 nicht aktiviert. TPM, Secure Boot und WinRE
|
||||
wurden geprueft; BitLocker bleibt ein separater Security-Schritt.
|
||||
- Der Recovery-Stick ist Teil des Restore-Pfads und muss getrennt vom Rechner
|
||||
aufbewahrt werden.
|
||||
|
||||
## Vorab-Pruefungen 2026-06-05
|
||||
|
||||
| Check | Ergebnis |
|
||||
|---|---|
|
||||
| SMB-Port `445` auf `kallilabcore` | erreichbar |
|
||||
| SMB-Zielordner | angelegt |
|
||||
| SMB-Schreibtest | erfolgreich, Testdatei wieder geloescht |
|
||||
| Veeam Installation | erfolgreich via `winget` |
|
||||
| Veeam Dienst | `VeeamEndpointBackupSvc` running |
|
||||
| WinRE | Enabled |
|
||||
| TPM | Present/Ready/Enabled/Activated/Owned |
|
||||
| Secure Boot | True |
|
||||
| BitLocker C: | FullyDecrypted, Protection Off |
|
||||
|
||||
## Backup-Job
|
||||
|
||||
Veeam Agent -> Job `baerchen-c-image`
|
||||
|
||||
- Backup Mode: `Volume level backup`
|
||||
- Included items:
|
||||
- Lokaler Datentraeger C:
|
||||
- EFI System Partition
|
||||
- Recovery-Partitionen
|
||||
- Destination: `Shared folder`
|
||||
- Shared folder: `\\kallilabcore\backups\windows-images\baerchen`
|
||||
- Credentials: bestehender Unraid-SMB-User `micha`
|
||||
- Compression: `Optimal`
|
||||
- Storage encryption: Stand erster Lauf **nicht aktiv**
|
||||
- Schedule: Workstation-Schedule in Veeam; Stand 2026-06-05: taeglich nachts
|
||||
eingerichtet.
|
||||
|
||||
Wenn Veeam Storage Encryption spaeter aktiviert wird, ist das
|
||||
Veeam-Job-Passwort nicht aus dem Repo wiederherstellbar. Es muss dann in
|
||||
Vaultwarden als eigener Eintrag/Secure Note liegen und vor dem ersten
|
||||
verschluesselten Full-Backup getestet werden.
|
||||
|
||||
## Secrets und Ablageorte
|
||||
|
||||
Keine Secret-Werte in dieses Repository schreiben.
|
||||
|
||||
| Secret | Ablage |
|
||||
|---|---|
|
||||
| Veeam Job Encryption Password | nur noetig, falls Veeam Storage Encryption aktiviert wird; Ziel: Vaultwarden Secure Note `Veeam baerchen backup encryption password` |
|
||||
| SMB Credential fuer Backup-Ziel | bestehender Unraid/Vaultwarden-Eintrag fuer User `micha` |
|
||||
| BitLocker Recovery Key | noch nicht aktiv; Ziel bei Aktivierung: `D:\30_Finanzen\BitLocker-RecoveryKey-baerchen-<DATUM>.txt`, Vaultwarden Secure Note, physischer Ausdruck |
|
||||
|
||||
## Recovery Media
|
||||
|
||||
Der USB-Stick wurde mit Veeam Recovery Media erstellt.
|
||||
|
||||
Erwarteter Zustand:
|
||||
|
||||
- Laufwerk beim Erstellen: F:
|
||||
- Label: `VEEAMRE`
|
||||
- Dateisystem: FAT32
|
||||
- Boot-Dateien vorhanden: `boot/`, `efi/`, `sources/`, `bootmgr`,
|
||||
`bootmgr.efi`, `BMRAnswerFile.xml`
|
||||
|
||||
Aufbewahrung: Stick beschriften mit `baerchen Veeam Recovery - 2026-06-05`
|
||||
und nicht als Alltags-USB verwenden.
|
||||
|
||||
## Restore-Prozedur
|
||||
|
||||
1. Wenn C: defekt oder leer ist, `baerchen` ausschalten.
|
||||
2. Veeam-Recovery-USB `VEEAMRE` einstecken.
|
||||
3. Rechner vom USB-Stick booten.
|
||||
4. In der Veeam Recovery Environment Netzwerk pruefen.
|
||||
5. Shared Folder als Backup-Quelle oeffnen:
|
||||
`\\kallilabcore\backups\windows-images\baerchen`
|
||||
6. Mit SMB-User `micha` authentifizieren.
|
||||
7. Veeam-Backup auswaehlen.
|
||||
8. Falls der Restore Point verschluesselt ist: Veeam-Job-Encryption-Passwort
|
||||
aus Vaultwarden eingeben. Der erste Full-Lauf vom 2026-06-05 ist laut Log
|
||||
nicht verschluesselt.
|
||||
9. Bare Metal Recovery starten und Ziel-Disk fuer Windows C: auswaehlen.
|
||||
10. Vor dem finalen Restore pruefen, dass nicht D:/G:/H: als Ziel ausgewaehlt
|
||||
sind.
|
||||
11. Restore ausfuehren.
|
||||
12. Nach erstem Boot:
|
||||
- Windows startet
|
||||
- Veeam Agent startet
|
||||
- Laufwerksbuchstaben C:/D:/G: plausibel
|
||||
- Netzwerk/DNS/Tailscale plausibel
|
||||
- `reagentc /info` zeigt WinRE Enabled
|
||||
|
||||
## Restore-Test ohne echten Restore
|
||||
|
||||
Der Test ist noch offen und muss nach dem ersten erfolgreichen Backup
|
||||
durchgefuehrt werden:
|
||||
|
||||
1. Vom USB-Stick booten.
|
||||
2. Veeam Recovery Environment starten.
|
||||
3. Netzwerk pruefen.
|
||||
4. SMB-Ziel `\\kallilabcore\backups\windows-images\baerchen` mounten.
|
||||
5. Restore Point anzeigen lassen.
|
||||
6. Wenn der Restore Point verschluesselt ist: Veeam-Encryption-Passwort testen.
|
||||
7. Vor Auswahl eines echten Ziel-Datentraegers abbrechen.
|
||||
8. Windows normal von der internen SSD booten.
|
||||
|
||||
Erfolgskriterium: Recovery-Umgebung sieht das SMB-Ziel und den Restore Point,
|
||||
ohne dass ein Restore gestartet wurde.
|
||||
|
||||
## Erster Full-Lauf 2026-06-05
|
||||
|
||||
Der erste manuelle Full-Lauf wurde am 2026-06-05 gestartet.
|
||||
|
||||
Beleg aus `C:\ProgramData\Veeam\Endpoint\baerchen-c-image\Job.baerchen-c-image.Backup.log`:
|
||||
|
||||
- Start: 2026-06-05 19:46:01
|
||||
- Ziel-Datei: `\\kallilabcore\backups\windows-images\baerchen\baerchen-c-image\baerchen-c-image2026-06-05T194605.vbk`
|
||||
- Veeam-Storage-Statistik: `BackupSize 57801080832` Bytes; Veeam-GUI zeigt
|
||||
`Total backup size: 53,8 GB`
|
||||
- Veeam-GUI: Restore Point Size `53,8 GB`, Backup duration `0:11:31`,
|
||||
`Full backup created`
|
||||
- MetaChecker: `0 errors`, `0 warnings`
|
||||
- VSS Finalisierung: `job: success`
|
||||
- Repository-Speicher danach: ca. 5.99 TB total, ca. 3.99 TB frei
|
||||
- Job-Konfiguration im Log: `StorageEncryptionEnabled=False`
|
||||
|
||||
Damit ist der erste Image-Lauf technisch erfolgreich geschrieben. Noch offen
|
||||
bleibt der Recovery-USB-Boot-/SMB-Test.
|
||||
|
||||
Hilfsskript fuer die Windows-Seite:
|
||||
|
||||
```powershell
|
||||
.\ops\windows-reinstall\check-veeam-baerchen.ps1
|
||||
```
|
||||
|
||||
Wenn der SMB-Pfad in der normalen PowerShell nicht erreichbar ist, aber Veeam
|
||||
den Job erfolgreich schreibt, liegt das meist an getrennten Credentials:
|
||||
Veeam nutzt gespeicherte Job-Credentials, waehrend die interaktive Windows-
|
||||
Sitzung zusaetzlich per `net use` authentifiziert werden muss.
|
||||
|
||||
## Offene Punkte
|
||||
|
||||
- Recovery-Stick-Boot und SMB-Mount testen.
|
||||
- Entscheiden, ob Veeam Storage Encryption nachtraeglich aktiviert werden soll.
|
||||
Wenn ja: Passwort in Vaultwarden anlegen, Job umstellen und ein neues Full-
|
||||
Backup erzeugen.
|
||||
- Optional: BitLocker C: separat aktivieren und Recovery-Key an den drei
|
||||
vorgesehenen Orten sichern.
|
||||
- Optional: spaeter dedizierten SMB-User `veeam-baerchen` anlegen, falls die
|
||||
Unraid-User-/Share-Policy wieder angefasst wird.
|
||||
@@ -43,7 +43,9 @@ Erledigt:
|
||||
Noch offen:
|
||||
|
||||
- Manuelle Screenshots in `H:\Windows-Neuaufsetzen-Backup\14_Screenshots` ablegen.
|
||||
- BitLocker-Status mit Adminrechten pruefen.
|
||||
- BitLocker-Status mit Adminrechten pruefen. **Nachlauf 2026-06-05:** Status
|
||||
wurde geprueft; C:/D:/E:/G:/H: sind `FullyDecrypted`, Protection `Off`.
|
||||
Offen bleibt nur die bewusste BitLocker-Entscheidung.
|
||||
- Passwortmanager, 2FA-Recovery-Codes und Browser-Sync manuell pruefen.
|
||||
- Banking4-Speicherort explizit pruefen.
|
||||
- Banking4 im Programm selbst oeffnen und aktuellen Datentresor/Backup-Export bestaetigen. Der Key und der Datentresor sind bereits lokal auf H: gesichert.
|
||||
@@ -528,6 +530,12 @@ Zielstruktur:
|
||||
|
||||
## Finale Checkliste vor dem Löschen
|
||||
|
||||
Status 2026-06-05: Diese Checkliste ist historisch fuer die Freigabe der
|
||||
Neuinstallation. Die technische Neuinstallation, Laufwerksbereinigung,
|
||||
WinRE-Pruefung und Veeam-Baseline sind in neueren Dokumenten nachgezogen.
|
||||
Als offene manuelle Pruefungen bleiben vor allem Passwortmanager/2FA,
|
||||
Banking4, WISO und Microsoft/M365.
|
||||
|
||||
- [ ] Backup-Struktur auf H: erstellt
|
||||
- [ ] Programmliste exportiert
|
||||
- [ ] Laufwerksliste exportiert
|
||||
|
||||
+142
@@ -0,0 +1,142 @@
|
||||
#!/usr/bin/env bash
|
||||
set -euo pipefail
|
||||
|
||||
BASE_DIR="${BASE_DIR:-/mnt/user/services/posture-check}"
|
||||
WATCHER_SCRIPT="${WATCHER_SCRIPT:-/mnt/user/services/homelab-infra/services/posture-check/docker-critical-events.sh}"
|
||||
PID_FILE="${PID_FILE:-$BASE_DIR/docker-critical-events.pid}"
|
||||
OUT_FILE="${OUT_FILE:-$BASE_DIR/docker-critical-events.out}"
|
||||
EVENT_LOG="${EVENT_LOG:-$BASE_DIR/docker-critical-events-last.log}"
|
||||
NTFY_SCRIPT="${NTFY_SCRIPT:-/mnt/user/services/homelab-infra/ops/restore-tests/send-ntfy.sh}"
|
||||
NTFY_TOPIC="${NTFY_TOPIC:-homelab-alerts}"
|
||||
|
||||
usage() {
|
||||
cat >&2 <<EOF
|
||||
Usage: $0 start|stop|restart|status|smoke
|
||||
|
||||
start Start Docker critical-events watcher in the background.
|
||||
stop Stop the watcher by pidfile.
|
||||
restart Stop and start the watcher.
|
||||
status Print watcher status and recent log tail.
|
||||
smoke Send one ntfy test message through the same alert path.
|
||||
EOF
|
||||
}
|
||||
|
||||
is_running() {
|
||||
[ -s "$PID_FILE" ] || return 1
|
||||
local pid
|
||||
pid="$(cat "$PID_FILE")"
|
||||
[ -n "$pid" ] || return 1
|
||||
kill -0 "$pid" >/dev/null 2>&1
|
||||
}
|
||||
|
||||
start_watcher() {
|
||||
mkdir -p "$BASE_DIR"
|
||||
|
||||
if is_running; then
|
||||
echo "docker-critical-events watcher already running (pid $(cat "$PID_FILE"))"
|
||||
return 0
|
||||
fi
|
||||
|
||||
if [ ! -r "$WATCHER_SCRIPT" ]; then
|
||||
echo "Watcher script not readable: $WATCHER_SCRIPT" >&2
|
||||
return 1
|
||||
fi
|
||||
|
||||
NTFY_SCRIPT="$NTFY_SCRIPT" \
|
||||
NTFY_TOPIC="$NTFY_TOPIC" \
|
||||
OUTPUT_PATH="$EVENT_LOG" \
|
||||
nohup bash "$WATCHER_SCRIPT" >"$OUT_FILE" 2>&1 </dev/null &
|
||||
|
||||
echo "$!" > "$PID_FILE"
|
||||
sleep 1
|
||||
|
||||
if is_running; then
|
||||
echo "docker-critical-events watcher started (pid $(cat "$PID_FILE"))"
|
||||
else
|
||||
echo "docker-critical-events watcher failed to stay running; see $OUT_FILE" >&2
|
||||
return 1
|
||||
fi
|
||||
}
|
||||
|
||||
stop_watcher() {
|
||||
if ! is_running; then
|
||||
rm -f "$PID_FILE"
|
||||
echo "docker-critical-events watcher is not running"
|
||||
return 0
|
||||
fi
|
||||
|
||||
local pid
|
||||
pid="$(cat "$PID_FILE")"
|
||||
kill "$pid" >/dev/null 2>&1 || true
|
||||
sleep 1
|
||||
|
||||
if kill -0 "$pid" >/dev/null 2>&1; then
|
||||
echo "watcher still running after SIGTERM; sending SIGKILL"
|
||||
kill -9 "$pid" >/dev/null 2>&1 || true
|
||||
fi
|
||||
|
||||
rm -f "$PID_FILE"
|
||||
echo "docker-critical-events watcher stopped"
|
||||
}
|
||||
|
||||
status_watcher() {
|
||||
if is_running; then
|
||||
echo "status=running pid=$(cat "$PID_FILE")"
|
||||
else
|
||||
echo "status=stopped"
|
||||
[ -e "$PID_FILE" ] && echo "stale_pidfile=$PID_FILE"
|
||||
fi
|
||||
|
||||
echo "watcher_script=$WATCHER_SCRIPT"
|
||||
echo "event_log=$EVENT_LOG"
|
||||
echo "out_file=$OUT_FILE"
|
||||
|
||||
if [ -s "$EVENT_LOG" ]; then
|
||||
echo
|
||||
echo "Recent critical events:"
|
||||
tail -n 20 "$EVENT_LOG"
|
||||
fi
|
||||
|
||||
if [ -s "$OUT_FILE" ]; then
|
||||
echo
|
||||
echo "Recent watcher output:"
|
||||
tail -n 20 "$OUT_FILE"
|
||||
fi
|
||||
}
|
||||
|
||||
smoke_ntfy() {
|
||||
if [ ! -r "$NTFY_SCRIPT" ]; then
|
||||
echo "ntfy helper not readable: $NTFY_SCRIPT" >&2
|
||||
return 1
|
||||
fi
|
||||
|
||||
bash "$NTFY_SCRIPT" \
|
||||
"$NTFY_TOPIC" \
|
||||
"Docker critical watcher smoke" \
|
||||
"Smoke test from $(hostname) at $(date -Iseconds). No container was stopped." \
|
||||
default
|
||||
echo "smoke notification sent to $NTFY_TOPIC"
|
||||
}
|
||||
|
||||
case "${1:-}" in
|
||||
start)
|
||||
start_watcher
|
||||
;;
|
||||
stop)
|
||||
stop_watcher
|
||||
;;
|
||||
restart)
|
||||
stop_watcher
|
||||
start_watcher
|
||||
;;
|
||||
status)
|
||||
status_watcher
|
||||
;;
|
||||
smoke)
|
||||
smoke_ntfy
|
||||
;;
|
||||
*)
|
||||
usage
|
||||
exit 2
|
||||
;;
|
||||
esac
|
||||
@@ -0,0 +1,55 @@
|
||||
#!/usr/bin/env bash
|
||||
set -euo pipefail
|
||||
|
||||
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
|
||||
WATCHER="$SCRIPT_DIR/../docker-critical-events.sh"
|
||||
|
||||
if [ ! -r "$WATCHER" ]; then
|
||||
echo "FAIL: watcher not readable at $WATCHER" >&2
|
||||
exit 1
|
||||
fi
|
||||
|
||||
tmp="$(mktemp -d)"
|
||||
trap 'rm -rf "$tmp"' EXIT
|
||||
|
||||
mkdir -p "$tmp/bin"
|
||||
cat > "$tmp/bin/docker" <<'EOF'
|
||||
#!/usr/bin/env bash
|
||||
if [ "${1:-}" != "events" ]; then
|
||||
echo "unexpected docker command: $*" >&2
|
||||
exit 1
|
||||
fi
|
||||
|
||||
cat <<'EVENTS'
|
||||
{"Type":"container","Action":"die","Actor":{"Attributes":{"name":"ok-container","image":"example:latest","exitCode":"0"}}}
|
||||
{"Type":"container","Action":"die","Actor":{"Attributes":{"name":"bad-container","image":"example:latest","exitCode":"137"}}}
|
||||
{"Type":"container","Action":"oom","Actor":{"Attributes":{"name":"oom-container","image":"example:latest"}}}
|
||||
EVENTS
|
||||
EOF
|
||||
chmod +x "$tmp/bin/docker"
|
||||
|
||||
PATH="$tmp/bin:$PATH" \
|
||||
SEND_NTFY=0 \
|
||||
OUTPUT_PATH="$tmp/events.log" \
|
||||
bash "$WATCHER"
|
||||
|
||||
fail() {
|
||||
echo "FAIL: $*" >&2
|
||||
echo "--- events.log ---" >&2
|
||||
cat "$tmp/events.log" >&2 || true
|
||||
exit 1
|
||||
}
|
||||
|
||||
[ -s "$tmp/events.log" ] || fail "expected critical event log to be written"
|
||||
|
||||
if grep -q 'ok-container' "$tmp/events.log"; then
|
||||
fail "exitCode 0 die event should not alert"
|
||||
fi
|
||||
|
||||
grep -q 'bad-container' "$tmp/events.log" || fail "non-zero die event missing"
|
||||
grep -q 'oom-container' "$tmp/events.log" || fail "oom event missing"
|
||||
|
||||
line_count="$(wc -l < "$tmp/events.log" | tr -d ' ')"
|
||||
[ "$line_count" = "2" ] || fail "expected 2 logged critical events, got $line_count"
|
||||
|
||||
echo "OK - docker critical events filter test passed"
|
||||
@@ -93,12 +93,29 @@ bash /mnt/user/services/homelab-infra/services/posture-check/daily-status-report
|
||||
|
||||
## `docker-critical-events-at-start`
|
||||
|
||||
Zeit: Array Start. Dieser Job startet einen Hintergrund-Watcher und beendet sich sofort.
|
||||
Zeit: Array Start. Dieser Job startet einen Hintergrund-Watcher und beendet sich
|
||||
sofort. Der Supervisor schreibt PID, stdout/stderr und Event-Log nach
|
||||
`/mnt/user/services/posture-check/`.
|
||||
|
||||
```bash
|
||||
#!/bin/bash
|
||||
ps -ef | grep -F -- "docker events --filter event=die --filter event=oom --filter event=kill" | grep -v grep >/dev/null && exit 0
|
||||
mkdir -p /mnt/user/services/posture-check
|
||||
nohup bash /mnt/user/services/homelab-infra/services/posture-check/docker-critical-events.sh >/mnt/user/services/posture-check/docker-critical-events.out 2>&1 </dev/null &
|
||||
exit 0
|
||||
exec /mnt/user/services/homelab-infra/services/posture-check/docker-critical-events-supervisor.sh start
|
||||
```
|
||||
|
||||
Status pruefen:
|
||||
|
||||
```bash
|
||||
/mnt/user/services/homelab-infra/services/posture-check/docker-critical-events-supervisor.sh status
|
||||
```
|
||||
|
||||
Stoppen:
|
||||
|
||||
```bash
|
||||
/mnt/user/services/homelab-infra/services/posture-check/docker-critical-events-supervisor.sh stop
|
||||
```
|
||||
|
||||
ntfy-Smoke-Test ohne Container-Stopp:
|
||||
|
||||
```bash
|
||||
/mnt/user/services/homelab-infra/services/posture-check/docker-critical-events-supervisor.sh smoke
|
||||
```
|
||||
|
||||
Reference in New Issue
Block a user