Preserve historical Gemini backups and separate snapshot staging

SPEICHER.md

@@ -191,3 +191,64 @@ und `result.txt`. `SUCCESS` im aktuellen `result.txt` bestätigt das Update; der
 Restore-Teststatus ist ein separater Nachweis nach dem Monatslauf. Scheitert ein Update trotz der
 sicheren Bereinigung, bleiben die Timer nach begonnener Installation gestoppt;
 der Fehler muss behoben und das Paket erneut ausgeführt werden.
+
+## Gemini: historische Archive erhalten, Staging trennen – 18.10.2026
+
+**Reparatur vorbereitet; produktive Ausführung und vollständiger neuer Lauf noch
+offen.** Die durch Johannes ausgeführte Root-Diagnose bestätigt rund 48 GB
+historische flache Archive sowie drei vollständige lokale Sätze ohne `UPLOADED`.
+Die Platzprüfung des Nachtlaufs bricht vor dem Snapshot ab. Diese Daten werden
+nicht als automatische Löschkandidaten freigegeben.
+
+`operations/gemini_backup_repair.py` ist eine feste Gemini-Operation. Sie wird
+zusammen mit der ACME-Reparatur aus dem ai-rem-maintenance-Paket gestartet:
+
+```bash
+sudo bash /var/tmp/install-gemini-repair-20261018.sh
+sudo journalctl -fu jr-gemini-repair-20261018.service --no-pager
+```
+
+Der einmalige Hintergrundauftrag erfordert das Betreiberpasswort. Quellen,
+Prüfsumme und vollständiger Ablauf stehen im
+[Wartungsrepository](https://gitea.jr-it-services.de/johannes/ai-rem-maintenance).
+
+Die Speicheroperation erhält die bisherigen Archive wie folgt:
+
+- Historische flache Archive und bei Bedarf ältere vollständige, nicht als
+  hochgeladen bestätigte Sätze werden auf die freie Root-Partition unter
+  `/srv/app-backup-preserved-20261018/` **verlagert**. Quelle und Ziel jeder Datei
+  werden mit SHA-256 sowie rsync-Metadatenprüfung verglichen und Zielzustand
+  synchronisiert. Das ursprüngliche Objekt wird erst danach entfernt; die
+  Sicherung bleibt unter ihrem bisherigen Namen am neuen Ort erhalten.
+- Bestätigte aktuelle lokale Sätze bleiben im aktiven Archivverzeichnis. Die
+  Verlagerung macht aus unbestätigten Sätzen keine bestätigten Uploads. Unter
+  `/var/lib/jr-app-backup-space-20261018/` liegen ursprüngliche Konfiguration,
+  Planung und ein Prüfnachweis mit Quell-/Zielort pro Objekt, ausschließlich root-
+  lesbar. Alte Pfade nach einer erfolgreichen Verlagerung nicht weiterverwenden.
+- `STAGING_ROOT` wechselt nach erfolgreicher Prüfung auf
+  `/home/.app-backup-staging`; `ARCHIVE_DIR` bleibt unter `/var`. Neue und alte
+  Pfade dürfen keine Backup-Quellen einschließen oder in Quellen liegen.
+- Die normale gemeinsame Backup-Sperre wird gehalten. Bestehende Recovery-Marker,
+  belegtes Staging, unbekannte Zielkopien, Symlinks, Hardlinks, fremde Besitzer,
+  beschreibbare Archive und zu wenig Platz führen zum Abbruch. Vor der
+  Konfigurationsaktivierung laufen die echten `--prepare-space`- und `--check`-
+  Prüfungen mit der vorgeschlagenen Konfiguration und geerbter echter Sperre.
+- `MIN_FREE_GB`, Aufbewahrung und Schätzung bleiben unverändert. Auf `/` verbleiben
+  mindestens die konfigurierte Reserve plus 2 GiB. Auf `/var` wird Platz für das
+  zuletzt beobachtete Snapshotbudget plus Reserve plus 10 GiB zusätzlichen
+  Spielraum geschaffen. Die aktuelle Live-Schätzung ist trotzdem maßgeblich.
+
+Danach wird der normale `app-backup.service` gestartet. Der erfolgreiche
+Reparaturauftrag bestätigt nur die Vorbereitung und das Einreihen dieses Laufs.
+Erst dessen `SUCCESS` einschließlich Offsite-Prüfung bestätigt die Backup-Abnahme.
+Der Kopier-/Dumpabschnitt hält wie bisher die konfigurierten Writer kurz an.
+
+Bei Teilfehlern bleiben verifizierte Zielkopien erhalten. Die alte Konfiguration
+wird bis zum erfolgreichen Preflight nicht ersetzt. Eine Rücknahme der
+Konfiguration allein stellt verlagerten Bestand und freien Platz nicht zurück;
+kein blindes Zurückkopieren oder Löschen. Den Nachweis pro Objekt zur gezielten
+Wiederherstellung beziehungsweise Auswahl historischer Restore-Quellen nutzen.
+
+Sieben lokale Tests prüfen Datei- und Verzeichnisverlagerung, Kopierkorruption
+mit erhaltenem Original, Schutz vor Quellenüberschneidung/Links und Platzreserve.
+Die produktive Abnahme und ein vollständiger Restore-Test stehen weiterhin aus.