Check database dump privileges before stopping applications

Dokumentation.md

@@ -138,7 +138,23 @@ Es wird je aktivierter Anwendung ein Dump benötigt, sofern `ENABLE_DB_DUMPS=tru
 
 Für gemischte Storage Engines nutzt das Paket `--lock-all-tables --quick`. **Die globale Lesesperre kann während jedes Dumps Schreibzugriffe auf alle Datenbanken desselben Servers blockieren.** Eine reine `--single-transaction`-Sicherung schützt insbesondere nicht alle nichttransaktionalen Tabellen. Zusätzlich müssen Anwendungsschreiber über das gesamte Ruhefenster angehalten sein, damit Dateikopien zu den Dumps passen. Quelle: [MariaDB mariadb-dump](https://mariadb.com/docs/server/clients-and-utilities/backup-restore-and-import-clients/mariadb-dump).
 
-Die konkreten Rechte hängen von Serverversion, Views, Routinen und Sperrmethode ab. Der Backup-Account benötigt Leserechte sowie Rechte für Views, Trigger, Events, Routinen und die globale Sperre; ein früherer einfacher `SELECT`-Account reicht möglicherweise nicht. Die Rechte gezielt auf eure Version zuschneiden. `--check` prüft Anmeldung und DB-Zugriff, **nicht sämtliche später benötigten Dump-Privilegien**. Die Integrationstests verwenden einen isolierten administrativen Testaccount.
+Die konkreten Rechte hängen von Serverversion, Views, Routinen und Sperrmethode ab.
+Der Backup-Account benötigt Leserechte sowie Rechte für Views, Trigger, Events,
+Routinen und die globale Sperre. Für `--lock-all-tables` ist insbesondere globales
+`RELOAD` erforderlich; Rechte nur auf `wordpress.*` reichen dafür nicht.
+`--check` prüft Anmeldung, DB-Zugriff und dieses globale Recht über lesende
+Privileg-Metadaten. Bei MariaDB wird auch `SELECT * FROM mysql.proc LIMIT 0`
+geprüft: `--routines` benötigt diesen Lesezugriff. Die Abfrage liefert keine
+Routineninhalte. Die Prüfung führt kein `FLUSH` aus und nimmt keine globale DB-Lesesperre.
+Authentifizierungsdaten aus `SHOW GRANTS` werden weder ausgegeben noch gespeichert.
+Direkte Grants und bei MariaDB aktivierte, auch verschachtelte Rollen werden
+berücksichtigt; lediglich zugewiesene, aber nicht aktivierte Rollen reichen nicht.
+Andere Rollenmodelle oder nicht auswertbare Rollennamen benötigen einen direkt
+nachweisbaren Grant für das Backup-Konto. Die Prüfung belegt **nicht sämtliche
+objekt- und versionsabhängigen Dump-Rechte**; der vollständige Probelauf bleibt
+erforderlich. Zusätzlich zum administrativen Testkonto prüfen die Integrationstests
+einen eingeschränkten Backup-Account mit gezielten Grants und MariaDB-Rollen.
+Quelle: [MariaDB FLUSH / RELOAD](https://mariadb.com/docs/server/reference/sql-statements/administrative-sql-statements/flush-commands/flush).
 
 Für einen Restore einen separaten Account mit DDL-/DML-Rechten auf die Ziel-Datenbanken verwenden. Importe sind nicht als Ganzes transaktional. Eine leere vorbereitete Zieldatenbank vermeidet, dass Tabellen oder andere Objekte zurückbleiben, die im Backup nicht vorkommen. Das Skript löscht keine vollständige Datenbank und legt keine Datenbanken/Accounts automatisch an.
 
@@ -315,10 +331,12 @@ Die Entfernung der drei DB-Dateien aus dem aktuellen Baum löscht deren Historie
 
 Reproduzierbar mit `tests/Dockerfile` und `tests/run.sh`. Der Container bekommt das Repository nur lesbar und benötigt während der Tests kein Netzwerk. Die MariaDB läuft ohne TCP-Port in einem temporären Verzeichnis. systemd/occ werden simuliert; alle eigentlichen Archive, Dateikopien, Dumps/Imports und Crypt-Operationen sind real.
 
-Ergebnis des lokalen Abschlusslaufs am 10.09.2026: **37 Tests erfolgreich**, Shell-Syntax und ShellCheck ohne Befund. Testumgebung: Debian 13.6, MariaDB 11.8.6, rclone 1.60.1-DEV (Distributionspaket), ShellCheck 0.10.0. Diese Versionsangaben beschreiben die Testumgebung, keine Empfehlung für die Produktivversion.
+Ergebnis des lokalen Abschlusslaufs am 10.09.2026: **41 Tests erfolgreich**, Shell-Syntax und ShellCheck ohne Befund. Testumgebung: Debian 13.6, MariaDB 11.8.6, rclone 1.60.1-DEV (Distributionspaket), ShellCheck 0.10.0. Diese Versionsangaben beschreiben die Testumgebung, keine Empfehlung für die Produktivversion.
 
 Geprüfte Fälle umfassen:
 
+- Fehlendes globales `RELOAD` bei eingeschränktem Konto: Vorprüfungsabbruch ohne Installation/Writer-Stopp, anschließend erfolgreicher Paketlauf nach gezieltem Grant. Aktive verschachtelte MariaDB-Rollen werden anerkannt, inaktive Rollen abgewiesen.
+- Fehlender Zugriff auf MariaDB-Routinen-Metadaten vor Wartungsmodus erkannt; nach gezielter Berechtigung tatsächlicher Dump mit gespeicherter Prozedur geprüft.
 - Fehlender Mailstore ohne Live-Änderung, explizite Pfadkorrektur, Homes-only-Update samt tatsächlichem Maildatei-Restore und Ablehnung unvollständiger Home-Konfigurationen.
 - Shell-Syntax und ShellCheck der Paketdateien.
 - MyISAM-Dump und tatsächlicher SQL-Import samt Dateiwiederherstellung.