Das Problem

Der Windows 11 PC (SKYNET) dient als lokaler KI-Rechenknoten für matzka.cloud: Eine NVIDIA RTX 4070 Ti betreibt Ollama mit Llama 3.1 8B und LiteLLM als OpenAI-kompatibles API-Gateway. Der Chatbot auf der Homepage greift über das Tailscale VPN auf diesen Client zu.

Das Problem: Windows installiert Updates und startet danach automatisch neu. Nach dem Neustart wurde die Tailscale-VPN-Verbindung zum Headscale-Server (vpn.matzka.cloud) nicht automatisch wiederhergestellt — der Chatbot war dann nicht mehr erreichbar, bis jemand manuell eingriff. Außerdem fehlte ein Offsite-Backup der Server-Daten auf dem leistungsfähigen lokalen Speicher.

Tailscale Auto-Connect

Reusable Pre-Auth Key

Der bisherige Headscale Pre-Auth Key war einmalig und bereits verbraucht. Für die automatische Wiederverbindung wurde ein dauerhaft wiederverwendbarer Key mit 10 Jahren Laufzeit erstellt:

docker exec headscale headscale preauthkeys create \
  --user 1 \
  --expiration 87600h \
  --reusable

PowerShell Auto-Connect Script

Das Script tailscale-autoconnect.ps1 prüft beim Ausführen den Verbindungsstatus und ruft tailscale up auf, falls Tailscale nicht verbunden ist:

$status = & tailscale.exe status --json | ConvertFrom-Json
if ($status.BackendState -ne "Running") {
    & tailscale.exe up --login-server=https://vpn.matzka.cloud `
        --authkey=$AuthKey --accept-routes
}

Windows Scheduled Task

Das Script wird als Windows Scheduled Task beim Systemstart ausgeführt — 30 Sekunden verzögert, damit das Netzwerk bereit ist. Der Task läuft unter dem SYSTEM-Account und benötigt daher keinen Benutzer-Login:

Eigenschaft	Wert
Task-Name	Tailscale AutoConnect
Trigger	Systemstart + 30 Sekunden
Account	SYSTEM (kein Login erforderlich)
Script	scripts\tailscale-autoconnect.ps1

Automatische Offsite-Backups

Ausgangssituation

Auf ssh2.matzka.cloud erstellt der Container docker-volume-backup täglich um 03:00 Uhr ein vollständiges Backup aller Docker-Volumes als .tar.gz-Archiv (~1,7 GB/Tag). Der Server behält die letzten 7 Tage. Bisher lagen alle Backups ausschließlich auf dem Server selbst — kein Offsite-Schutz.

SKYNET verfügt über ein RAID1-Volume (Z:) — ideal als kostengünstiger Offsite-Backup-Speicher.

Architektur: Pull statt Push

Statt den Server aktiv auf den Win11-PC pushen zu lassen (was einen SSH-Server auf Windows erfordert hätte), zieht Win11 die Backups selbst vom Server. Das vereinfacht die Konfiguration erheblich:

SKYNET (Win11)  ──SSH/SCP──▶  backup-reader@ssh2.matzka.cloud
                               /opt/docker/backups/*.tar.gz
                               ↓
                          Z:\matzka-cloud\

Server: backup-reader User

Auf dem Server wurde ein eingeschränkter System-User backup-reader angelegt, der per SSH-Key authentifiziert wird und ausschließlich lesenden Zugriff auf /opt/docker/backups/ hat:

# SSH-Konfiguration (kein interaktives Terminal, nur Key-Auth)
Match User backup-reader
    PasswordAuthentication no
    AllowTcpForwarding no
    X11Forwarding no
    PermitTTY no

Win11: Backup Pull Script & Scheduled Task

Das Script backup-pull-from-server.ps1 wird täglich um 05:00 Uhr ausgeführt (2 Stunden nach dem Server-Backup). Es lädt nur Dateien herunter, die noch nicht lokal vorhanden sind — inkrementell, ohne Duplikate:

Eigenschaft	Wert
Task-Name	matzka.cloud Backup Pull
Trigger	Täglich 05:00 Uhr
Account	S4U (Reinhard, kein Login nötig)
Ziel	Z:\matzka-cloud\ (RAID1)
Retention	30 Tage
Dateigröße	~1,7 GB pro Tag

Der Task nutzt LogonType S4U (Service for User) — der Task läuft im Kontext des Benutzers und hat Zugriff auf dessen SSH-Key und known_hosts, ohne dass ein Passwort gespeichert oder der Benutzer angemeldet sein muss.

Integritätsprüfung & Notifications

Archiv-Integrität prüfen

Nach jedem Download wird das Archiv mit tar -tzf vollständig gelesen. Schlägt die Prüfung fehl, wird das korrupte Archiv gelöscht — beim nächsten Lauf wird es erneut heruntergeladen:

& tar -tzf $localPath 2>&1 | Out-Null
if ($LASTEXITCODE -ne 0) {
    Remove-Item $localPath -Force
    # → nächster Lauf lädt die Datei erneut
}

Gotify Push-Notifications

Für den Backup-Status wurde eine eigene Gotify-App Win11 Backup angelegt. Notifications werden in zwei Szenarien gesendet:

Ereignis	Priorität	Beispiel
Neues Backup erfolgreich	4 (still)	✅ Backup erfolgreich — 1 neue Datei auf Z: (10.8 GB gesamt)
Download- oder Integritätsfehler	8 (dringend)	❌ Backup fehlgeschlagen — Integritätsfehler: backup-20260616…

Ergebnis

Nach einem Windows-Reboot (z.B. nach automatischen Updates) läuft nun alles vollautomatisch:

Zeit	Aktion	Account
Start + 30s	Tailscale verbindet mit vpn.matzka.cloud	SYSTEM
03:00	Server erstellt Backup aller Docker-Volumes	docker-volume-backup
05:00	Win11 zieht neues Backup nach Z:\matzka-cloud\	S4U (Reinhard)

Alle Scripts sind im Gitea-Repository win11-llm-client versioniert und können bei Bedarf per git pull auf Win11 aktualisiert werden.