AI-Profile-Router/docs/RECOVERY.md

Backup und vollständige Wiederherstellung

Athena besitzt zwei voneinander unabhängige Sicherungsebenen. Nur gemeinsam decken sie Systemplatten-, Datenplatten- und Totalausfall ab.

Sicherungsebenen

Ebene	Ziel	Takt	Zweck
Lokales Schnellbackup	/data/docker-backups	alle 5 Stunden	schneller Wiederaufbau, wenn nur die Systemplatte stirbt
Verschlüsseltes Disaster-Backup	externes Restic-Repository, bevorzugt Unraid	nachts	Wiederaufbau, wenn /data oder beide Platten sterben

Ein Backup, das ausschließlich auf /data liegt, schützt ausdrücklich nicht vor dem Ausfall der Datenplatte.

Lokales Schnellbackup

mike-ai-backup sichert:

• /etc/mike-ai, einschließlich install.env, WireGuard und Geheimnissen,
• ganz /opt/mike-ai, einschließlich aller bereitgestellten Spezialprojekte,
• Router-Zustand und Router-Bilder,
• Portainer-Daten.

Das Whisper-Volume ist reproduzierbar und wird bei Bedarf erneut geladen. Ein vorhandener Hugging-Face-Token wird als root-only /etc/mike-ai/huggingface-token mitgesichert, damit auch zugriffsbeschränkte FLUX-Gewichte nach einem Datenverlust automatisch erneut geladen werden können. Er steht niemals im Git-Repository.

Externes Disaster-Backup

athena-disaster-backup.timer startet nachts ein verschlüsseltes, dedupliziertes Restic-Backup. Vor jedem Lauf erzeugt es ein konsistentes Docker-Schnellbackup und nimmt dieses in den externen Snapshot auf. Gesichert werden außerdem:

• /etc/mike-ai und /opt/mike-ai,
• eigene Stimmen, Applio-Datasets und Trainingsstände unter /data/voice,
• Musikprojekte und Ausgaben unter /data/music,
• Audio-Trennungen unter /data/audio,
• Dashboard-, Operator-, Benchmark- und Projektdaten.

Die rund 100 GB reproduzierbaren Modellgewichte unter /data/models werden nicht extern dupliziert. Kerngewichte lädt install.sh anhand URL und SHA256 neu. Spezialmodelle laden ihre gepinnten Container beim ersten Start erneut.

Herunterladbare Notfallpakete

Zusätzlich erzeugt athena-export-backup.timer alle fünf Stunden ein mit Age verschlüsseltes Komplettpaket der unersetzlichen Daten unter /data/emergency-backups. Das Dashboard zeigt die letzten fünf Generationen mit Größe, SHA256-Prüfsumme und einem fortsetzbaren Download an. Enthalten sind insbesondere Applio-Logs und -Checkpoints, Datasets, eigene Stimmen, Musikprojekte, Audioergebnisse, Konfiguration, Docker-Zustand und sämtliche bereitgestellten Quellstände. Erneut ladbare Modell- und Hugging-Face-Caches sind ausgeschlossen.

Bei aktuellem Datenbestand ist mit ungefähr 16 bis 20 GB je Generation zu rechnen. Fünf Generationen benötigen daher grob 80 bis 100 GB auf /data. Diese Pakete schützen nur dann vor einem Datenplattenausfall, wenn mindestens eine Generation tatsächlich auf einen anderen Rechner oder Datenträger heruntergeladen wurde. Die Pakete auf /data selbst sterben mit /data.

Der zu recovery.age-recipient gehörende private Age-Schlüssel darf nicht auf Athena verbleiben. Ohne ihn können die Pakete absichtlich nicht entschlüsselt werden.

Einmalige Einrichtung des externen Backups

1. Ein physisch anderes Backupziel bereitstellen, vorzugsweise einen ausschließlich über WireGuard erreichbaren Unraid-Share, und zum Beispiel unter /mnt/athena-offsite einhängen.

2. Eine starke Restic-Passphrase erzeugen und zusätzlich außerhalb Athenas in einem Passwortmanager oder auf einem Recovery-USB verwahren.

3. Konfiguration anlegen:

   cp config/disaster-backup.env.example /etc/mike-ai/disaster-backup.env
   chmod 600 /etc/mike-ai/disaster-backup.env
   # Repository, Mountpoint und Passwortdatei eintragen; danach:
   sed -i 's/^DISASTER_BACKUP_ENABLED=false/DISASTER_BACKUP_ENABLED=true/' \
     /etc/mike-ai/disaster-backup.env
   

4. Ersten Lauf und Snapshot prüfen:

   systemctl start athena-disaster-backup.service
   journalctl -u athena-disaster-backup.service --no-pager
   restic snapshots --tag athena-disaster
   

Die externe Recovery-Konfiguration und die Passphrase bilden den kleinen Recovery-Schlüssel. Eine Kopie davon muss außerhalb beider Athena-Platten liegen. Ohne extern erreichbares Repository und dessen Schlüssel ist ein Totalausfall mathematisch nicht wiederherstellbar.

Gemeinsame Voraussetzung aller drei Fälle

Debian 13 ist frisch beziehungsweise weiterhin vorhanden. Die korrekte Datenpartition ist formatiert und als eigener Mountpoint /data eingehängt. disaster-recovery.sh partitioniert und formatiert absichtlich nichts und bricht ab, wenn /data nur ein Verzeichnis auf der Systemplatte ist. Dadurch kann es nicht versehentlich die falsche Platte überschreiben.

Der Installer darf einen kontrollierten Neustart für NVIDIA-Treiber oder die stabile Netzwerkschnittstelle verlangen. Das Recovery-Skript startet Athena niemals selbst neu. Nach dem manuellen Neustart wird derselbe Befehl erneut ausgeführt; alle Schritte sind idempotent.

Fall 1: Systemplatte defekt, Datenplatte erhalten

Nach Debian-Installation und Einhängen der alten /data-Platte:

sudo ./disaster-recovery.sh --scenario system \
  --archive /data/docker-backups/athena-latest.tar.gz

Das Skript birgt Konfiguration und sämtliche /opt/mike-ai-Projekte aus dem lokalen Archiv, installiert Docker/NVIDIA, verwendet die vorhandenen Modelle, stellt die Docker-Volumes wieder her, baut Spezialcontainer und führt den Smoke-Test aus.

Ältere Archive vor Einführung von /etc/mike-ai/install.env bleiben lesbar. Bei einem solchen Archiv muss die Installationsdatei einmal separat angegeben werden:

sudo ./disaster-recovery.sh --scenario system \
  --archive /data/docker-backups/athena-latest.tar.gz \
  --install-config /root/mike-ai-install.env

Fall 2: Datenplatte defekt, Systemplatte erhalten

Neue Datenpartition unter /data einhängen und den extern aufbewahrten Recovery-Schlüssel bereitstellen:

sudo ./disaster-recovery.sh --scenario data \
  --config /root/athena-recovery.env

Eigene Daten und der letzte Docker-Zustand kommen aus Restic. Modellgewichte werden anschließend automatisch neu geladen. Je nach Internetverbindung ist dies der längste Teil der Wiederherstellung.

Fall 3: Beide Platten defekt

Debian auf der neuen Systemplatte installieren, neue Datenpartition als /data einhängen, dieses Git-Repository klonen und den externen Recovery-Schlüssel bereitstellen:

sudo ./disaster-recovery.sh --scenario all \
  --config /root/athena-recovery.env

Der externe Snapshot liefert Installationskonfiguration, Schlüssel, Anwendungsquellen, Spezial-UIs, eigene Daten und Docker-Zustand. Danach werden Pakete, Images und Modellgewichte reproduzierbar neu aufgebaut.

Alternativ kann ein zuvor aus dem Dashboard heruntergeladenes Notfallpaket direkt verwendet werden:

sudo ./disaster-recovery.sh --scenario all \
  --portable /mnt/usb/athena-portable-2026-09-10T15-00-00Z.tar.zst.age \
  --identity /mnt/usb/athena-recovery-key.txt

Ergebnis und Sicherheitsverhalten

Nach erfolgreichem Lauf gilt:

• Kernstack und Dashboard laufen,
• Medium ist das aktive LLM-Standardprofil,
• Spezialcontainer und ihre Oberflächen sind gebaut beziehungsweise erstellt,
• GPU-intensive Spezialworker bleiben gestoppt,
• keine automatische Umschaltung in Musik-, Bild-, Voice- oder Applio-Modus,
• smoke-test.sh hat den Kern geprüft.

Erst danach wird der gewünschte Spezialmodus über das Dashboard aktiviert.

Regelmäßige Prüfung

Mindestens vierteljährlich einen Restore in eine leere Test-VM beziehungsweise auf Testdatenträger durchführen. Ein grünes Backup-Log beweist nur, dass Daten geschrieben wurden; erst ein Restore-Test beweist Wiederherstellbarkeit.

systemctl status athena-disaster-backup.timer
journalctl -u athena-disaster-backup.service --since '2 days ago'
restic snapshots --tag athena-disaster
sudo ./restore.sh --check /data/docker-backups/athena-latest.tar.gz

Unraid

Hermes und die Fach-MCPs laufen auf Unraid und sind kein Bestandteil des Athena-Restores. Sie werden weiterhin über das Unraid-Appdata-Backup gesichert. Das Athena-Disaster-Repository muss auf einem anderen Datenträger beziehungsweise Storage-Pool als das zu schützende Athena-System liegen.