AI-Profile-Router/docs/DISASTER_RECOVERY.md

Disaster Recovery und Abnahme

Definition „vollständig wiederhergestellt“

Eine Installation gilt erst dann als wiederhergestellt, wenn nicht nur Prozesse laufen, sondern alle fachlichen Funktionen geprüft wurden.

Phase A – Basissystem

• Betriebssystem und Kernel dokumentierter Stand
• Uhrzeit, Zeitzone und NTP korrekt
• Netzwerk nach Neustart automatisch verfügbar
• NVIDIA-Treiber geladen
• RTX und kompletter VRAM sichtbar
• System- und Modelllaufwerk korrekt gemountet
• mindestens 15 Prozent frei auf dem Systemlaufwerk
• Docker und Compose funktionieren
• keine RX- oder Benchmark-Altlast aktiviert

Phase B – Textmodell

• llama.cpp entspricht dem festgelegten Commit
• Modelldateien stimmen mit SHA256 überein
• Fast startet mit 76.800 Kontext
• Medium startet mit 160.000 Kontext und ist Standard
• Large startet mit 192.000 Kontext
• Ultra startet mit 262.144 Kontext und bleibt text-only
• Uncensored startet mit 80.000 Kontext, 90:10 und MTP2
• GPU-/CPU-Verteilung entspricht den Profilen
• Fast erreicht den festgelegten Geschwindigkeitstoleranzbereich
• MTP funktioniert und verursacht keine Qualitätsregression
• Rolling-/Kontextverhalten ist bewusst definiert und getestet

Phase C – Router

• Start ohne API-Key schlägt bewusst fehl
• /health bleibt bei Hotswap 200 und /ready wird vorübergehend 503
• geschützte Endpunkte liefern ohne Key 401
• Router-Key erscheint weder im Upstream noch im Journal
• /status meldet den richtigen Upstream
• /v1/models liefert fünf virtuelle Modelle
• /fast, /medium, /large, /ultra und /uncensored wechseln zuverlässig
• automatischer Wechsel über virtuellen Modellnamen funktioniert
• paralleler Wechsel wird sauber gesperrt
• Streaming funktioniert
• Tool Calls funktionieren
• Fehler sind OpenAI-kompatibel
• ein abgebrochener Client hinterlässt keinen blockierten Job
• erzwungener Routerabbruch wird aus Zustandsdatei sauber rekonstruiert
• fehlende/falsche Profilregistry verhindert falsche Readiness

Phase D – Web und MCP

• OpenWebUI zeigt nur die fünf MikeAI-Arbeitsbereichsmodelle

• rohe qwen-*-Routermodelle sind ausgeblendet

• Medium ist die gespeicherte Standardauswahl

• Filter und Quick Actions sind allen fünf Presets zugeordnet

• SearXNG und TinySearch gesund

• Websuche liefert kompakte, quellengebundene Ergebnisse

• GitHub- und Hugging-Face-Routing geprüft

• Home Assistant read-only Diagnose geprüft

• ARR read-only Suche geprüft

• Navidrome-MCP gesund; 38 beziehungsweise mit Last.fm 45 Werkzeuge

• Navidrome-Schemas vollständig llama.cpp-kompatibel

• Navidrome ist nicht pauschal an jedes Modellprofil gebunden

• offizieller GitHub-MCP gesund; exakt vier read-only Repository-Werkzeuge

• GitHub-Token liegt nur in /etc/mike-ai/github-mcp.env (0600), nicht in OpenWebUI

• Unraid read-only Diagnose geprüft

• schreibende Werkzeuge standardmäßig nicht geladen

• Tool-Schemas bleiben innerhalb des festgelegten Kontextbudgets

• kein Secret erscheint in Toolantworten oder Logs

• PLATFORM_OVERVIEW.md, QWEN_OPERATOR_CONTEXT.md und der Operator- System-Prompt entsprechen dem wiederhergestellten Stand

Phase E – Vision, Bild und Sprache

• neues Bild wird ohne Dienstneustart direkt vom aktiven Qwen analysiert
• Folgefrage bleibt im multimodalen Verlauf und löst keinen Hotswap aus
• Bilddaten werden größen- und URL-validiert
• Remote-/private Bild-URL wird abgewiesen und übergroße Data-URL blockiert
• llama.cpp-PID und aktives Profil bleiben bei Vision unverändert
• FLUX erzeugt Standard- und High-Bild
• Qwen-Profil wird nach FLUX wiederhergestellt
• Whisper transkribiert deutsche und englische Testdatei
• XTTS-v2 läuft ausschließlich auf der RTX 3060 und meldet Annmarie Nele
• TTS-Gateway erzeugt über den Router deutsche und englische WAV-/MP3-Ausgabe
• englische IT-Begriffe im deutschen Satz werden sprachlich segmentiert
• gestopptes XTTS fällt ohne Router-/OpenWebUI-Neustart auf Piper zurück
• Piper-Fallback und piper-tts-Version entsprechen der Installationskonfiguration
• STT/TTS blockieren das Textmodell nicht unzulässig

Phase F – Sicherheitsprüfung

• Port 8080/8081 an der physischen Hostadresse nicht erreichbar
• beide Ports über die Fritz-VPN-Adresse erreichbar
• gestopptes WireGuard-Gateway blockiert Container-Egress
• Hilfsports nur localhost
• Router nur aus erlaubtem Netz erreichbar
• Dienste laufen mit minimalen Rechten
• Environment-Dateien Modus 0600
• kein allgemeiner Shell-MCP im Standardprofil
• Schreibaktionen verlangen Vorschau und Approval Ticket
• Secret-Restore wurde ohne Klartextausgabe durchgeführt
• verschlüsseltes Recovery-Bundle liegt außerhalb von Athena
• age-Identität liegt getrennt vom Bundle und nicht auf Athena

Phase G – Fachlicher Benchmark

Der gespeicherte Standardbenchmark wird mindestens mit Fast und Medium sowie für Kontextgrenzen zusätzlich mit Large und Ultra sowie mit dem gesonderten Uncensored-Sicherheitslauf ausgeführt:

• Home-Assistant-Automatisierung analysieren
• Logs lesen und Fehlerursache begründen
• sichere Korrektur vorschlagen
• Webrecherche mit Quellen durchführen
• Docker-/Unraid-Diagnose simulieren
• Tool-Limits, Halluzinationen und unnötige Aufrufe bewerten

Die neue Installation muss innerhalb einer vorher festgelegten Toleranz zur Referenz liegen. Nur „Dienst läuft“ genügt nicht.

Recovery-Protokoll

Für jeden Wiederaufbau werden festgehalten:

• Datum
• verwendeter Repository-Commit
• Modellmanifest-Version
• Hardware
• Dauer je Phase
• Abweichungen
• Testergebnis
• verantwortliche Freigabe

Erst nach Abschluss aller Pflichtpunkte darf der alte Host gelöscht oder als Fallback außer Betrieb genommen werden.

Der ausführbare Ablauf steht in BARE_METAL_RECOVERY.md.