# 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: ```bash 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: ```bash 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: ```bash 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: ```bash 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: ```bash 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: ```bash 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: ```bash 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. ```bash 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.