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

Paketinhalt per SHA-256 prüfen und geschützt unter /var/tmp entpacken.
Bestehende Einstellungen nach /var/backups/app-backup-upgrade-XXXXXXXX sichern.
Aktuelle Pfade und Einstellungen übernehmen; sichere Betriebsoptionen ergänzen.
Vorhandene Webdienste und direkt erkennbare Nextcloud-systemd-Writer zuordnen.
Crypt-Konfiguration und DB-Dateien prüfen; vorhandene Schlüssel/Passwörter erhalten.
Vorprüfung mit geschützten Kopien durchführen. Bei Fehlern bleibt das installierte Paket samt Anwendungskonfiguration und Timer unverändert.
Einen von SSH unabhängigen systemd-Auftrag app-backup-upgrade.service starten.
Backup-Timer stoppen, Paket mit Rollback-Inventar installieren, Konfiguration atomar übernehmen und Rechte der aktiven root-eigenen Zugangsdaten korrigieren.
Vollständiges Backup ohne lokale/Remote-Retention durchführen. Anschließend den abgeschlossenen Satz nochmals über Crypt herunterladen und mit dem Restore prüfen.
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

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

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:

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:

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.

6.5 KiB Raw Blame History