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 73.728 Kontext
• Medium startet mit 94.208 Kontext
• Long startet mit 131.072 Kontext
• 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 drei virtuelle Modelle
• /fast, /medium und /long 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

• 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
• 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

Phase E – Vision, Bild und Sprache

• neues Bild löst genau einen Vision-Hotswap aus
• Folgefrage verwendet Cache und keinen zweiten Hotswap
• Bilddaten werden vor dem Textmodell sanitisiert
• Remote-/private Bild-URL wird abgewiesen und übergroße Data-URL blockiert
• Qwen-Profil wird nach Vision wiederhergestellt
• FLUX erzeugt Standard- und High-Bild
• Qwen-Profil wird nach FLUX wiederhergestellt
• Whisper transkribiert deutsche und englische Testdatei
• XTTS erzeugt deutsche WAV- und MP3-Ausgabe
• STT/TTS blockieren das Textmodell nicht unzulässig

Phase F – Sicherheitsprüfung

• Port 8080 von normalen Clients nicht erreichbar
• 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

Phase G – Fachlicher Benchmark

Der gespeicherte Standardbenchmark wird mindestens mit Fast und Long 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.