Check database dump privileges before stopping applications

UPDATE_ANLEITUNG.md

@@ -21,7 +21,9 @@ Backups mit zeitweiliger Unterbrechung der konfigurierten Anwendungen.
 2. Bestehende Einstellungen nach `/var/backups/app-backup-upgrade-XXXXXXXX` sichern.
 3. Aktuelle Pfade und Einstellungen übernehmen; sichere Betriebsoptionen ergänzen.
 4. Vorhandene Webdienste und direkt erkennbare Nextcloud-systemd-Writer zuordnen.
-5. Crypt-Konfiguration und DB-Dateien prüfen; vorhandene Schlüssel/Passwörter erhalten.
+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. Bei Fehlern bleibt das installierte
    Paket samt Anwendungskonfiguration und Timer unverändert.
 7. Einen von SSH unabhängigen systemd-Auftrag `app-backup-upgrade.service` mit
@@ -191,6 +193,87 @@ startet den Timer nicht ungeprüft. Neu erzeugte root-eigene Kopien von rclone-D
 sowie strengere Dateirechte bleiben erhalten. Bei unterbrochener Vorbereitung
 ohne Installationsbeginn ist kein Paket-Rollback erforderlich.
 
+### Fehlendes DB-Recht RELOAD
+
+`mariadb-dump: ... FLUSH ... Access denied ... RELOAD ... (1227)` bedeutet:
+Die Anmeldung funktioniert, aber dem tatsächlich verwendeten DB-Konto fehlt das
+globale Sperrrecht für `--lock-all-tables`. Ein pauschaler Wechsel auf einen Dump
+ohne Sperren oder ausschließlich `--single-transaction` ist bei gemischten
+Storage Engines kein gleichwertiger Ersatz. Das neue Paket prüft `RELOAD` bereits
+vor Installation und Wartungsmodus über lesende Privileg-Metadaten.
+
+Die tatsächlich authentifizierten Konten und Serverversionen ermitteln. Zunächst
+eine Root-Shell starten:
+
+```bash
+sudo bash
+```
+
+Erst in dieser Shell den folgenden Block ausführen. Er gibt keine Passwörter
+oder Authentifizierungshashes aus und beendet anschließend die Root-Shell:
+
+```bash
+source /etc/app-backup/app-backup.conf
+query='SELECT CURRENT_USER(), VERSION()'
+echo WordPress
+mariadb --defaults-extra-file="$WP_DB_CNF" -N -B -e "$query"
+echo Nextcloud
+mariadb --defaults-extra-file="$NC_DB_CNF" -N -B -e "$query"
+echo Gitea
+mariadb --defaults-extra-file="$GITEA_DB_CNF" -N -B -e "$query"
+exit
+```
+
+Nur die Zeilen für tatsächlich konfigurierte Anwendungen ausführen. Die getrennte
+Root-Shell vermeidet Probleme durch kopierte Einrückungen an Here-Doc-Abschlussmarken.
+
+Mit einem DB-Administratorkonto nur die betroffenen, vorhandenen Backup-Konten
+berechtigen. Beispiel für das **zuvor tatsächlich identifizierte** Konto
+`backup@localhost` (nicht ungeprüft übernehmen):
+
+```sql
+GRANT RELOAD ON *.* TO 'backup'@'localhost';
+```
+
+`RELOAD` ist ein globales Verwaltungsrecht zum Flush/Reload; deshalb wird es nicht
+automatisch durch den Paketinstaller vergeben. Keine pauschalen `ALL PRIVILEGES`
+oder `GRANT OPTION` erteilen. Wenn die CNF ein produktives Anwendungskonto verwendet,
+ein separates Backup-Konto mit gezielten Rechten vorbereiten. Ein zusätzliches
+`FLUSH PRIVILEGES` ist nach `GRANT` nicht notwendig. Quelle:
+[MariaDB GRANT](https://mariadb.com/docs/server/reference/sql-statements/account-management-sql-statements/grant).
+
+Für MariaDB prüft das Paket außerdem den Lesezugriff auf `mysql.proc`, den die
+verwendete Option `--routines` benötigt. Falls dieser fehlt, gezielt für das
+identifizierte Backup-Konto vergeben:
+
+```sql
+GRANT SELECT ON mysql.proc TO 'backup'@'localhost';
+```
+
+Auch dies ist ein Beispiel mit zu ersetzendem Kontonamen. Es erlaubt den Zugriff
+auf Routinen-Metadaten datenbankübergreifend; kein `SELECT ON mysql.*` vergeben.
+Quelle: [MariaDB mariadb-dump / routines](https://mariadb.com/docs/server/clients-and-utilities/backup-restore-and-import-clients/mariadb-dump).
+
+Weitere erforderliche Rechte hängen von Views, Triggern und Events ab;
+`RELOAD` allein ersetzt keine Leserechte auf den zu sichernden Datenbanken.
+Die neue Prüfung deckt die globale Sperrberechtigung und MariaDB-Routinen-Metadaten
+ab, nicht sämtliche möglichen Objektrechte. Der vollständige Abnahmelauf bleibt verpflichtend.
+
+Beim gemeldeten Lauf vom 10.09.2026 um 14:41 Uhr war das Paket bereits installiert,
+als der erste Dump scheiterte. Nextcloud verließ laut Log den Wartungsmodus und
+Cron wurde wieder gestartet. Das ist **kein erfolgreiches Backup**; der Timer
+bleibt bis zur Abnahme gestoppt. Nach Rechtekorrektur das aktuelle Paket erneut
+starten: Es prüft, sichert und aktiviert den Timer erst nach erfolgreicher
+Remote-Prüfung. Ein erneuter Paketlauf erhält die ursprüngliche Sicherung des
+vorigen Update-Versuchs. Für einen Rückweg zum Stand vor dem ersten Installationslauf
+ist dessen Rollback-Ordner maßgeblich; ein späterer Snapshot enthält bereits die
+zuvor installierte Version.
+
+Dienst-Stopps/-Starts und das Warten auf Nextcloud-Writer werden jetzt ausdrücklich
+im Journal protokolliert. Eine längere Pause ohne CPU-Last lässt sich so einem
+konkreten Dienst zuordnen; ohne dessen Journal lässt sich die Ursache der Pause
+nicht aus ihrer Dauer allein bestimmen.
+
 ## Paket reproduzieren
 
 Aus einem sauberen, eingecheckten Repository:
@@ -207,7 +290,7 @@ Das ausführbare Paket ausschließlich über euren vertrauenswürdigen Kanal bez
 
 ## Verifikation der Lieferung
 
-37 Container-Tests sowie ShellCheck und Shell-Syntaxprüfung erfolgreich.
+41 Container-Tests sowie ShellCheck und Shell-Syntaxprüfung erfolgreich.
 Die Tests enthalten echte MariaDB-Dumps/Imports und lokale rclone-Crypt-Roundtrips;
 systemd/occ und die systemd-run-Übergabe sind simuliert. Das Übergabemodell
 berücksichtigt jetzt das Warten auf den oneshot-Startauftrag: Der Regressionstest