Recover backup capacity with verified adaptive retention

Resume pending publications under local pressure, allow verified offsite-only history as a final local recovery stage, and prune old complete remote sets against actual upload quota while preserving the newest verified copies. Document defaults, recovery limits and validation; add pressure and quota regression coverage.
This commit is contained in:
admin committed 2026-10-22 15:08:35 +02:00
1 parent a79f48bc2a
commit 6737405b35
10 files changed
+601 -31

No files matched your search

+101
View File
@@ -1,5 +1,106 @@
# Automatische Speicherbereinigung
## Adaptive Bereinigung bei Platznot – 22.10.2026
Der Bericht vom 22.10. nennt 74.630.297.390 benötigte und 59.122.741.248 freie
Bytes auf `/var`: Es fehlen 15.507.556.142 Bytes (14,44 GiB). Die geschützte
hochgeladene lokale Sicherung belegt 34.408.038.400 Bytes (32,05 GiB).
Ihre Freigabe kann diesen Engpass lösen. Eine Löschung in OneDrive schafft dagegen
keinen Platz auf Gemini. Der historische/unbestätigte Satz wird nicht blind entfernt.
Die folgende Strategie ersetzt die frühere unbedingte lokale Mindestkopie.
Neue Standardwerte gelten auch bei bestehenden Konfigurationen ohne diese Einträge:
```bash
SPACE_KEEP_LOCAL=1
SPACE_ALLOW_REMOTE_ONLY=true
SPACE_REMOTE_CLEANUP=true
SPACE_KEEP_REMOTE=1
```
1. Wie bisher: erkannte Arbeitsreste bereinigen, Snapshotbedarf plus Reserve
schätzen, Writer erst nach erfolgreichem Preflight anhalten.
2. Vor einem Upload die Remote-Quote über `rclone about --json` abfragen.
Unter Platzdruck darf `SPACE_REMOTE_CLEANUP=true` ältere vollständige v2-Sätze
unabhängig von Altersretention und `ENABLE_REMOTE_RETENTION` entfernen.
Die neuesten `SPACE_KEEP_REMOTE` geprüften vollständigen Sätze bleiben erhalten
(Default und Minimum eins). Nur Verzeichnisse mit passendem Laufnamen,
gültigem Manifest und Abschlussmarker sowie vollständigem Dateibestand in
Manifestgrößen zählen als gültig. Unvollständige, unbekannte oder abweichende
Bestände werden weder gelöscht noch als Rückfallkopie gezählt. Vor jeder
Entfernung werden Kandidat und geschützte Rückfallkopien erneut geprüft.
Der aktuelle Upload und eine ausdrücklich ausgewählte Remote-Restore-Quelle
werden ausgenommen. Gelöscht wird ältester Satz zuerst, nur bis ausreichend
Quote verfügbar ist. Der Quotenbedarf enthält zusätzlich 5 % plus 1 MiB für
Verschlüsselungs-/Datei-Overhead. Nach jeder Entfernung wird die Quote neu
gelesen; ein erfolgreicher Purge gilt nicht als Beleg für freien Speicher.
3. Bei lokalem Archivplatzmangel vollständige unbestätigte lokale v2-Sätze prüfen.
Ist ihre Remote-Veröffentlichung schon vollständig und identisch, wird der
lokale `UPLOADED`-Marker nach erneuter Prüfung nachgetragen. Andernfalls wird
der Upload mit `--immutable` wiederholt: Archive und Manifest zuerst,
Dateiprüfung, Abschlussmarker zuletzt, Identitätsprüfung, dann `UPLOADED`.
Fehlerhafte, unvollständige oder weiterhin nicht veröffentlichte Sätze bleiben
geschützt. Eine beschädigte Remote-Datei wird nicht überschrieben.
4. Zunächst wie bisher ältere bestätigte lokale Kopien bis `SPACE_KEEP_LOCAL`
bereinigen. Reicht das nicht, erlaubt `SPACE_ALLOW_REMOTE_ONLY=true` auch die
Freigabe dieser lokalen Mindestkopien, wenn ihre belegten Blöcke das Defizit
voraussichtlich decken können. Auch hier: vollständige lokale Inhaltsprüfung,
Remote-Dateien/-Größen sowie bytegleiche Remote-Manifeste und Abschlussmarker;
erst danach lokale Entfernung, ältester Satz zuerst, erneute Platzmessung und
Stopp bei ausreichender Kapazität. Eine ausgewählte lokale Restore-Quelle
bleibt ausgeschlossen. Mit `SPACE_ALLOW_REMOTE_ONLY=false` bleibt die bisherige
feste lokale Untergrenze erhalten.
5. Vor der Veröffentlichung des neuen lokalen Satzes Remote-Quote anhand seiner
tatsächlichen Archivgröße prüfen. Das unkomprimierte Snapshotbudget ist keine
Remote-Platzanforderung und blockiert keinen kleineren komprimierten Upload.
Nach erfolgreichem Lauf bleibt der neue lokale Satz erhalten; die normale Altersretention gilt weiterhin separat.
**Abwägung:** In der letzten lokalen Notstufe kann bis zur Fertigstellung des
neuen Backups ausschließlich die geprüfte Offsite-Sicherung existieren. Schlägt
der neue Lauf fehl, steht diese weiter bereit; ein lokaler Restore erfordert dann
zunächst einen Download. Die Prüfungen lesen keine Archive aus OneDrive zurück.
Gleich große Inhaltsbeschädigungen erkennt erst der vollständige Restore-Test.
Die Änderungen ersetzen dessen weiterhin offene produktive Abnahme nicht.
`SPACE_REMOTE_CLEANUP=false` deaktiviert Quotenbereinigung, `SPACE_KEEP_REMOTE`
erhöht die geschützte Remote-Anzahl. Die normale Altersretention behält ihre
separaten Werte `RETENTION_KEEP_LAST`, `LOCAL_RETENTION_DAYS` und
`REMOTE_RETENTION_DAYS`; Quotenbereinigung ändert diese Konfiguration nicht.
`--no-retention` unterdrückt weiterhin nur die normale Altersretention, nicht
die notwendige lokale oder Remote-Platzbeschaffung. `--check` bleibt ohne
Bereinigung, Upload oder Remote-Löschung. `--prepare-space` kann diese Schritte
bereits ausführen und stoppt dabei keine produktiven Writer.
Kann das Backend keine brauchbare freie Quote melden, wird dies protokolliert;
es erfolgt keine Remote-Notbereinigung, der normale Upload wird weiter versucht.
Signalisierte Abbrüche werden weitergereicht. Bei nicht freigegebener Provider-
Quote (z. B. verzögerte Abrechnung), ausschließlich geschützten Beständen,
Remote-Prüffehlern oder einem selbst für einen neuen Satz zu kleinen Dateisystem
bleibt ein gezielter Abbruch erforderlich. Keine Automatik kann diese Fälle
sicher durch Löschen der letzten Offsite-Sicherung lösen. Speicherreserve,
Recovery-Journale, historische Formate, Mounts und unbekannte Daten bleiben geschützt.
Installation erfolgt als vollständiges Update-Paket nach
[UPDATE_ANLEITUNG.md](UPDATE_ANLEITUNG.md). Der dortige alte Abnahmenachweis vom
19.10. gilt für den damaligen Stand. Der Fix vom 22.10. muss nach Installation
auf Gemini anhand des nächsten erfolgreichen Backup-Berichts abgenommen werden.
### Lokale Prüfung am 22.10.2026
Shell-Syntax und ShellCheck bestanden. Von 157 Testfällen bestanden alle 149
aktivierten Fälle; acht optionale Tests für echten User-systemd beziehungsweise
Docker-Restore bleiben übersprungen. Die Suite verwendet echte Archive, eine
isolierte MariaDB und lokale rclone-Crypt-Ziele. Geprüft sind insbesondere ein
neuer erfolgreicher Backup-/Upload-Lauf nach Freigabe der letzten lokalen Kopie,
fehlende beziehungsweise beschädigte Offsite-Metadaten, nachgeholte Uploads,
Quotenbereinigung mit erhaltener neuester Offsite-Sicherung, unveränderte Quote
nach Purge, unbekannte Quote, Abbruchsignale und die Verwendung komprimierter
Archivgrößen statt des Snapshotbudgets für die Remote-Platzprüfung.
Die produktive Installation und Abnahme auf Gemini sind damit nicht ersetzt.
Die folgenden datierten Abschnitte dokumentieren frühere Stände; bei abweichenden
Schutzgrenzen und Upload-Regeln gilt die oben beschriebene Strategie vom 22.10.2026.
## Platznot vor dem Backup: Korrektur vom 21.09.2026
Der Mailbericht vom 20.09. nennt 55.823.183.174 benötigte und