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

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

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.

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

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

8.8 KiB Raw Blame History