Prepare MariaDB restore tests and recover backup disk space safely

UPDATE_ANLEITUNG.md

@@ -7,16 +7,21 @@ Wegen des knappen Speichers arbeitet er Komponenten einzeln ab und entfernt
 jeweils Archiv, entpackte Daten und Test-DB. Auch Fehler- und Abbruchpfade besitzen
 eine Bereinigung. Es bleiben nur kleine, begrenzte Betriebsnachweise.
 
-Vor dem Paketstart nach [RESTORE_TEST.md](RESTORE_TEST.md) ein lokales, zur
-Produktions-MariaDB passendes Docker-Image vorbereiten, Speichergrenzen prüfen und
-`ENABLE_RESTORE_TEST=true` sowie `RESTORE_TEST_DB_IMAGE` in der aktiven Konfiguration
-setzen. Die zusätzliche Vorprüfung kontrolliert lokale Voraussetzungen, ohne
-Images oder Backups herunterzuladen. Fehlende Voraussetzungen stoppen die
-Vorbereitung vor der Installation. Nach erfolgreicher Update-Abnahme aktiviert
-der Installer den monatlichen Timer (1., 06:00 Uhr Serverzeit) und die
-Boot-Bereinigung. Der erste echte Restore-Test hat eine eigene Mail und
-`$WORKDIR/restore-test/state.json`; sein Erfolg ist separat zu kontrollieren.
+Mit `--enable-restore-test` übernimmt der Installer die MariaDB-Vorbereitung:
+Produktionsserie lesen, passendes lokales Image wiederverwenden oder laden und
+einen isolierten Probeimport einschließlich Bereinigung ausführen. Manuelles
+`docker pull` ist auf Gemini nicht mehr erforderlich. Die Option aktiviert
+zugleich das adaptive Arbeitsbudget; Details: [RESTORE_TEST.md](RESTORE_TEST.md).
+Danach prüft der Worker sein neues Offsite-Backup vollständig mit Entpacken und
+DB-Import. Erst bei Erfolg aktiviert er Monatstimer und Boot-Bereinigung.
 
+Vor der Vorprüfung werden erkannte Überreste fehlgeschlagener Backups bereinigt
+und der nächste Snapshot geplant. Reicht der Platz nicht, werden geeignete ältere
+lokale Kopien nach vollständiger Offsite-Rückleseprüfung entfernt; die neuesten
+`RETENTION_KEEP_LAST` bleiben geschützt. Diese Platzbereinigung gilt auch während
+einer Update-Abnahme ohne reguläre Retention. Sie wird nicht durch Paketrollback
+rückgängig gemacht; entfernte vollständige lokale Sätze bleiben offsite verfügbar.
+[SPEICHER.md](SPEICHER.md) dokumentiert Grenzen und den Gemini-Fehlerfall.
 Bestehende Konfigurationen ohne `ENABLE_RESTORE_TEST` bleiben deaktiviert.
 Bestehende Restore-Test-Zeitpläne werden erhalten; neue Vorlagen liegen als `.dist`
 daneben. Bei einem Paketrollback werden die Test-Timer/-Bereinigungs-Units vor dem
@@ -33,7 +38,7 @@ auf den Server übertragen. Auf dem Server im selben Verzeichnis prüfen/starten
 
 ```bash
 sha256sum -c app-backup-update-VERSION.run.sha256
-sudo bash app-backup-update-VERSION.run
+sudo bash app-backup-update-VERSION.run --enable-restore-test
 ```
 
 VERSION durch den tatsächlichen Dateinamen ersetzen. Ein Git-Checkout auf dem
@@ -67,7 +72,7 @@ abschwächen und sind im Backup-Prozess nicht unterstützt.
 5. Crypt-Konfiguration, DB-Dateien, globales DB-Recht `RELOAD` und bei MariaDB
    Zugriff auf Routinen-Metadaten prüfen;
    vorhandene Schlüssel/Passwörter erhalten. Keine automatischen DB-Grants.
-6. Vorprüfung mit geschützten Kopien durchführen. rsync prüft außerdem den Zugriff
+6. Sichere Platzbereinigung und Bedarfsplanung unter gemeinsamer Sperre ausführen, dann Vorprüfung mit geschützten Kopien durchführen. rsync prüft außerdem den Zugriff
    auf Quellverzeichnisse und deren Attribute in einem privaten temporären
    Prüfbereich, ohne Datei-Inhalte zu kopieren. Bei Fehlern bleibt das installierte
    Paket samt Anwendungskonfiguration und Timer unverändert.
@@ -75,12 +80,15 @@ abschwächen und sind im Backup-Prozess nicht unterstützt.
    `--no-block` einreihen und die Sperren an ihn übergeben.
 8. Backup-Timer stoppen, Paket mit Rollback-Inventar installieren, Konfiguration
    atomar übernehmen und Rechte der aktiven root-eigenen Zugangsdaten korrigieren.
-9. Vollständiges Backup ohne lokale/Remote-Retention durchführen. Anschließend den
-   abgeschlossenen Satz nochmals über Crypt herunterladen und mit dem Restore prüfen.
+9. Vollständiges Backup ohne reguläre lokale/Remote-Altersretention durchführen.
+   Platzbereinigung bleibt erlaubt. Bei aktiviertem Restore-Test den Satz
+   komponentenweise herunterladen, entpacken und seine DB-Dumps isoliert importieren;
+   sonst alle Archive einzeln herunterladen und vollständig prüfen.
 10. Erst bei Erfolg den Backup-Timer aktivieren und das Ergebnis protokollieren.
 
 Es findet kein Import in produktive Anwendungen oder Datenbanken statt. Der
-Remote-Prüflauf belegt Archivlesbarkeit, ersetzt aber keinen fachlichen Test-Restore.
+Prüflauf belegt bei aktiviertem Restore-Test auch Entpacken und DB-Import, ersetzt
+aber keinen fachlichen Anwendungstest.
 
 ## Verlauf und Ergebnis