Add encrypted configuration backup and planned restore

BACKUP.md

@@ -0,0 +1,64 @@
+# Backup und Wiederherstellung
+
+**Einstellungen → Backup & Restore** erstellt eine `.adbackup`-Datei. Für die Verschlüsselung ist ein separates Kennwort mit mindestens 16 Zeichen nötig. Die Datei enthält auch Secrets und darf nur an vertrauenswürdige Stellen weitergegeben werden. Das Kennwort wird beim Export nicht gespeichert. Ohne Kennwort lässt sich ein heruntergeladenes Backup nicht wiederherstellen.
+
+## Inhalt
+
+- Alle Deck-Modellprofile mit Sampling, Kontext, Slots, GPU-Verteilung, KV-Cache, MTP, Vision-Projektor, Komponenten und Prompt-Aufwertern.
+- API-Port, freigegebene Profile, Listener-Autostart, aktive Video-Modellauswahl und TTS-/STT-Residency-Einstellungen.
+- Modellinventar mit festen Hugging-Face-Commits, Dateinamen, Größe und SHA-256. Laufzeitrezepte und vorhandene llama.cpp-Buildversionen, inklusive aktivem Build.
+- Oberflächenkennwort als Prüfwert, API-Token als Prüfwert, Hugging-Face-Token und Deck-eigener ComfyUI-Diensttoken. API-Token im Klartext kann Deck nicht rekonstruieren: der bereits im Client konfigurierte Token bleibt nach Wiederherstellung gültig.
+- Deck-eigene WireGuard-Konfiguration einschließlich Schlüsseln, gewünschter Verbindung und Zugriffsmodus, wenn das Deck-Netzwerkmodul angebunden ist.
+- Ausdrücklich mit `io.athena-deck.managed=true` und `io.athena-deck.role=application` markierte Container: Image-/Registryquelle, Labels, Startparameter, Umgebungsvariablen, Benutzer, Ressourcenlimits, Restart-Regel, Ports, Mount-Zuordnung und Startzustand. Eingebundene Secret-Dateien und Swarm `Settings.fds`/`Backends.fds` werden mitgesichert. Swarm erhält das im Deck-Quellstand gepflegte Build-Rezept.
+- Aktuelles Browser-Theme. Optional: Dashboard-History als konsistenter SQLite-Snapshot, maximal 40 MiB.
+
+Nicht enthalten: Modellgewichte, Python-/CUDA-/ComfyUI-Umgebungen, Docker-Layer, Chats, Prompt-/Antwortinhalte, Anwendungslogs, Medien, generierte Ausgaben, Trainingsdaten, Docker-Registry-Login und beliebige Verzeichnisinhalte anderer Anwendungen. Volumes werden deshalb nicht pauschal archiviert: für weitere Anwendungs-Konfigurationsdateien werden gepflegte, ausdrückliche Rezepte benötigt. Solche Daten und lokal gebaute Images ohne veröffentlichtes Image oder Deck-Build-Rezept separat sichern.
+
+RAM-/VRAM-Inhalt und gerade laufende Aufträge werden nicht exportiert. Profile, Auswahl und Vorladeverhalten werden wiederhergestellt; ein GPU-Prozess wird nicht allein deshalb gestartet, weil er beim Export lief. Die normale Deck-Steuerung lädt bei Anfrage bzw. nach der gespeicherten Audio-Policy.
+
+## Wiederherstellung auf einem frisch installierten Deck
+
+1. Deck mit seinen normalen Voraussetzungen installieren und einen vorläufigen Administratorzugang einrichten. Der bisherige Docker-Testinstaller setzt Docker voraus; native Debian-Basisinstallation und NVIDIA-Treiberinstallation bleiben eigenständige Voraussetzungen.
+2. Backup auswählen, Kennwort eingeben und **Backup prüfen** klicken. Die Prüfung verändert noch keine Einstellungen. Sie zeigt Profile, vorhandene/fehlende Dateien, erforderlichen Platz, Laufzeitrezepte, Dienste und Hindernisse.
+3. Zusatzdienste auswählen. Zum Beispiel Swarm abwählen, wenn es nicht mehr gebraucht wird. Entscheiden, ob das Oberflächenkennwort und der API-Zugang aus dem Backup zurückkommen oder der neu eingerichtete Zugang erhalten bleiben soll.
+4. Plan bestätigen und **Wiederherstellung starten**. Deck sichert vorher den aktuellen Konfigurationsstand, beendet nur eigene Worker und sperrt Verwaltungsänderungen während des Restore.
+5. Vorhandene Gewichte werden per SHA-256 geprüft. Fehlende Dateien werden aus der gespeicherten Quellversion geladen und mit der gespeicherten SHA-256 verglichen. Vorhandene Laufzeiten werden verwendet; fehlende bekannte Laufzeiten werden installiert bzw. llama.cpp-Versionen gebaut. Ein abweichendes Bild-/TTS-Runtime-Rezept wird vorab als Hindernis gemeldet.
+6. Gewählte Dienste werden aus ihrer Registry geladen oder aus dem gepflegten Swarm-Rezept gebaut. Neue externe Mounts werden in das eigene Dienstverzeichnis des Systemhelfers verlegt; lesende Deck-Modellvolumes werden mit der aktuellen Installation verbunden. Fremde/existierende Dienste werden weder ersetzt noch gestoppt. Vorhandene markierte Container mit gleichem Image werden unverändert übernommen – deren externe Settings werden während dieses Wiederverwendens nicht überschrieben.
+7. Profile, Komponenten, Einstellungen und optional Dashboard-History werden angewendet. Die Oberfläche zeigt pro Schritt das Ergebnis, Downloadgeschwindigkeit/ETA sowie einen Abschlussstatus. **„Mit offenen Punkten“**, **„fehlgeschlagen“** und **„unterbrochen“** sind ausdrücklich kein vollständiger Erfolg.
+
+Docker-GPU-/privilegierte Container, Host-Geräte, Docker-Socket-Mounts, fremde Host-Dateisysteme und beliebige Host-Netzwerkcontainer werden nicht automatisch wiederhergestellt. Neue veröffentlichte Ports sind auf Loopback begrenzt. Bekannte Swarm-/LTX-DeskWEB-Oberflächen dürfen wie bisher Host-Netzwerk verwenden. Modelle und produktive Fremddienste werden dafür nicht beendet. Der Restore verändert weder den vorhandenen Gateway noch Host-Firewall, SSH, Kernel oder NVIDIA-Treiber und startet den Server nicht neu.
+
+### Lokale Modelldateien
+
+Bei rein lokalen Dateien ohne gesicherte Downloadquelle ist ein vollständiger Neuaufbau aus einem Konfigurationsbackup unmöglich. Sie werden als solche angezeigt und ein Restore bei fehlender Datei blockiert. Der aus dem alten Router übernommene `mmproj-BF16.gguf` ist eine geprüfte Ausnahme: Größe und SHA-256 stimmen exakt mit `unsloth/Qwen3.8-27B-GGUF`, Commit `4ca720788d1e01f1bff70c033e0d0028fd02e502`, überein. Er lässt sich nachladen; die ursprüngliche Bibliotheks-ID und Profilreferenzen bleiben bestehen.
+
+### WireGuard und Erreichbarkeit
+
+Nur das Deck-eigene Netzwerkmodul wird exportiert; der bestehende Athena-WireGuard-Gateway gehört nicht dazu. Die aktuelle isolierte Athena-Installation hat dieses Modul deaktiviert, ihr Export enthält daher keine Gateway-Schlüssel. Ein Backup mit WireGuard verlangt beim Import zunächst ein angebundenes Deck-Netzwerkmodul und bestätigten LAN-Zugang bei deaktiviertem Deck-Tunnel.
+
+Konfiguration und Verbindung werden dort wiederhergestellt und der Handshake geprüft. Ohne Handshake bleibt LAN erhalten. Für `tunnel`/`both` greift der bestehende befristete Zugriffsversuch: Bestätigung über den Tunnel ist erforderlich, sonst Rückfall. Der Restore meldet diesen offenen Schritt ausdrücklich. Einen ungetesteten reinen Tunnelzugang vollautomatisch zu erzwingen würde den entfernten Server aussperren können.
+
+## Rückfall, Abbruch und Neustart
+
+Vor jedem Restore liegt ein verschlüsselter lokaler Rückfallstand unter `state/recovery/before-<id>.adbackup`; dessen lokaler Schlüssel liegt getrennt mit Modus 0600 daneben. **Lokale Rückfallstände → prüfen** bietet denselben Importplan an. Das ist ein lokales Rückfallmittel, kein Ersatz für ein extern gelagertes Backup. Bei fatalen Fehlern versucht Deck, die vorherigen Anwendungseinstellungen wiederherzustellen. Bereits nachgeladene Dateien und neu angelegte Container bleiben erhalten und werden nicht automatisch gelöscht.
+
+Abbruch stoppt Deck-Downloads und Laufzeit-Builds. Ein bereits laufender Docker-Pull/Build wird zu Ende geführt, bevor der Job abbricht. Nach einem Deck-Neustart wird ein laufender Restore als unterbrochen gemeldet; kein stilles Wiederaufnehmen mit ungesichertem Kennwort. Das Backup erneut importieren: erfolgreich vorhandene Dateien/Builds werden wiederverwendet.
+
+## API und Format
+
+Nur Administratorsitzungen; alle POSTs benötigen `X-Athena-Deck: 1` und den bestehenden Same-Origin-Schutz:
+
+- `GET /api/v1/backup`: Job, geprüfter Plan und lokale Rückfallstände; niemals Backup-Secrets.
+- `POST /api/v1/backup/export`: JSON `{password, theme, history}` → verschlüsselte Binärdatei.
+- `POST /api/v1/backup/inspect`: Binärdatei, `Content-Type: application/octet-stream`; Kennwort UTF-8/Base64 im Header `X-Backup-Passphrase` → bereinigter Importplan.
+- `POST /api/v1/backup/restore`: JSON `{id, services: [Namen], confirm: true, restore_credentials: true|false}` → Hintergrundjob.
+- `POST /api/v1/backup/cancel`: `{}`.
+- `POST /api/v1/backup/checkpoint`: `{name}` → Importprüfung eines lokalen Rückfallstands.
+
+Formatversion 1: JSON-Konfigurationsmanifest, zlib-Kompression, AES-256-GCM mit zufälligem 96-Bit-Nonce und authentisiertem Header; Schlüsselableitung scrypt (N=32768, r=8, p=1) mit zufälligem 128-Bit-Salt. Maximal 64 MiB Konfigurationsinhalt und Upload; entpackte Größen werden begrenzt. Keine ZIP/Tar-Extraktion, kein Pickle, keine importierten Shellskripte. `python3-cryptography` wird in den Deck-Docker-Images installiert; native Installationen benötigen dasselbe Debian-Paket.
+
+Der root-eigene Docker-Helfer validiert Container unabhängig von der GUI und verwendet feste argv-Aufrufe ohne Shell. Das Deck-Zustandsverzeichnis wird mit `setup_docker_helper.py --deck-state /ABS/PATH/state` registriert. Er darf nur sein eigenes Dienstverzeichnis und dieses registrierte Verzeichnis beschreiben.
+
+## Prüfung
+
+Automatische Tests decken Verschlüsselung, Manipulation, Dekompressionsgrenzen, ungültige Pfade/Referenzen, fehlende Downloadquellen, SHA-256, vorhandene/neu geladene Dateien, Bestandsschutz und Rückfall ab. Auf Athena erfolgen zusätzlich ein echter Konfigurationsexport und ein kleiner API-Restore mit echtem HF-Download in einem separaten Testbestand. Kein vollständiger Desaster-Restore des laufenden Athena-Servers und keine echte Änderung am produktiven WireGuard-Gateway.