Recover disk space safely and complete metadata-only backup updates

Dokumentation.md

@@ -1,10 +1,17 @@
 # Dokumentation app-backup v2
 
-**Aktualisiert am 15. September 2026:** Das Code-Paket `3730ab4676a5` enthält
-den lokal geprüften Schutz laufender Writer-Stopps gegen konkurrierende
-Healthcheck-Aufträge. Code und Paket sind bereitgestellt; Installation und neue
-Abnahme auf Gemini sind noch nicht bestätigt. Aktuelle Deployment-Befehle und
-Erfolgskriterien stehen in der [Update-Anleitung](UPDATE_ANLEITUNG.md#deployment-des-bereitgestellten-pakets-3730ab4676a5).
+**Aktualisiert am 21. September 2026:** Die Platzbereinigung schützt mit
+`SPACE_KEEP_LOCAL=1` mindestens eine vollständig geprüfte, als hochgeladen markierte
+lokale Sicherung; reguläre Retention und Speicherreserve bleiben separat bestehen.
+Manifest und Abschlussmarker werden vor lokaler Entfernung bytegenau remote verglichen.
+Siehe [Speicherstrategie und Fehlerbehebung](SPEICHER.md).
+
+Seit 16. September 2026: Backup, Platzbereinigung und Update-Abnahme
+prüfen remote nur Dateiexistenz und Größen; Archive werden erst beim monatlichen
+Restore-Test vollständig geladen. Der Abschlussmarker wird weiterhin bytegenau
+bestätigt. Die neue Option `--enable-ai-rem` nimmt auf Gemini die Daten und
+Konfiguration samt Writer-Stopps wieder auf. Installation auf Gemini steht aus.
+Aktuelle Befehle: [Update-Anleitung](UPDATE_ANLEITUNG.md).
 
 Stand des Reviews: 10. September 2026. Untersucht wurde der Gitea-Stand `099688e` einschließlich Backup, Restore, Installer, Konfiguration, systemd und bisheriger README. Die Erweiterung wird als zusammengehöriges Paket installiert; einzelne Skripte dürfen nicht ohne die gemeinsamen Bibliotheken aktualisiert werden.
 
@@ -17,8 +24,8 @@ Stand des Reviews: 10. September 2026. Untersucht wurde der Gitea-Stand `099688e
 | **Kritisch:** Nextcloud-Wartungsmodus wurde nach dem DB-Dump vor der Dateikopie ausgeschaltet. WordPress blieb live. | Datenbank und Dateien konnten unterschiedliche Zustände abbilden. | Gemeinsames Ruhefenster über sämtliche Dumps und Dateikopien. |
 | **Hoch:** Maildienste hatten keine zuverlässige Wiederanlaufbehandlung; Fehler und rsync-Teilergebnisse wurden ignoriert. | Unvollständige Mailsicherung oder unbeabsichtigte Dienstausfälle. | Zustandsabhängige Stopps, geprüfter Wiederanlauf, Exit-Code und Wiederanlaufdatei. |
 | **Hoch:** Crypt-Prüfung ließ u. a. `no_data_encryption=true` und reine Namensverschleierung zu. Restore verlangte dagegen explizite Optionen, obwohl sichere Defaults gültig sind. | Inhalt konnte trotz Remote-Typ `crypt` unverschlüsselt bleiben; gültige Remotes konnten abgelehnt werden. | Gemeinsame Prüfung von Typ, Inhalt, Dateinamen und Verzeichnisnamen; Defaults werden berücksichtigt. |
-| **Hoch:** `--checksum` und Remote-Listing ersetzten keine Prüfung des entschlüsselten Inhalts. | Transfererfolg war kein belastbarer Rücklesetest. | Vollständiger `rclone check --download` vor Veröffentlichung des Abschlussmarkers. |
-| **Hoch:** Retention lief vor dem neuen Backup und löschte remote einzelne alte Objekte rekursiv. | Alte Wiederherstellungspunkte konnten verloren gehen, bevor ein neuer verfügbar war; Sätze konnten unvollständig werden. | Reguläre Retention nach einem neuen erfolgreichen Lauf; zusätzliche lokale Platzbereinigung nur mit erneuter Offsite-Inhaltsprüfung und Mindestanzahl. |
+| **Hoch:** `--checksum` und Remote-Listing ersetzten keine Prüfung des entschlüsselten Inhalts. | Transfererfolg war kein belastbarer Rücklesetest. | Lokale Inhaltsprüfung; seit 16.09. Remote-Datei-/Größenprüfung vor dem Marker, vollständige Remote-Inhaltsprüfung beim Monats-Restore. |
+| **Hoch:** Retention lief vor dem neuen Backup und löschte remote einzelne alte Objekte rekursiv. | Alte Wiederherstellungspunkte konnten verloren gehen, bevor ein neuer verfügbar war; Sätze konnten unvollständig werden. | Reguläre Retention nach einem neuen erfolgreichen Lauf; zusätzliche lokale Platzbereinigung nur mit erneuter Remote-Datei-/Größenprüfung und Mindestanzahl. |
 | **Hoch:** Drei nicht als Vorlage gekennzeichnete DB-Dateien enthielten mögliche echte Zugangsdaten. | Geheimnisse im aktuellen Baum und in der Git-Historie. | Dateien entfernt, ausschließlich Vorlagen, `.gitignore`; Passwortrotation bleibt Betriebsaufgabe. Keine Historienumschreibung. |
 | **Hoch:** Gitea war im ausgelieferten Config-Beispiel nicht eingeschaltet; `APP_DATA_PATH` allein deckt externe Repositories/custom nicht ab. | Erwartete Gitea-Daten konnten fehlen. | Sichtbarer Aktivierungsschalter und zusätzliche Pfade; erforderliche Verzeichnisse fehlen nicht stillschweigend. |
 | **Mittel:** Konfigurierbare WordPress-Excludes wurden nicht vollständig angewendet; Nextcloud `data/` war fest angenommen. | Falscher Umfang bei abweichender Verzeichnisstruktur. | Ableitung relativer Excludes aus den konfigurierten Pfaden, auch beim Restore. |
@@ -26,14 +33,14 @@ Stand des Reviews: 10. September 2026. Untersucht wurde der Gitea-Stand `099688e
 | **Mittel:** Installer aktivierte den Timer sofort und überschrieb Unit-Dateien ohne Rückweg. | Ungeprüfte Erstläufe; individuelle Zeitpläne konnten verloren gehen. | Config-/Timer-Erhalt, `.dist`-Vorlagen, gemeinsame Sperre, Rollback-Paket, frische Timer zunächst aus. |
 | **Mittel:** Eigene Logdatei je Lauf plus `logrotate`/`notifempty`. | Rotierte Dateien konnten wegen leerer Nachfolgedateien dauerhaft liegen bleiben. | Altersbasierte Bereinigung neuer Laufprotokolle nach erfolgreichen Backups. |
 
-Die vollständige Rückleseprüfung erhöht den Datenverkehr um ungefähr die hochgeladene komprimierte Datenmenge. Dieser Aufwand ist bewusst Teil des Sicherheitskonzepts.
+Die vollständige Rückleseprüfung findet seit 16.09.2026 beim monatlichen Restore-Test statt. Tägliche Backups und Update-Abnahmen laden keine Archive zurück. Gleich große Remote-Beschädigungen können deshalb erst beim Restore erkannt werden.
 
 ## Sicherheitsziel und Grenzen
 
 Das Paket soll Fehler sichtbar machen, vollständige Sicherungssätze erhalten und eine nachprüfbare Wiederherstellung ermöglichen. Es kann keine absolute Datensicherheit garantieren. Folgende Ebenen sind getrennt zu betrachten:
 
 1. **Vertraulichkeit:** Das Crypt-Remote verschlüsselt Inhalt und Namen vor dem Upload. Lokales Staging, lokale Archive und entpackte Restores sind Klartext und benötigen ein verschlüsseltes Servervolume, sichere Dateirechte und Zugriffsschutz.
-2. **Integrität:** SHA-256, Kompressions-/Tar-Prüfung, Manifest und Rückleseprüfung erkennen fehlende bzw. veränderte Bestandteile. Das Manifest ist nicht digital signiert. Wer Archive und Manifest gemeinsam kontrolliert, kann neue passende Prüfsummen erzeugen.
+2. **Integrität:** SHA-256, Kompressions-/Tar-Prüfung, Manifest und monatliche Rückleseprüfung erkennen fehlende bzw. veränderte Bestandteile. Das Manifest ist nicht digital signiert. Wer Archive und Manifest gemeinsam kontrolliert, kann neue passende Prüfsummen erzeugen.
 3. **Konsistenz:** Alle relevanten Writer müssen während der Dumps/Kopien ruhen. Nicht erfasste Cronjobs, externe DB-Schreiber, systemd-Sockets, Container, S3-Speicher oder Remote-Mounts werden nicht automatisch eingefroren. Ein erfolgreicher Dateivergleich beweist keine Anwendungskonsistenz.
 4. **Verfügbarkeit:** OneDrive mit demselben löschberechtigten Konto ist keine unabhängige, unveränderliche Kopie. Für Schutz vor kompromittiertem Server/Konto, Ransomware oder versehentlicher Löschung eine weitere getrennte bzw. offline/immutable Sicherung vorsehen.
 5. **Wiederherstellbarkeit:** Ein getesteter Restore mit Anwendungskontrollen ist erforderlich. Passende Anwendungsversionen, Systempakete, UID/GID, Datenbankrechte und außerhalb des Umfangs liegende Schlüssel/Konfigurationen müssen verfügbar sein.
@@ -51,7 +58,7 @@ flowchart TD
     E --> F[Je Komponente komprimieren und Tar-Inhalt prüfen]
     F --> G[Manifest und lokaler COMPLETE-Marker]
     G --> H[Archive und Manifest über Crypt hochladen]
-    H --> I[Alles entschlüsselt zurücklesen und vergleichen]
+    H --> I[Remote-Dateiexistenz und Größen prüfen]
     I --> J[COMPLETE zuletzt hochladen und zurücklesen]
     J --> K[Retention vollständiger Sätze / Status / Bericht]
 ```
@@ -65,7 +72,7 @@ Sie gehen nach stderr; Marker und Dateilisten auf stdout bleiben maschinell
 auswertbar. Alte Konfigurationen erhalten den Intervallstandard automatisch.
 Eine Anpassung wirkt erst beim nächsten rclone-Prozess. Die bestehende
 I/O-Leerlauffrist `RCLONE_TIMEOUT="1h"` ist keine Gesamtlaufzeitbegrenzung.
-Für vollständige Rücklesevergleiche gelten seit 15.09.2026 eigene kürzere
+Für Remote-Dateiprüfungen und monatliche Downloads gelten eigene kürzere
 Leerlauffristen, eine Prozessfrist je Versuch und mehrere vollständige Versuche.
 Dort zeigen mehrzeilige Statistiken aktive Prüfungen und ein Ergebnis pro Datei
 den tatsächlichen Fortschritt. Details: [Rückleseprüfung](REMOTE_READBACK.md).
@@ -130,7 +137,7 @@ Ein neuer Lauf heißt beispielsweise `appbackup_2026-09-10_02-30-00_a1b2c3d4`. Z
   ...
   manifest.json
   COMPLETE
-  UPLOADED                # nur lokal, nach erfolgreicher Remote-Rückleseprüfung
+  UPLOADED                # nur lokal, nach erfolgreicher Remote-Datei-/Größenprüfung und Markerbestätigung
 ```
 
 | Komponente | Inhalt / Ziel aus lokaler Config |
@@ -154,7 +161,7 @@ Indexbasierte Pfade müssen ihre Reihenfolge behalten. Bei `extra-*` und `mail-h
 
 Zielumgebung: Rocky Linux 10 mit systemd und nativen Anwendungen. Die automatische Datenbankbehandlung ist auf MariaDB/MySQL ausgerichtet; PostgreSQL, SQLite-Livekopien und Container-Volume-Snapshots benötigen ein eigenes Verfahren.
 
-Erforderliche Werkzeuge: Bash ≥ 4.4 (`inherit_errexit`), Python ≥ 3.9, GNU coreutils/findutils/tar, `flock`, `rsync`, `gzip`/`zstd`, `systemctl`; bei Nextcloud `sudo` und CLI-PHP; für Datenbanken `mariadb-dump`/`mariadb` oder kompatible MySQL-Clients. Ein konfiguriertes Crypt-Remote benötigt rclone mit den verwendeten Crypt-Flags und `check --download`; die Integrationstests laufen auch mit rclone 1.60.1. Für den tatsächlichen Server einen aktuell gepflegten rclone-Stand einsetzen und `--check` ausführen.
+Erforderliche Werkzeuge: Bash ≥ 4.4 (`inherit_errexit`), Python ≥ 3.9, GNU coreutils/findutils/tar, `flock`, `rsync`, `gzip`/`zstd`, `systemctl`; bei Nextcloud `sudo` und CLI-PHP; für Datenbanken `mariadb-dump`/`mariadb` oder kompatible MySQL-Clients. Ein konfiguriertes Crypt-Remote benötigt rclone mit den verwendeten Crypt-Flags und `check --size-only`; die Integrationstests laufen auch mit rclone 1.60.1. Für den tatsächlichen Server einen aktuell gepflegten rclone-Stand einsetzen und `--check` ausführen.
 
 Ein Ausgangspunkt auf Rocky, abhängig von aktivierten Paketquellen und vorhandener PHP-Version:
 
@@ -189,15 +196,14 @@ Vorhandene Passwörter/Salt und Zuordnung **nicht neu generieren**, wenn bestehe
 sudo rclone --config /root/.config/rclone/rclone.conf lsd OneDriveCrypt:
 ```
 
-`rclone check --download` vergleicht die heruntergeladenen Inhalte und benötigt keinen gemeinsamen Backend-Hash. Es verändert die geprüften Dateien nicht. Das Paket verwendet es vor dem abschließenden Marker. Quelle: [rclone check](https://rclone.org/commands/rclone_check/).
+`rclone check --size-only` prüft Dateiexistenz und Größe ohne Archivdownload. Das Paket verwendet es vor dem abschließenden Marker. Die Remote-Inhalte werden erst beim monatlichen Restore-Test anhand der SHA-256-Werte im Manifest geprüft. Quelle: [rclone check](https://rclone.org/commands/rclone_check/).
 
 Exportierte `RCLONE_*`-Variablen sind ausschließlich für die vom Paket ausdrücklich
 unterstützten Einstellungen und `RCLONE_CONFIG_PASS` erlaubt. Andere Optionen
 werden vor dem ersten rclone-Aufruf und vor dem Writer-Stopp mit ihrem Namen,
-ohne ihren Wert, abgewiesen. Insbesondere kann `RCLONE_SIZE_ONLY=true` in rclone
-auch bei `check --download` den Inhaltsvergleich überspringen. Ein Regressionstest
-hat diesen Fehler vor der Härtung mit einer veränderten Remote-Datei gleicher Größe
-reproduziert. Zusätzliche Filter, Dry-run- und TLS-Overrides aus der Umgebung werden
+ohne ihren Wert, abgewiesen. Auch `RCLONE_SIZE_ONLY` bleibt als globale
+Umgebungsvariable verboten: Der Größenvergleich wird ausschließlich am Check-Aufruf
+gesetzt. Zusätzliche Filter, Dry-run- und TLS-Overrides aus der Umgebung werden
 ebenfalls abgewiesen. Einstellungen über die dokumentierte Backup-Konfiguration
 und Remote-Definitionen verwalten; eine absichtlich manipulierte root-eigene
 Bash-Konfiguration liegt außerhalb dieser Absicherung.
@@ -209,9 +215,9 @@ Quelle: [rclone 1.74.3 Inhaltsprüfung](https://github.com/rclone/rclone/blob/v1
 | --- | --- |
 | Vorübergehender Upload-Fehler | rclone wiederholt den Kopierauftrag bis zu `RCLONE_RETRIES=6` Versuche, soweit der Fehler wiederholbar ist; Wartezeit standardmäßig `RCLONE_RETRIES_SLEEP=30s`, zusätzlich gegebenenfalls Provider-Backoff. Kein erneuter DB-Dump oder Writer-Stopp innerhalb dieser Versuche. |
 | Upload endgültig fehlgeschlagen | Fehlerexit; lokaler vollständiger Satz bleibt erhalten; Staging wird nach erfolgreichem Dienstwiederanlauf bereinigt. Kein neuer Remote-Abschlussmarker und keine nachgelagerte Altersretention. |
-| Rückleseprüfung scheitert oder hängt | Bis zu drei vollständige Prüfanläufe, jeweils maximal 3600 Sekunden plus bis zu 10 Sekunden Abbruchfrist, 30 Sekunden Pause dazwischen. Jeder Versuch vergleicht alle ausgewählten Inhalte erneut. Bleibt ein Fehler, Fehlerexit und kein Abschlussmarker. Auch gleich große Dateien werden inhaltlich verglichen. |
+| Remote-Dateiprüfung scheitert oder hängt | Bis zu drei Metadaten-Prüfanläufe, jeweils maximal 3600 Sekunden plus bis zu 10 Sekunden Abbruchfrist, 30 Sekunden Pause dazwischen. Jeder Versuch prüft alle ausgewählten Dateinamen und Größen erneut. Bleibt ein Fehler, Fehlerexit und kein Abschlussmarker. Keine Archivdownloads; gleich große Beschädigungen erkennt erst der Restore. |
 | Abschlussmarker kann nicht geschrieben oder bestätigt werden | Fehlerexit; kein lokales `UPLOADED`, kein neuer Erfolgsstatus, keine Retention. Der Vergleich prüft die exakten Bytes einschließlich abschließender Zeilenumbrüche, passend zum strikten Restore-Parser. Ist der Marker schon geschrieben und nur seine Bestätigung fehlgeschlagen, kann der Remote-Satz vollständig vorliegen; der Lauf meldet konservativ trotzdem einen Fehler. |
-| Wiederholungen erfolgreich und Rücklesen bestanden | Remote-Marker wird zuletzt geschrieben und zurückgelesen; erst danach gilt der Upload als erfolgreich. Ein früheres `ERROR` im Log allein ist kein Endergebnis. |
+| Wiederholungen erfolgreich und Remote-Dateiprüfung bestanden | Remote-Marker wird zuletzt geschrieben und zurückgelesen; erst danach gilt der Upload als erfolgreich. Ein früheres `ERROR` im Log allein ist kein Endergebnis. |
 | Prozess hängt oder wird abgebrochen | systemd begrenzt den regulären Backup-Dienst auf 12 Stunden, den Update-Auftrag auf 24 Stunden, mit 5 Minuten Stop-Frist. Direkte CLI-/Foreground-Aufrufe besitzen diese systemd-Gesamtfrist nicht. |
 
 HTTP 409 benötigt nach dem beobachteten erfolgreichen Wiederholungsversuch keinen
@@ -224,10 +230,9 @@ Keine automatischen Remote-Löschungen oder Überschreibungen zur Konfliktbehebu
 serverseitiger WORM-/Ransomware-Schutz gegen andere berechtigte Zugriffe.
 
 Die sechs Gesamtversuche gelten nicht pauschal für jeden rclone-Befehl:
-`check --download` verwendet in rclone 1.74.3 keine Wiederholung des ganzen Befehls,
-jedoch Wiederholungen fehlgeschlagener Datei-Leseoperationen. Deshalb verwendet
-app-backup jetzt einen eigenen begrenzten Wrapper nur für vollständige
-Rücklesevergleiche (Backup und Platzbereinigung). Er greift auch mit alten
+`check` verwendet in rclone 1.74.3 keine Wiederholung des ganzen Befehls. Deshalb
+verwendet app-backup einen eigenen begrenzten Wrapper für Remote-Datei-/
+Größenvergleiche (Backup und Platzbereinigung). Er greift auch mit alten
 Konfigurationen. Uploads und manuelle `app-restore.sh`-Downloads behalten ihre
 bisherigen Einstellungen. Der separate monatliche Restore-Test verwendet seit
 dem Folgefix ebenfalls begrenzte Downloads; siehe [RESTORE_TEST.md](RESTORE_TEST.md).
@@ -351,7 +356,12 @@ Dateisystem-Metadaten und Wachstum. `MIN_FREE_GB` (Default 10 GiB) bleibt zusät
 frei. Erst nach erfolgreicher Platzbeschaffung werden Writer angehalten.
 
 Reicht Scratch-Bereinigung nicht, werden ältere geeignete lokale Sätze unter
-Wahrung von `RETENTION_KEEP_LAST` vollständig lokal und offsite zurückgelesen.
+Wahrung von `SPACE_KEEP_LOCAL` (Default und Minimum eins, seit 21.09.2026) lokal
+vollständig validiert und remote auf Dateiexistenz und passende Größen geprüft.
+Remote-Manifest und Abschlussmarker müssen zusätzlich bytegenau übereinstimmen.
+Dabei werden keine Archive geladen. Die normale Retention bleibt separat bei
+`RETENTION_KEEP_LAST` (Default drei). Bei weiterem Platzmangel nennt das Log das
+Defizit und die geschützten Archivbestände mit belegten Bytes und Schutzgrund.
 Nur danach darf ihre lokale Kopie entfernt werden. Offsite-Dateien bleiben
 unverändert. Diese Platzbereinigung gilt auch bei `--no-retention` während einer
 Update-Abnahme und kann das lokale Aufbewahrungsalter unterschreiten.
@@ -419,8 +429,9 @@ abgewiesen; ein Berichtsfehler verändert den Backup-Exit-Code nicht.
 
 Der UTF-8-Bericht enthält Zeit, Host, Status, Exit-Code, Dauer, Lauf-ID und letzte
 Phase, Konfigurations-/Arbeits-/Archivpfade, Kompression, Crypt-Ziel und getrennten
-Uploadstatus. Dieser wird erst nach erfolgreichem Rücklesen aller Inhalte und
-bytegenauer Markerbestätigung `OK`. Bei deaktiviertem Upload steht ausdrücklich
+Uploadstatus. Dieser wird erst nach erfolgreicher Remote-Datei-/Größenprüfung und
+bytegenauer Markerbestätigung `OK`. Der Bericht nennt den begrenzten Prüfumfang
+und verweist für die Inhaltsprüfung auf den Restore-Test. Bei deaktiviertem Upload steht ausdrücklich
 „nur lokal“; bei Fehlern bleibt die nicht abgeschlossene Uploadphase sichtbar.
 Ein Fehler bei nachgelagerter Retention kann deshalb korrekt `Status: FAIL` bei
 bereits verifiziertem Upload ergeben.
@@ -471,7 +482,7 @@ systemctl list-timers app-backup.timer
 
 Exit `0` bedeutet, dass die ausgeführten erforderlichen Schritte erfolgreich waren. Jeder Fehlercode ist ein Fehler; `130`/`143` kennzeichnen INT/TERM. `last-backup.json` wird beim Beenden geschrieben und zeigt während eines laufenden Backups noch den vorherigen beendeten Lauf. `last-successful-backup.json` wird ausschließlich nach einem vollständig erfolgreichen Backup aktualisiert. `--check` aktualisiert diese Erfolgsmarkierung nicht. Sehr frühe Fehler vor der Laufinitialisierung/Sperrübernahme können nur auf stderr bzw. im Journal erscheinen; deshalb sowohl Servicefehler als auch Alter des letzten Erfolgs überwachen. Bei `ENABLE_UPLOAD=false` belegt ein Erfolg nur eine lokale Sicherung; für Offsite-Überwachung zusätzlich die Upload-Konfiguration und `UPLOADED` des gemeldeten Satzes berücksichtigen.
 
-Für den täglichen Zeitplan z. B. bei mehr als 36 Stunden ohne erfolgreichen Lauf alarmieren, zusätzlich freien Speicher, offene Recovery-Dateien und wachsende Partial-Verzeichnisse prüfen. Diese Überwachung läuft idealerweise außerhalb des gesicherten Servers. `TimeoutStartSec=12h` und `TimeoutStopSec=5min` sind Ausgangswerte und müssen zum ersten gemessenen Vollbackup plus Rückleseprüfung passen.
+Für den täglichen Zeitplan z. B. bei mehr als 36 Stunden ohne erfolgreichen Lauf alarmieren, zusätzlich freien Speicher, offene Recovery-Dateien und wachsende Partial-Verzeichnisse prüfen. Diese Überwachung läuft idealerweise außerhalb des gesicherten Servers. `TimeoutStartSec=12h` und `TimeoutStopSec=5min` sind Ausgangswerte und müssen zum ersten gemessenen Vollbackup mit Upload und Remote-Dateiprüfung passen.
 
 Ein geplanter Backupabbruch erfolgt über `systemctl stop app-backup.service`. Normale INT-/TERM-Behandlung versucht die ursprünglichen Dienste wiederherzustellen. SIGKILL, Kernelabsturz oder Stromverlust können keine Shell-Traps ausführen. Dafür liegt `recovery-LAUFNAME.json` mit vorher aufgezeichnetem Wartungs-/Dienstzustand und Arbeitsordner im Workdir. Diese Datei ist eine manuelle Wiederanlaufhilfe, kein automatischer Neustartauftrag. Das System startet nicht blind Anwendungen über einen teilweise restaurierten Datenbestand.
 
@@ -562,11 +573,10 @@ wartete der Starter auf den oneshot-Abschluss, während der Worker auf seine
 Sperre wartete. Ursache, Diagnose und Wiederanlauf beschreibt die Update-Anleitung.
 
 Der Abnahmelauf nutzt `app-backup.sh --no-retention`: keine reguläre Altersretention;
-die sichere lokale Platzbereinigung bleibt erlaubt. Nach Upload/Rücklesevergleich
-prüft bei aktiviertem Monatstest `app-restore-test.sh --remote-run ...` den konkreten
-Satz vollständig mit Entpacken und isoliertem DB-Import. Andernfalls erfolgt eine
-komponentenweise Archivprüfung mit `app-restore.sh --verify-only`. Erst nach Erfolg
-werden die konfigurierten Timer aktiviert. Remote-Retention bleibt
+die lokale Platzbereinigung bleibt erlaubt. Nach Upload, Remote-Datei-/
+Größenprüfung und Markerbestätigung werden die konfigurierten Timer aktiviert.
+Die Update-Abnahme startet keinen Archivdownload und keinen Offsite-Restore.
+Entpacken und isolierter DB-Import finden beim Monatslauf statt. Remote-Retention bleibt
 nach dieser Migration bewusst aus, bis die fachliche Restore-Abnahme erfolgt ist.
 
 Direkt erkennbare Nextcloud-systemd-Writer werden übernommen. Bei klassischen
@@ -626,7 +636,7 @@ separate Abnahmen. Aktivierung und Prüfung auf Gemini erfolgen nach Installatio
 
 ### Entwicklungstests
 
-Aktuelle Verifikation vom 15.09.2026 für den Code-Stand `3730ab4676a5`:
+Historische Verifikation vom 15.09.2026 für den Code-Stand `3730ab4676a5`:
 119 Fälle im Standardlauf, davon 111 erfolgreich und acht planmäßig übersprungen
 (906,3 Sekunden). Die drei Benutzer-systemd-Fälle bestanden separat: alter
 Reload-Konflikt reproduziert, geschützter Stop gegen Reload und Start erfolgreich,
@@ -647,9 +657,9 @@ Geprüfte Fälle umfassen:
 - MTA-Fehler und begrenzter Versand-Timeout verändern den Backup-Exit-Code nicht; die lokale Nachricht bleibt erhalten. Header-Injection wird abgewiesen; Prüfläufe/Restore versenden keine Backup-Mail.
 - Paketupdate installiert die Berichtskomponente, erhält alte Mail-Einstellungen und erzeugt beim Abnahmebackup einen Bericht über die MTA-Attrappe.
 - Endgültiger Upload-Fehler trotz bereits übertragener Bytes: vollständiger lokaler Satz, vorheriger Erfolgsstatus und alte lokale/entfernte Retention-Kandidaten bleiben erhalten.
-- Veränderte Remote-Datei gleicher Größe, Marker-Schreibfehler, abweichender Marker-Inhalt und zusätzliche Zeilenumbrüche verhindern den lokalen Upload-Erfolg und die Retention.
+- Fehlende Remote-Dateien, falsche Größen, Marker-Schreibfehler, abweichender Marker-Inhalt und zusätzliche Zeilenumbrüche verhindern Upload-Erfolg und Retention. Gleich große Beschädigungen erkennt seit 16.09. erst der Restore.
 - Nicht unterstützte rclone-Umgebungsoptionen werden vor Remote-Zugriff und Writer-Stopp abgewiesen; unterstützte exportierte Einstellungen bleiben nutzbar.
-- Periodische NOTICE-Statistiken bei gedrosseltem echten Crypt-Upload, erfolgreicher Rückleseprüfung und Remote-Restore; die Statistik verändert den maschinell gelesenen Abschlussmarker nicht.
+- Periodische NOTICE-Statistiken bei gedrosseltem echten Crypt-Upload, erfolgreicher Remote-Dateiprüfung und separatem Remote-Restore; die Statistik verändert den maschinell gelesenen Abschlussmarker nicht.
 - Fremde Startversuche während realer rsync-Kopien werden durch das systemd-Testmodell übersprungen; zuvor inaktive Writer bleiben nach dem Lauf inaktiv.
 - Aktive sowie zwischenzeitlich gestartete und wieder gestoppte Writer verhindern die Veröffentlichung eines vollständigen Satzes.
 - Nicht geladene Startsperre, Erhalt vorhandener Maskierungen und fehlgeschlagene Sperrfreigabe mit erhaltener Wiederanlaufdatei.
@@ -664,8 +674,8 @@ Geprüfte Fälle umfassen:
 - Shell-Syntax und ShellCheck der Paketdateien.
 - MyISAM-Dump und tatsächlicher SQL-Import samt Dateiwiederherstellung.
 - gzip/zstd, korrekte Excludes, vorhandener Wartungsmodus und inaktive Dienste.
-- Lokaler Crypt-Upload mit vollständigem Rücklesen und Restore aus diesem Remote.
-- Fehler bei Dump, rsync, Kompression, Diensten und Remote-Rückleseprüfung.
+- Lokaler Crypt-Upload mit Remote-Dateiprüfung und separatem Restore aus diesem Remote.
+- Fehler bei Dump, rsync, Kompression, Diensten und Remote-Dateiprüfung.
 - Fehlende/beschädigte Archive, Pfadtraversal, Link-Pivots, unzulässige Tar-Dateitypen.
 - Gemeinsame Sperre, TERM-Abbruch, Prüflauf ohne falsche Erfolgsmeldung.
 - Selektiver Restore mit Löschung und Schutz ausgeschlossener Nextcloud-Daten.