Backup und Wiederherstellung

Athena – geprüfter Sicherungsstand vom 12. September 2026

mike-ai-backup läuft und sichert im Fünf-Stunden-Takt nach /data/docker-backups (14 Tage Aufbewahrung). Die aktuell geprüften Mounts sichern:

/etc/mike-ai einschließlich lokaler Konfiguration und Secrets,
/opt/mike-ai einschließlich des bereitgestellten, teilweise uncommitteten Stacks,
die Volumes router-images, router-state und portainer_data.

Piper-Daten sind kein aktueller Sicherungsbestand. Modellgewichte unter /data/models und das reproduzierbare Whisper-Volume gehören nicht zu diesen Backup-Mounts. Ein Backup ausschließlich auf /data schützt nicht vor deren Ausfall.

Zusätzlich existieren die externe Restic-Sicherung über athena-disaster-backup.timer und verschlüsselte Notfallpakete über athena-export-backup.timer. Bei beiden zugehörigen Services wurden Result=success und ExecMainStatus=0 gelesen. Das bestätigt den letzten Dienstabschluss, keinen in diesem Auftrag geprüften vollständigen Restore. Die Notfallpakete liegen unter /data/emergency-backups; Schutz vor Datenplattenausfall setzt eine außerhalb Athenas aufbewahrte Kopie voraus.

Wiederherstellung und Versionsgrenze

Der bereitgestellte Quellstand muss aus der Sicherung erhalten bleiben: Ein frischer Git-Clone enthält noch nicht sämtliche Live-Anpassungen und Spezialdienste, siehe Live-Stand. Vor einem Restore sind Archivinhalt, Aktualität und Kompatibilität der zugehörigen Restore-Skripte zu prüfen. Bestehende lokale Änderungen niemals blind überschreiben.

Die Host-Regel gilt unverändert: Athena niemals herunterfahren oder neu starten und ihre Erreichbarkeit nicht gefährden. Eine Neuinstallation ist keine normale Wartungsmaßnahme am erreichbaren Remote-Host. Für den begrenzten Rückfall des Modellservers stehen altes Image und gesicherte Startkonfiguration im b10930-Updatebericht.

Unraid

Hermes und die Fach-MCPs sind kein Bestandteil des Athena-Backups. Sie werden durch das vorhandene Unraid-Appdata-Backup gesichert:

/mnt/nvme-storage/appdata/Hermes-Agent
die jeweiligen Appdata-Verzeichnisse der MCP-Container
DockerMan-Templates unter /boot/config/plugins/dockerMan/templates-user/

Container-Images stammen aus den dokumentierten Registries beziehungsweise den eigenen Gitea-Repositories. Damit besteht die Wiederherstellung aus Appdata-Restore plus Neuerstellung über die jeweilige Template-XML.

Hermes Cron/Bot-Chat auf Unraid

Der offizielle Hermes-Build 0.21.0 mit Upstream-Stand 4b30b917 entfernt im Cron-Zustellprozess fälschlich HERMES_HOME. Bei einem Docker-Datenverzeichnis unter /opt/data findet deliver=bot-chat:<profil> dadurch vorhandene Profile nicht. Bis zur Übernahme des Upstream-Fixes bindet die Unraid-Vorlage dieses idempotente Startskript ein:

Host: /mnt/nvme-storage/appdata/Hermes-Agent/patches/025-cron-profile-root-fix
Container: /etc/cont-init.d/025-cron-profile-root-fix (read-only)
Quelle: platform/hermes/025-cron-profile-root-fix

Das Skript entfernt nur die bekannte fehlerhafte Zeile. Ist sie in einem neuen Image nicht mehr vorhanden, bleibt der Workaround automatisch wirkungslos. Es stellt außerdem /usr/local/bin/hermes wieder her, weil der offizielle Container den vom eigenen Doctor erwarteten CLI-Link derzeit nicht anlegt.

Nach einem Restore die Datei mit Modus 0755 ins Appdata kopieren, den Mount in der DockerMan-Vorlage kontrollieren und den Container neu erstellen. Prüfung:

docker logs Hermes-Agent 2>&1 | grep cron-profile-root-fix
docker exec Hermes-Agent hermes cron doctor

Kontrolle

docker compose --env-file /etc/mike-ai/stack.env ps
sudo ./restore.sh --check /data/docker-backups/athena-latest.tar.gz
curl -fsS http://192.168.1.212:8099/health
sudo ./smoke-test.sh

Anschließend einen Hermes-Chat, einen Router-Aufruf und je eine kleine read-only-Abfrage der benötigten MCPs testen.

4.0 KiB Raw Blame History Unescape Escape