app-backup/UPDATE_ANLEITUNG.md

Automatisches Update-Paket

Auf dem Arbeitsplatz die gelieferte .run-Datei und ihre .sha256-Datei per SCP auf den Server übertragen. Auf dem Server im selben Verzeichnis prüfen/starten:

sha256sum -c app-backup-update-VERSION.run.sha256
sudo bash app-backup-update-VERSION.run

VERSION durch den tatsächlichen Dateinamen ersetzen. Ein Git-Checkout auf dem Server ist nicht erforderlich. Der Installer benötigt die vorhandene Konfiguration /etc/app-backup/app-backup.conf und die bisherigen aktiven Zugangsdaten.

Der Start ist die Freigabe für das Update einschließlich eines vollständigen Backups mit zeitweiliger Unterbrechung der konfigurierten Anwendungen.

Was automatisch passiert

1. Paketinhalt per SHA-256 prüfen und geschützt unter /var/tmp entpacken.
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, 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 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.
7. Einen von SSH unabhängigen systemd-Auftrag app-backup-upgrade.service mit --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.
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.

Verlauf und Ergebnis

sudo journalctl -fu app-backup-upgrade.service --no-pager

Der Starter nennt außerdem den konkreten Ergebnisordner:

sudo cat /var/backups/app-backup-upgrade-XXXXXXXX/result.txt
sudo less /var/backups/app-backup-upgrade-XXXXXXXX/update.log

Erwartet wird SUCCESS. Bei QUEUED oder RUNNING nicht parallel erneut starten. QUEUED bedeutet, dass der Auftrag zur Übergabe vorbereitet wurde und noch kein Worker den Start bestätigt hat. Ein erfolgreicher Starter bestätigt nur die Annahme durch systemd; Installation und Backup können anschließend noch scheitern. Nach Ende verschwindet die kurzlebige systemd-Unit durch --collect auch bei Fehlern. Unit ... could not be found ist daher kein Erfolgsnachweis und verhindert die Journalabfrage nicht. Log und Ergebnis bleiben erhalten. Diagnose ohne Pager:

sudo journalctl -u app-backup-upgrade.service -n 100 --no-pager -l
sudo systemctl status app-backup-upgrade.service --no-pager -l

Bleibt QUEUED stehen, zuerst das Journal prüfen: Ein Fehler noch vor dem Start des Bash-Workers (z. B. ein nicht ausführbarer Paketpfad) kann noch nicht in update.log oder result.txt durch den Worker protokolliert werden. Ein späterer Sperr-Timeout erscheint dagegen in beiden Dateien. Nicht allein auf den Exit-Code von systemd-run vertrauen. --foreground führt den Vorgang stattdessen im aktuellen Terminal aus und ist für Tests/Diagnose gedacht; dabei besteht keine Absicherung gegen SSH-Abbruch.

Gezielte Rückfragen und Grenzen

• Zentrales Mailverzeichnis fehlt, etwa /var/vmail: Der Installer fragt vor der Installation nach dem tatsächlichen absoluten Pfad. Alternativ lässt sich dieser mit --mail-dir /tatsaechliche/mailablage übergeben. Kein leeres Ersatzverzeichnis anlegen: Das würde fehlende Maildaten nur verdecken. Liegen alle Mailboxen in den angezeigten MAIL_HOME_DIRS, im Dialog homes wählen und die vollständige Abdeckung bestätigen. --mail-homes-only erteilt dieselbe ausdrückliche Bestätigung ohne Dialog. Dabei müssen die Home-Sicherung aktiviert und alle konfigurierten Homes vorhanden sein. Excludes und Dateisystemgrenzen gelten weiterhin; ausgeschlossene Verzeichnisse, verlinkte externe Mailablagen und weitere Mounts sind dadurch nicht abgedeckt. Postfix/Dovecot-Konfigurationen und Maildienst-Stopps bleiben aktiv. Bei unbekannter Mailablage abbrechen und zuerst die Mailserver-Konfiguration prüfen. Ein fehlender Pfad wird nie automatisch übersprungen.
• Rclone-Datei nicht eindeutig: Pfad im Dialog oder mit --rclone-config FILE angeben. Eine user-eigene Datei wird in eine neue root-eigene Datei kopiert; die vom Benutzer verwendete Originaldatei bleibt unverändert.
• Gitea bisher nicht konfiguriert: Aufnahme bestätigen oder bewusst --no-gitea setzen. Absolute explizite Pfade und der MySQL-DB-Name können aus app.ini übernommen werden. Mehrdeutige/relative Pfade müssen zuerst in der vorhandenen Backup-Konfiguration ergänzt werden; es werden keine geratenen Repository-Pfade eingetragen.
• Nextcloud in crontab: Der Installer fragt, ob der gefundene Cron-Dienst während jeder Sicherung angehalten werden darf. Das betrifft auch andere Cronjobs; währenddessen fällige Jobs können ausfallen. Alternativ Nextcloud zuvor in einen eigenen systemd-Service/Timer übertragen. Bereits gestartete direkte cron.php-/occ-Prozesse werden nach dem Writer-Stopp abgewartet (Default 300 Sekunden), nicht blind beendet. Shell-Wrapper, externe Scheduler und nicht direkt erkennbare Writer müssen explizit berücksichtigt werden.
• Fehlende Basispakete: Installation über dnf nach Rückfrage oder mit --install-deps. Keine automatische Aktualisierung von PHP, DB-Server oder rclone auf eine möglicherweise inkompatible Version.
• Verschlüsselte rclone-Konfigurationsdatei: Die für rclone benötigte Entsperrung muss auch im systemd-Kontext verfügbar sein. Ohne verfügbare Entsperrung bricht die Prüfung ab, statt unsichtbar auf eine Passworteingabe zu warten. Der Installer legt keine neuen Crypt-Passwörter an und exportiert keine fremden Secret-Stores.
• Früher eingecheckte DB-Passwörter: Passwortrotation bleibt separat, weil weitere Benutzer derselben Accounts nicht zuverlässig ermittelt werden können.

Optionen können kombiniert werden:

sudo bash app-backup-update-VERSION.run \
  --rclone-config /root/.config/rclone/rclone.conf \
  --enable-gitea --cron-services nextcloudcron.timer,nextcloudcron.service

Die Remote-Retention bleibt nach der Migration ausgeschaltet. Nach einem echten Test-Restore bei Bedarf bewusst wieder aktivieren. Bestehende Timer-Zeitpläne bleiben erhalten; beim Aktivieren kann Persistent=true einen Lauf nachholen.

Fehler und Rückweg

Startfehler nach genau 60 Sekunden bei älteren Paketen

Die Pakete 8e6c9a058fa9 und 56fbcdad74f4 enthielten einen Fehler in der systemd-Übergabe: Der Starter hielt die Update-Sperre und wartete synchron auf den Abschluss des Startauftrags einer Type=oneshot-Unit. Dieser Startauftrag endet erst mit dem Worker; der Worker wartete aber selbst auf die Sperre des Starters. Nach 60 Sekunden brach seine Sperranforderung ab, noch vor Installation und Timer-Stopp. In diesem Ablauf ist kein Rollback erforderlich. Der ursprüngliche Worker hatte vor dem Sperrwarten noch kein eigenes Log eingerichtet, daher konnte die Fehlermeldung auf den systemd-Exit-Code beschränkt bleiben.

Das korrigierte Paket verwendet systemd-run --no-block und gibt zuerst die Backup-Sperre, dann die Update-Sperre frei. Eine fehlgeschlagene Übergabe entzieht auch einem möglicherweise schon eingereihten Worker die Freigabe. Die Sperren bleiben als Schutz vor parallelen Backups/Updates erhalten. Erneut das neue Paket starten; weder Sperrdateien löschen noch alte Worker manuell nachstarten.

Das Verhalten von --no-block und --collect ist in der systemd-Dokumentation beschrieben, der Startabschluss von oneshot in systemd.service.

Fehlende Mailablage und erneuter Start

Ein Abbruch Missing source: /var/vmail bei der Vorprüfung, wie beim Paket 8e6c9a058fa9, erfordert kein Rollback. Mit dem korrigierten Paket erneut starten und die Mailablage klären. Die bisherige Konfiguration und der Timer sind erhalten; der abgebrochene Versuch enthält noch kein erfolgreiches neues Backup. Bereits bewusst getroffene Entscheidungen können als Optionen mitgegeben werden:

sudo bash app-backup-update-VERSION.run --enable-gitea --cron-services crond.service

Diese Optionen passen nur, wenn Gitea aufgenommen werden soll und das Pausieren aller Cronjobs über crond.service ausdrücklich akzeptiert wurde.

Für Mailablagen wie /home/johannes/Mail unter den konfigurierten Benutzerhomes zusätzlich --mail-homes-only verwenden, sofern damit alle Postfächer erfasst sind:

sudo bash app-backup-update-VERSION.run \
  --enable-gitea --cron-services crond.service --mail-homes-only

Der Installer zeigt die übernommenen Home-Verzeichnisse an. Mail/ einschließlich cur, new, tmp und Dovecot-Dateien wird mit den normalen Home-Excludes der Vorlage vollständig kopiert, sofern es auf demselben Dateisystem liegt und kein Verweis auf eine externe Ablage ist. Weitere Benutzer müssen in MAIL_HOME_DIRS stehen; das Vorhandensein eines einzelnen Postfachs belegt nicht deren Abdeckung.

Fehler nach Installationsbeginn

Bei einem Fehler nach Beginn der Installation bleibt der Backup-Timer gestoppt. Es erfolgt kein automatisches Zurücksetzen über möglicherweise noch laufende oder teilweise wiederhergestellte Anwendungen. Logs und gegebenenfalls recovery-*.json im Workdir prüfen. Das kombinierte Rollback stellt die vorherigen Paketdateien und die vorherige Backup-Hauptkonfiguration wieder her:

sudo bash /var/backups/app-backup-upgrade-XXXXXXXX/rollback-update.sh

Es verändert keine gesicherten Anwendungsdaten, rotiert keine Zugangsdaten und startet den Timer nicht ungeprüft. Neu erzeugte root-eigene Kopien von rclone-Dateien 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:

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:

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):

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.

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:

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.

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.

SELinux: rsync-Zugriff verweigert (Exit 23)

Der Gemini-Lauf vom 10.09.2026 um 14:58 Uhr scheiterte nach drei erfolgreichen DB-Dumps beim Kopieren von /var/www/html. Das Audit bestätigt rsync im Kontext rsync_t: Lesen von httpd_sys_content_t sowie Attributänderungen und Relabeling im Staging wurden verweigert. Zusätzlich wurden geerbte Sperrdeskriptoren beanstandet. Die gestoppten Dienste wurden laut Journal wieder gestartet und Nextcloud verließ den Wartungsmodus. Es entstand kein vollständiger neuer Sicherungssatz.

Das aktuelle Paket setzt für den Update-Auftrag und den installierten Backup-Dienst SELinuxContext=system_u:system_r:unconfined_service_t:s0 und startet beide über /bin/bash. Diese privilegierten Prozesse und ihre Kindprozesse laufen damit ohne SELinux-Einschränkung. SELinux bleibt systemweit aktiv; andere Dienste behalten ihre bestehende Policy. Der Installer ändert keine globalen rsync-Booleans, keine Quell-Labels und keine Quellberechtigungen. Ein nicht zugelassener Kontext führt zu einem sichtbaren Startfehler.

Auf Gemini ist die Bash-Startkette mit diesem Kontext und erfolgreichem rsync-Auflisten des Webverzeichnisses unter Enforcing geprüft. Der direkte Unit-Start von /usr/bin/rsync scheiterte dagegen mit 203/EXEC und bildet die Startkette des Pakets nicht ab. Manuelle Unit-Anpassungen sind nicht erforderlich: das aktuelle Paket mit denselben Gitea-/Cron-/Mail-Optionen erneut starten.

Vor dem Wartungsmodus prüft das Paket über rsync die Quellverzeichnisse und die Übernahme ihrer Verzeichnisattribute in einen privaten temporären Prüfbereich. Dabei werden keine Dateiinhalte kopiert. Die Probe erfasst nicht jede untergeordnete Datei; der vollständige Kopierlauf und die Remote-Prüfung bleiben erforderlich. rsync erhält keine geerbten Sperrdeskriptoren; die Elternprozesse halten die Sperren weiter. Der SELinux-Kontext des Backup-Prozesses erscheint im Protokoll.

Bei einem erneuten Fehler update.log, die ausgegebene Ergebnisdatei und die passenden AVC-Meldungen prüfen. Maßgeblich für den erfolgreichen Abschluss bleibt SUCCESS in result.txt; erst danach aktiviert der Installer den Backup-Timer. Eine Wiederherstellungsprobe auf einem separaten System steht weiterhin aus.

Erneuter Dienststart während der Sicherung

Am 10.09.2026 starteten auf Gemini um 15:15 Uhr Apache und PHP-FPM während der Nextcloud-Datenkopie erneut. Paket c0a24b63fc1c hatte die SELinux-Zugriffe bereits korrigiert, schützte jedoch nicht vor fremden Startaufträgen. Den betroffenen Lauf nicht als konsistente Sicherung abnehmen, auch falls Upload/Hashprüfung anschließend erfolgreich waren. Der konkrete Auslöser des Startauftrags ist noch offen. Die 90 Sekunden Apache-Stopp sind dagegen durch dessen Journal erklärt: Timeout beim Beenden, anschließend SIGKILL durch systemd. Das neue Paket ändert weder Apache-Timeout noch seine Signalbehandlung pauschal.

Einen noch laufenden alten Update-Auftrag kontrolliert beenden:

sudo systemctl stop app-backup-upgrade.service
sudo journalctl --no-pager -u app-backup-upgrade.service -n 60
sudo systemctl --no-pager is-active httpd php-fpm gitea postfix dovecot crond

Im Protokoll die Wiederaufnahme und das Verlassen des Wartungsmodus prüfen. Bei Fehlern die ausgegebene recovery-*.json beachten. Erst nach abgeschlossenem alten Auftrag das aktuelle Paket mit den bisherigen Gitea-/Cron-/Mail-Optionen starten. Bestehende Sicherungssätze und Arbeitsverzeichnisse nicht pauschal löschen.

Das neue Paket richtet für die Kopierphase vorübergehende systemd-Startbedingungen ein und prüft Writer-Zustände sowie Aktivierungszeitpunkte vor/nach den Kopien. Es entfernt beim Wiederanlauf nur eigene Ergänzungen; bei einem teilweise ausgeführten Restore bleiben sie bis zur manuellen Prüfung bestehen. Einzelheiten zur gezielten Freigabe stehen in Dokumentation.md bei der Wiederanlaufhilfe. Die permanente Dienstkonfiguration und vorhandene Maskierungen bleiben erhalten. Die Meldung Copy window complete; writer guards verified bestätigt das Ende der geprüften Kopierphase. Abgeschlossen ist die Paketabnahme erst bei SUCCESS in der Ergebnisdatei nach vollständiger Remote-Prüfung.

Der Abbruchpfad wurde ebenfalls korrigiert: Bisher erreichte TERM bei KillMode=mixed zunächst nur den Update-Hauptprozess. Eine wartende Bash konnte dadurch den Stop bis zum Ende ihres Backup-/Upload-Kindprozesses verzögern. Die neuen Units verwenden KillMode=control-group; die Protokollprozesse bleiben während der Fehlerbehandlung verfügbar. Nach einem Update-Abbruch das Journal und die Dienstzustände prüfen; insbesondere ein Stop-Timeout ist kein Nachweis für eine erfolgreiche Wiederaufnahme. Die Änderung wirkt für neue Aufträge, nicht nachträglich für einen bereits gestarteten alten Worker.

OneDrive: HTTP 409 resourceModified und stilles Journal

Der Lauf auf Gemini vom 10.09.2026 ab 15:30 Uhr hat die geschützte Kopierphase und Dienstwiederaufnahme erfolgreich abgeschlossen. Um 15:46:11 meldete rclone 1.74.3 bei wordpress.tar.zst HTTP 409 resourceModified; das deutet auf einen Versions-/eTag-Konflikt am OneDrive-Objekt. Der konkrete Auslöser ist anhand dieser Meldung nicht bestimmt. Der lokale Satz bleibt erhalten; eine erfolgreiche Offsite-Abnahme ist damit noch nicht belegt.

HTTP 409 ist in dieser rclone-Version nicht in der allgemeinen Liste unmittelbar wiederholter OneDrive-HTTP-Fehler enthalten. --low-level-retries 20 bedeutet daher nicht, dass genau dieser Fehler sofort 20-mal versucht wird. Die standardmäßig bis zu sechs Versuche über --retries betreffen den übergeordneten Kopierauftrag; andere Dateiübertragungen können vor dessen Wiederholung noch laufen. Bei als fatal oder nicht wiederholbar eingestuften Fehlern kann rclone früher abbrechen. Quelle: rclone 1.74.3 OneDrive-Code, Wiederholungen.

Die bisherigen Aufträge zeigten normale Fortschrittsstatistiken nicht an: rclone meldet sie standardmäßig auf INFO, die normale Logschwelle ist NOTICE. Das aktuelle Paket setzt --stats-log-level NOTICE --stats-one-line mit RCLONE_STATS_INTERVAL="1m" und meldet die Phasen Upload, Rücklesen und Freigabe des Abschlussmarkers. Statistiken gehen nach stderr, damit maschinell gelesene Marker und Dateilisten auf stdout unverändert bleiben. Quelle: rclone-Statistiken.

RCLONE_TIMEOUT="1h" ist die bestehende I/O-Leerlauffrist, keine Gesamtlaufzeit und kein Versprechen einer Meldung pro Minute. RUNNING und der systemd-Zustand activating/start bei der oneshot-Unit belegen keinen Datenfortschritt. Bei einem stillen alten Auftrag Prozesszustand und TCP-Zähler mit ps/ss prüfen; steigende Zähler belegen Netzwerkverkehr, aber noch keinen erfolgreichen Upload. Quelle: I/O-Leerlauffrist.

Eine neue Paketdatei oder geänderte Config ergänzt keine Statistiken im bereits laufenden rclone-Prozess. Keinen zweiten Upload parallel starten und den vorhandenen lokalen Satz nicht löschen. Ein einzelner 409-Fehler begründet keine Abschwächung der Prüfungen durch --ignore-existing/--size-only. Entscheidend bleiben erfolgreiches Rücklesen, Manifest-/Archivprüfung und SUCCESS in der Ergebnisdatei des konkreten Auftrags.

Paket reproduzieren

Aus einem sauberen, eingecheckten Repository:

python3 tools/build-update-package.py

Ausgabe: dist/app-backup-update-COMMIT.run und zugehörige SHA-256-Datei. Das Paket enthält nur explizit freigegebene Programm-/Dokumentationsdateien und Credential-Vorlagen; keine Git-Historie, echten CNF-Dateien oder Backupdaten. Die Prüfsumme schützt vor Übertragungsfehlern, ist keine digitale Signatur. Das ausführbare Paket ausschließlich über euren vertrauenswürdigen Kanal beziehen.

Verifikation der Lieferung

52 Testfälle erfolgreich: vollständiger Durchlauf mit 50 Tests, anschließend die zwei zusätzlichen Abbruchtests für Kopie und Upload. ShellCheck und Shell-Syntaxprüfung abschließend erfolgreich. Für die danach ergänzten Upload-Statistiken bestanden drei gezielt wiederholte Tests: gedrosselter echter Crypt-Upload mit Remote-Restore, fehlgeschlagene Rückleseprüfung ohne Abschlussmarker und TERM während des Uploads. ShellCheck und Shell-Syntax bestanden erneut; kein erneuter vollständiger Durchlauf für diese Protokollergänzung.

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 scheiterte mit dem alten Code und war nach dem Fix erfolgreich. Geprüft sind auch abgewiesene Übergaben, eingereihte Worker trotz fehlgeschlagener Antwort und persistente Fehlerprotokolle bei belegter Update-Sperre. Die tatsächliche SELinux-Durchsetzung wird im Debian-Testcontainer nicht nachgebildet; der erfolgreiche Bash-/rsync-Lesetest auf Gemini wurde separat vom Betreiber durchgeführt. Die vollständige Server-/OneDrive-Prüfung erfolgt beim Paketlauf. Ein fachlicher Restore auf einem separaten Testsystem bleibt erforderlich.

Die neuen Tests bilden fremde Startaufträge während rsync, zwischenzeitliche Neustarts, bestehende Maskierungen und Fehler bei der Sperrfreigabe ab. Die Condition-Auswertung (Sperrverzeichnis vorhanden/entfernt) und Unit-Syntax wurden zusätzlich mit echtem systemd-analyze geprüft. Der tatsächliche systemd-Manager und SELinux auf Gemini bleiben Teil der noch ausstehenden Serverabnahme.