# 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: ```bash 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 und DB-Dateien prüfen; vorhandene Schlüssel/Passwörter erhalten. 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` starten. 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 ```bash sudo journalctl -fu app-backup-upgrade.service ``` Der Starter nennt außerdem den **konkreten** Ergebnisordner: ```bash sudo cat /var/backups/app-backup-upgrade-XXXXXXXX/result.txt sudo less /var/backups/app-backup-upgrade-XXXXXXXX/update.log ``` Erwartet wird `SUCCESS`. Solange `RUNNING` steht, nicht parallel erneut starten. Nach Ende verschwindet die kurzlebige systemd-Unit; Log und Ergebnis bleiben erhalten. Bei `QUEUED` wurde der Auftrag übergeben und wartet auf den Start. `--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 - **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: ```bash 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 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: ```bash 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. ## Paket reproduzieren Aus einem sauberen, eingecheckten Repository: ```bash 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 30 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. Die tatsächliche Server-/OneDrive-Prüfung erfolgt beim ersten Paketlauf. Ein fachlicher Restore auf einem separaten Testsystem bleibt erforderlich.