Prepare MariaDB restore tests and recover backup disk space safely

RESTORE_TEST.md

@@ -25,11 +25,15 @@ Der Spitzenbedarf ist ungefähr das Maximum aus:
 - SQL-Dump plus zugehöriger Testdatenbank einschließlich MariaDB-Systemtabellen,
   Indexen und temporären DB-Dateien.
 
-Standard: höchstens **4 GiB geplantes Test-Arbeitsvolumen**, zusätzlich mindestens
-**2 GiB freie Reserve**. Die Komponente muss vollständig in dieses Budget passen;
-sonst scheitert der Test mit einem Bericht und bereinigt seine Dateien. Es wird
-nicht still auf eine Zufallsdatei oder eine Teilprüfung ausgewichen. Das Budget
-lässt sich nach Prüfung mit `df -h /var/backups/app-backup` anpassen.
+Standard: **adaptives Arbeitsbudget** (`RESTORE_TEST_MAX_WORK_GB=0`) mit mindestens
+**2 GiB freier Reserve**. Ein positiver Wert setzt zusätzlich eine feste Grenze.
+Die größte Komponente muss vollständig passen. Die frühere Vorgabe von 4 GiB
+reicht für Geminis rund 8,8 GB Nextcloud-Daten nicht; die Update-Option
+`--enable-restore-test` setzt deshalb ausdrücklich das adaptive Budget.
+Bei Platzdruck versucht der Test zwischen Arbeitsschritten die sichere lokale
+Bereinigung aus [SPEICHER.md](SPEICHER.md). Schlägt sie fehl, wird der Test mit
+Fehlerbericht beendet und sein Scratch bereinigt. Alle Komponenten werden geprüft;
+ein fehlender Platz wird nicht durch eine Stichprobe kaschiert.
 
 Vor Download und Entpacken wird der Bedarf geprüft. Während externer Prozesse
 wird freier Speicher laufend kontrolliert, die tatsächliche Belegung regelmäßig
@@ -53,66 +57,60 @@ Die Bereinigung wird wiederholt; ein solcher Zustand darf nicht als Erfolg gelte
 Bei einem ausgeschalteten Server erfolgt sie naturgemäß erst nach dem Neustart.
 
 Nur der eindeutig zu diesem Test gehörende Container und das markierte
-`$WORKDIR/restore-test/scratch` werden bereinigt. Vorhandene Backups, reguläre
-manuelle Restore-Verzeichnisse und fremde Docker-Ressourcen werden nicht gelöscht.
+`$WORKDIR/restore-test/scratch` werden bereinigt. Reguläre manuelle Restore-Verzeichnisse und fremde Docker-Ressourcen bleiben
+erhalten. Die getrennte Platzbereinigung darf ältere lokale Sicherungskopien nur
+nach erneuter vollständiger Offsite-Prüfung und unter Wahrung der Mindestanzahl entfernen.
 Es gibt kein allgemeines `docker prune`. Das einmal vorbereitete DB-Image bleibt
 als wiederverwendbare Abhängigkeit erhalten; sein einmaliger Platzbedarf kommt
 zum Arbeitsbudget hinzu. Images werden im Test weder heruntergeladen noch gebaut.
 
-## Einmalige Vorbereitung auf Gemini
+## Automatische Vorbereitung auf Gemini
 
-Am 12.09.2026 lesend auf Gemini festgestellt: MariaDB **10.11.18**, Docker-CLI
-vorhanden und rund **9,1 GiB frei auf `/var`**. Für diesen Stand passt die unten
-genannte Serie `mariadb:10.11`. Die freie Kapazität ist eine Momentaufnahme;
-vor Image-Download und Test nochmals prüfen.
-
-Docker Engine und CLI müssen lokal vorhanden sein. Verwendet wird ausschließlich
-`unix:///var/run/docker.sock`. Zur produktiven MariaDB passende Major-/Minor-Version
-ermitteln:
+Docker Engine und CLI müssen lokal vorhanden sein. Gemini verwendet laut
+Bestandsaufnahme vom 12.09.2026 MariaDB 10.11.18 und besitzt Docker bereits.
+Der Installer liest `SELECT VERSION()` mit den vorhandenen Backup-Zugangsdaten.
+Alle zu prüfenden Datenbanken müssen dieselbe MariaDB-Major-/Minor-Serie verwenden.
+Ohne gesetztes Image wählt er beispielsweise `mariadb:10.11`. Ein vorhandenes
+Image wird wiederverwendet, ein fehlendes einmalig mit Zeitlimit geladen. Ein
+explizites Image wird erhalten, muss aber zur Produktionsserie passen.
 
 ```bash
-sudo mariadbd --no-defaults --version
-sudo docker --host unix:///var/run/docker.sock info
+sha256sum -c app-backup-update-VERSION.run.sha256
+sudo bash app-backup-update-VERSION.run --enable-restore-test
 ```
 
-Beispiel **nur wenn die Produktion MariaDB 10.11.x verwendet**:
-
-```bash
-sudo docker --host unix:///var/run/docker.sock pull mariadb:10.11
-```
-
-Bei einer anderen Produktionsversion den Tag entsprechend ersetzen. Platz für
-Image und Testdaten vorab prüfen. Ein vorhandenes kompatibles Image kann
-wiederverwendet werden; für reproduzierbare Tests kann statt des Tags ein Digest
-konfiguriert werden. Bei einem Major-/Minor-Upgrade der Produktions-DB auch das
-Testimage prüfen und aktualisieren.
-
-Vor dem Start des neuen Update-Pakets `/etc/app-backup/app-backup.conf` bearbeiten:
-
-```bash
-ENABLE_RESTORE_TEST="true"
-RESTORE_TEST_DB_IMAGE="mariadb:10.11"  # Beispiel: an Produktionsversion anpassen!
-RESTORE_TEST_MAX_WORK_GB=4
-RESTORE_TEST_MIN_FREE_GB=2
-RESTORE_TEST_MAX_AGE_HOURS=72
-RESTORE_TEST_TIMEOUT=39600           # 11 Stunden, inklusive Remote-Arbeit
-MAIL_HOSTNAME="gemini.jr-it-services.de"
-```
-
-Danach das neue `.run`-Update wie in [UPDATE_ANLEITUNG.md](UPDATE_ANLEITUNG.md)
-installieren. Der Starter prüft das lokale Image und die freie Reserve, bevor er
-installiert. Er lädt kein Image nach. Nach der normalen Update-Abnahme aktiviert
-er den Restore-Test-Timer und den Boot-Bereinigungsdienst, wenn
-`ENABLE_RESTORE_TEST=true` gesetzt ist. Der Timer kann bei einem nachzuholenden
-Termin sofort starten. Das Update-Ergebnis bestätigt weiterhin das Paket und sein
-Abnahmebackup; der neue Restore-Test hat ein eigenes Ergebnis und eine eigene Mail.
-
-Bestehende Konfigurationen ohne die neue Option bleiben kompatibel: Der monatliche
-Test ist zunächst deaktiviert. Eine reine Installation mit `install.sh` installiert
-die Units und erhält bestehende Zeitpläne; für die erstmalige Aktivierung dann:
+Die Option aktiviert den Test und das adaptive Arbeitsbudget in der gesicherten
+Kandidatenkonfiguration. Die freie Docker-Kapazität wird vor einem Download geprüft.
+Der Installer startet bei Bedarf den vorhandenen Docker-Dienst. Er initialisiert
+eine isolierte Test-MariaDB, importiert eine kleine Prüftabelle, führt
+`mariadb-check` aus und entfernt Container und Daten wieder. Erst nach Erfolg
+wird ein automatisch ermitteltes Image in die Konfiguration übernommen. Der
+Probeimport verändert keine produktive Datenbank und setzt keinen erfolgreichen
+monatlichen Sicherungsnachweis.
+
+Anschließend installiert der Update-Worker das Paket, erstellt ein Backup und
+prüft **diesen konkreten Offsite-Satz vollständig inklusive DB-Import**. Erst nach
+erfolgreicher Prüfung und Bereinigung aktiviert er Backup-Timer, Monatstimer und
+Boot-Bereinigung. Das Update-Ergebnis und der separate Restore-Bericht dokumentieren
+die Abnahme. Die zeitaufwendige Worker-Phase läuft unabhängig von SSH; die
+vorgelagerte Vorbereitung sollte bis zur Übergabemeldung verbunden bleiben.
+
+Ohne `--enable-restore-test` erhält das Update den bisherigen Aktivierungszustand
+und ein ausdrücklich eingestelltes Arbeitsbudget. Ist der Test bereits aktiviert,
+erfolgen Image-Vorbereitung und vollständige Abnahme ebenfalls automatisch.
+Bei einem MariaDB-Serienwechsel ein bisher ausdrücklich eingetragenes Image
+anpassen oder leeren; ein inkompatibles Image wird vor Verwendung abgelehnt.
+
+Eine direkte Installation mit `install.sh` bereitet eine bereits aktivierte
+Testkonfiguration ebenfalls vor. Für eine spätere Aktivierung ohne Paketupdate:
 
 ```bash
+sudoedit /etc/app-backup/app-backup.conf
+# ENABLE_RESTORE_TEST=true; RESTORE_TEST_DB_IMAGE=""; RESTORE_TEST_MAX_WORK_GB=0
+sudo bash /usr/local/sbin/app-restore-test.sh --cleanup
+sudo bash /usr/local/lib/app-backup/prepare-restore-test.sh /etc/app-backup/app-backup.conf
 sudo bash /usr/local/sbin/app-restore-test.sh --check
+sudo systemctl start app-restore-test.service
 sudo systemctl enable app-restore-test-cleanup.service
 sudo systemctl enable --now app-restore-test.timer
 ```
@@ -223,16 +221,19 @@ Technische Referenzen: [Docker run](https://docs.docker.com/reference/cli/docker
 
 ## Entwicklung und lokale Verifikation
 
-Der Standardlauf (`tests/run.sh` im bestehenden Testcontainer) prüfte am
-12.09.2026 81 Fälle: 80 erfolgreich, der separate Docker-Test planmäßig
-übersprungen. Zusätzlich bestanden alle 19 gezielten Restore-Tests mit lokalem
-Docker-Daemon und dem offiziellen `mariadb:10.11` (29,0 Sekunden). Vier gezielte
-Sperr-/Installer-Tests bestanden ebenfalls (23,7 Sekunden). Dazu gehören echte
-Crypt-Downloads, vollständiges Entpacken, DB-Import/Tabellenprüfung, ungültiges SQL,
-SIGTERM/SIGKILL, fehlender Platz, beschädigte Statusdateien und ein zeitweise nicht
-erreichbarer Docker-Daemon. Container-Isolation und vollständige Bereinigung
-werden nachgeprüft. Die bereits vorhandene Entwicklungstest-DB mit MariaDB 11.8.6
-wurde ebenfalls erfolgreich verwendet. Es werden keine echten Mails versendet.
+Am 12.09.2026 bestanden **100 unterschiedliche Tests**: 71 Backup-/Restore-/
+Installer-Regressionstests, 23 Restore-Test-Fälle mit dem offiziellen lokalen
+MariaDB-10.11-Image und 6 gezielte Scratch-/Recovery-Schutzprüfungen. ShellCheck
+und Python-Syntaxprüfung bestanden ebenfalls. Das Testverzeichnis war danach
+leer, und es blieben keine zugehörigen Testcontainer zurück.
+
+Die automatischen Tests decken echte Crypt-Downloads, Entpacken, DB-Import und
+Tabellenprüfung ab, außerdem ungültiges SQL, SIGTERM/SIGKILL, Platzmangel,
+beschädigte Statusdateien und einen zeitweise nicht erreichbaren Docker-Daemon.
+Die Installer-Vorbereitung wird zusätzlich mit dem offiziellen lokalen
+`mariadb:10.11` geprüft, einschließlich automatischer Versionswahl und Ablehnung
+einer falschen Produktionsserie. Scratch-, Container- und Konfigurationserhalt
+werden nachgeprüft; Testmails bleiben lokal in der Testumgebung.
 
 Auf einem separaten Entwicklungs-/Testrechner mit den Abhängigkeiten aus
 `tests/Dockerfile`, Docker-CLI und lokal vorbereitetem Image lässt sich die