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:
1 parent
a79f48bc2a
commit
6737405b35
10 files changed
+601
-31
No files matched your search
+101
@@ -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
|
||||
|
||||
Reference in new issue
Block a user