Recover disk space safely and complete metadata-only backup updates

SPEICHER.md

@@ -1,5 +1,60 @@
 # Automatische Speicherbereinigung
 
+## Platznot vor dem Backup: Korrektur vom 21.09.2026
+
+Der Mailbericht vom 20.09. nennt 55.823.183.174 benötigte und
+47.615.086.592 verfügbare Bytes: Es fehlen 8.208.096.582 Bytes (7,64 GiB).
+Die alte Bereinigung schützt dieselben drei lokalen Kopien wie die reguläre
+Retention. Dadurch kann sie bereits vor dem nächsten Backup blockieren.
+
+`SPACE_KEEP_LOCAL=1` setzt jetzt eine eigene Untergrenze für Platznot, auch bei
+bestehender Konfiguration ohne diesen Eintrag. Die neuesten so vielen gültigen,
+als hochgeladen markierten lokalen Sätze bleiben erhalten. `RETENTION_KEEP_LAST=3`
+gilt weiterhin für die normale Retention und wird nicht verändert. Wer die alte
+Grenze ausdrücklich beibehalten möchte, setzt `SPACE_KEEP_LOCAL=3`. Null ist
+unzulässig. Die Reserve `MIN_FREE_GB=10` und die Snapshot-Schätzung bleiben bestehen.
+
+Gelöscht wird ältester Satz zuerst, nur bis der Bedarf gedeckt ist und nur nach
+vollständiger lokaler Inhaltsprüfung, Remote-Datei-/Größenvergleich und bytegenauem
+Vergleich von Remote-Manifest und `COMPLETE`. Für die beiden kleinen Kontrolldateien
+gelten dieselben begrenzten Versuche/Zeitlimits; Archive werden nicht heruntergeladen.
+Die geschützten neuesten lokalen Kopien werden zuvor ebenfalls vollständig geprüft.
+Ist eine davon beschädigt oder unvollständig, bleiben alle älteren Kandidaten
+erhalten; ein bloßer `UPLOADED`-Marker genügt nicht als Rückfallabsicherung.
+Signalisierte Abbrüche beenden die Bereinigung, statt weitere Kandidaten zu versuchen.
+Nach jeder Entfernung wird der tatsächlich freie Platz neu gemessen. Mountpoints,
+auch Bind-Mounts einzelner Dateien, werden nicht rekursiv gelöscht.
+
+Das schafft Platz, wenn ausreichend bestätigte lokale Kopien vorhanden sind.
+Bei geschützten Beständen, Remote-Fehlern oder einem zu kleinen Datenträger kann
+die Software keinen sicheren Platz erzwingen: Sie bricht vor dem Writer-Stopp ab
+und protokolliert Bedarf, Verfügbarkeit, Defizit sowie verbleibende Archivbestände
+mit belegten Bytes und Schutzgrund. Nicht bestätigte Uploads bleiben erhalten.
+Das Update führt diese Bereinigung bereits vor der Installation aus; sie ist
+daher auch dann wirksam, wenn der bisher installierte Stand nicht mehr starten kann.
+
+### Wenn die geschützten Bestände den Platz belegen
+
+`preflight.log` beziehungsweise das Backup-Log zeigt, ob bestätigte lokale Sätze
+oder unbestätigte/unklare Bestände übrig sind. Zunächst lesend prüfen:
+
+```bash
+sudo du -xhd2 /var/backups/app-backup
+df -h /var/backups/app-backup
+sudo find /var/backups/app-backup/archives -maxdepth 2 -name UPLOADED -printf '%h\n'
+```
+
+Unbestätigte vollständige Sätze müssen außerhalb dieses automatischen Ablaufs
+gesondert geprüft und offsite veröffentlicht oder auf einen anderen Datenträger
+verschoben werden. Keinen `UPLOADED`-Marker manuell vortäuschen. Reicht auch danach
+der Platz nicht, das Backup-Dateisystem erweitern oder `WORKDIR`/`STAGING_ROOT`/
+`ARCHIVE_DIR` auf einen ausreichend großen dedizierten Datenträger umstellen.
+Eine Verlagerung erfolgt bei gestoppten Backup-/Restore-/Update-Aufträgen; vorhandene
+Sätze, Besitzrechte und Modus 700 müssen erhalten bleiben. Anschließend
+`--prepare-space` und `--check` mit der neuen Konfiguration ausführen.
+Weder geschützte Recovery-Daten noch die letzte bestätigte lokale Sicherung
+werden als Ausweg automatisch gelöscht.
+
 Der auf Gemini gemeldete Abbruch vom 12.09.2026 erfolgte nach dem erfolgreichen
 Wiederanlauf der Dienste, während der Kompression: Unter `/var` waren nur noch
 9,2 GiB frei, die konfigurierte Reserve beträgt 10 GiB. Rund 29 GiB Staging und
@@ -27,19 +82,21 @@ oder der Update-Vorbereitung werden folgende Schritte ausgeführt:
    Platzprüfung werden produktive Writer angehalten.
 4. Bei Platzmangel ältere geeignete lokale v2-Sätze prüfen. Nur Sätze mit gültigem
    Manifest, `COMPLETE` und lokalem `UPLOADED` kommen infrage. Die neuesten
-   `RETENTION_KEEP_LAST` geeigneten Kopien bleiben geschützt (Default drei,
-   mindestens zwei). Ältere Kandidaten werden lokal vollständig validiert und mit
-   `rclone check --download` inklusive Manifest und `COMPLETE` erneut vollständig
-   gegen ihre Offsite-Kopie gelesen. Erst bei erfolgreicher Prüfung wird die lokale
-   Kopie entfernt. Ein nicht mehr lesbarer oder veränderter Remote-Satz bleibt
-   lokal erhalten. Es wird nur so lange bereinigt, bis der geplante Platz reicht.
+   `SPACE_KEEP_LOCAL` geeigneten Kopien bleiben geschützt (Default und Minimum eins).
+   Ältere Kandidaten werden lokal vollständig validiert und mit
+   `rclone check --size-only` inklusive Manifest und `COMPLETE` auf
+   Remote-Dateiexistenz und passende Größen geprüft (ohne Archivdownload). Erst bei erfolgreicher Prüfung wird die lokale
+   Kopie entfernt; zusätzlich müssen Remote-Manifest und `COMPLETE` bytegenau
+   mit den lokalen Dateien übereinstimmen. Fehlende Remote-Dateien oder Größenabweichungen verhindern die Löschung.
+   Gleich große Inhaltsbeschädigungen werden erst beim Restore erkannt. Es wird nur so lange bereinigt, bis der geplante Platz reicht.
 
 Diese Offsite-Vergleiche verwenden ebenfalls die begrenzten Prüfanläufe und
 Zeitlimits aus [REMOTE_READBACK.md](REMOTE_READBACK.md). Ein fehlgeschlagener
 Vergleich erlaubt auch nach mehreren Versuchen keine lokale Löschung.
 
 Die Platzbereinigung benötigt keinen vorherigen neuen Sicherungslauf. Sie darf
-das lokale Aufbewahrungsalter unterschreiten, **niemals die Mindestanzahl**.
+das lokale Aufbewahrungsalter und `RETENTION_KEEP_LAST` unterschreiten,
+**niemals die eigene Mindestanzahl `SPACE_KEEP_LOCAL`**.
 Sie verändert keine Offsite-Daten. Die normale Altersretention nach einem neuen
 erfolgreichen Backup bleibt davon getrennt. `--no-retention` im Update unterdrückt
 die Altersretention, erlaubt aber weiterhin die hier beschriebene Platzbereinigung.
@@ -60,7 +117,7 @@ fehlgeschlagen ist, bleibt erhalten.
 Folgende Daten bleiben geschützt:
 
 - vollständige lokale Sätze ohne bestätigten Upload;
-- die neuesten `RETENTION_KEEP_LAST` geeigneten lokalen Sicherungen;
+- die neuesten `SPACE_KEEP_LOCAL` geeigneten lokalen Sicherungen;
 - ein `.partial`-Verzeichnis, das bereits einen `COMPLETE`-Marker enthält;
 - sämtliche Arbeitsreste bei vorhandenem `recovery-*.json` oder angefangener
   Recovery-Datei: zunächst muss der Dienst-/Restore-Zustand geklärt werden;
@@ -112,8 +169,9 @@ von der Platzbereinigung ausgenommen.
 
 Das neue Update-Paket wie in [UPDATE_ANLEITUNG.md](UPDATE_ANLEITUNG.md) mit
 `--enable-restore-test` starten. Es bereinigt vor der Vorprüfung erkannte alte
-Arbeitsreste, bereitet MariaDB vor und führt Backup und vollständigen Restore-Test
-aus. Erst danach aktiviert es die Timer. Der alte fehlgeschlagene Update-Ordner
+Arbeitsreste, bereitet MariaDB vor und führt Backup mit Remote-Dateiprüfung
+aus. Nach erfolgreicher Update-Abnahme aktiviert es die Timer; der vollständige
+Restore-Test folgt beim Monatstermin. Der alte fehlgeschlagene Update-Ordner
 bleibt als Diagnose-/Rollback-Nachweis erhalten; ein pauschales `rm` ist unnötig.
 
 Nach bereits erfolgter Installation kann die Platzvorbereitung separat gestartet
@@ -127,9 +185,9 @@ df -h /var/backups/app-backup
 ```
 
 `--check` allein bleibt eine Prüfung ohne Bereinigung. Vollständige
-Offsite-Rückleseprüfungen während der Platzbeschaffung können dauern. Der Starter
+lokale Inhaltsprüfungen können dauern; remote werden nur Dateiexistenz und Größen geprüft. Der Starter
 nennt sein Verzeichnis mit `preflight.log`; der spätere Worker schreibt `update.log`
-und `result.txt`. `SUCCESS` im aktuellen `result.txt` und `cleanup: OK` im
-Restore-Teststatus sind die Abnahmenachweise. Scheitert ein Update trotz der
+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.