Prepare MariaDB restore tests and recover backup disk space safely

Dokumentation.md

@@ -12,7 +12,7 @@ Stand des Reviews: 10. September 2026. Untersucht wurde der Gitea-Stand `099688e
 | **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. | Retention ausschließlich nach einem neuen erfolgreichen Lauf, nur vollständige v2-Ordner, Mindestanzahl. |
+| **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:** 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. |
@@ -198,7 +198,7 @@ Quelle: [rclone 1.74.3 Inhaltsprüfung](https://github.com/rclone/rclone/blob/v1
 | Ereignis | Verhalten und Konsequenz |
 | --- | --- |
 | 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 und Staging bleiben erhalten; kein neuer Remote-Abschlussmarker und keine Retention in diesem Lauf. |
+| 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 findet andere oder fehlende Inhalte | Fehlerexit; keine Veröffentlichung des Abschlussmarkers. Auch gleich große Dateien werden inhaltlich verglichen. |
 | 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. |
@@ -318,19 +318,43 @@ Homes-Bestätigung; Details stehen in [UPDATE_ANLEITUNG.md](UPDATE_ANLEITUNG.md)
 
 ### Speicher, Retention und Protokolle
 
-`MIN_FREE_GB` ist eine Reserveprüfung auf den Staging- und Archivdateisystemen, keine genaue Prognose. Die Kopie braucht Platz für unkomprimierte Quelldaten und Dumps; Archive benötigen zusätzlich komprimierten Platz. Beim Restore kommen die private Kopie des Sicherungssatzes und entpackte Daten hinzu. Eine Platte kann zwischen Prüfungen volllaufen; der Lauf muss dann scheitern. Ausreichend Reserve und ein externes Kapazitätsmonitoring einplanen.
+Der Ablauf und die Löschgrenzen sind in [SPEICHER.md](SPEICHER.md) beschrieben.
+Vor echten Backups und der Update-Vorprüfung werden eindeutig erkannte alte
+Arbeitsreste bereinigt und Quellen mit identischen rsync-Excludes sowie lesenden
+DB-Größenabfragen inventarisiert. Die Platzschätzung enthält Reserven für Dumps,
+Dateisystem-Metadaten und Wachstum. `MIN_FREE_GB` (Default 10 GiB) bleibt zusätzlich
+frei. Erst nach erfolgreicher Platzbeschaffung werden Writer angehalten.
 
-Neue lokale Sätze liegen zunächst unter `.partial-LAUFNAME`. Bei Fehlern bleiben Arbeitsdaten zur Analyse liegen. Sie sind **keine abgeschlossenen Backups** und werden nicht durch die Retention entfernt. Nach Ursachenklärung gezielt löschen; keine pauschale automatische Löschung gescheiterter Arbeitsstände.
+Reicht Scratch-Bereinigung nicht, werden ältere geeignete lokale Sätze unter
+Wahrung von `RETENTION_KEEP_LAST` vollständig lokal und offsite zurückgelesen.
+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.
 
-Retention:
+Jede erfolgreich komprimierte Komponente wird vor dem Entfernen ihrer
+Arbeitskopie vollständig geprüft. Bei Fehlern werden Staging und unvollständige
+Archive nach erfolgreicher Dienstwiederherstellung ebenfalls entfernt. Vollständige
+lokale Sätze ohne Upload-Bestätigung, ungelöste Recovery-Zustände, manuelle Restores,
+historische Formate und unbekannte Ordner bleiben geschützt. Ein erkanntes
+altes Staging ohne Recovery-Journal kann auch aus vorherigen Paketständen
+bereinigt werden. Die Bedarfsschätzung ist keine harte Quote; externe Schreiber
+oder ungewöhnlich wachsende Dumps können weiterhin einen Abbruch verursachen.
+
+Remote-`--verify-only` benötigt jeweils nur ein komprimiertes Archiv; die lokale
+Variante prüft direkt ohne Kopie. Reguläre v2-Restores planen zusätzlichen Platz
+vor Download/Kopie und Entpacken ein und nutzen dieselbe lokale Platzbereinigung.
+Ein echter Restore benötigt weiterhin Platz für den vollständigen Arbeitsbestand;
+Fehlerdaten werden dort für eine manuelle Prüfung erhalten.
+
+Reguläre Altersretention:
 
 - Läuft erst nach Abschluss des neuen Backups und gegebenenfalls der kompletten Remote-Prüfung.
 - Erkennt nur v2-Laufnamen und einen zum Manifest passenden Abschlussmarker.
 - Löscht ganze Sätze, keine einzelnen Archivinhalte.
 - Berücksichtigt das UTC-Datum im Laufnamen und behält die jüngsten `RETENTION_KEEP_LAST` geeigneten Sätze; mindestens zwei sind vorgeschrieben, Default drei.
 - Lokale Sätze ohne `UPLOADED` werden bei aktiviertem Upload nicht gelöscht. Bei bewusst deaktiviertem Upload sind vollständige lokale Sätze löschbar.
-- Alte v1-Läufe, unbekannte Verzeichnisse, unvollständige Uploads und `.partial`-Verzeichnisse bleiben erhalten.
-- Remote-Retention ist in neuen Konfigurationen aus. Ein vorhandenes `ENABLE_REMOTE_RETENTION=true` bleibt beim Update erhalten und muss bei Bedarf bewusst geändert werden.
+- Alte v1-Läufe, unbekannte Verzeichnisse und unvollständige Uploads bleiben erhalten. Erkannte lokale Scratch-Reste werden durch die getrennte Platzbereinigung behandelt.
+- Remote-Retention ist in neuen Konfigurationen aus. Das automatische Update setzt `ENABLE_REMOTE_RETENTION=false`; eine spätere Aktivierung erfolgt bewusst in der Konfiguration.
 
 Retention prüft die Metadaten alter Sätze, nicht erneut deren gesamte Nutzdaten. Ein `COMPLETE`-Marker beweist den erfolgreichen Abschluss zum Erstellungszeitpunkt, keine ewige Verfügbarkeit. Regelmäßige unabhängige Rücklese-/Restore-Proben bleiben erforderlich. Remote-Metadaten, die sich nicht lesen/validieren lassen, werden konservativ ausgelassen; fehlgeschlagene eigentliche Löschungen führen zu einem fehlgeschlagenen Lauf.
 
@@ -512,10 +536,12 @@ Das behebt das gegenseitige Warten in den früheren Paketen: Ohne `--no-block`
 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`: keinerlei lokale oder entfernte
-Löschung alter Sicherungssätze. Nach Upload/Rücklesevergleich prüft zusätzlich
-`app-restore.sh --remote-run ... --verify-only` den erneut heruntergeladenen Satz.
-Erst danach wird der vorhandene Backup-Timer aktiviert. Remote-Retention bleibt
+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
 nach dieser Migration bewusst aus, bis die fachliche Restore-Abnahme erfolgt ist.
 
 Direkt erkennbare Nextcloud-systemd-Writer werden übernommen. Bei klassischen
@@ -562,11 +588,11 @@ geprüft und entpackt; komprimierte Eingaben werden vor DB-Imports entfernt.
 Temporäre Dateien und DB-Container werden bei Erfolg, Fehler und Abbruch
 bereinigt; systemd und eine Boot-Einheit übernehmen die Nachbereinigung.
 
-Die Defaults von 4 GiB Arbeitsbudget und 2 GiB freier Reserve sind an den
-tatsächlichen Platz und die größte Komponente anzupassen. Die Überwachung ist
+Standard sind ein adaptives Arbeitsbudget (`RESTORE_TEST_MAX_WORK_GB=0`) und
+2 GiB freie Reserve. Eine positive Budgetgrenze bleibt optional möglich. Die Überwachung ist
 keine harte Dateisystemquote. Ein nicht passender Sicherungssatz führt zu FAIL,
 nicht zu einer unbemerkten Teilprüfung. Protokolle und Berichte bleiben klein;
-ein vorab bereitgestelltes DB-Image bleibt als Abhängigkeit installiert.
+das vom Installer vorbereitete passende DB-Image bleibt als Abhängigkeit installiert.
 
 Der Test ergänzt die bisherige technische Archivprüfung um tatsächliches
 Entpacken und DB-Import mit Tabellenprüfung. Fachliche Anwendungswiederherstellung