Updates und Rollback

Updates und Rollback

← Home · Zurück: Backup-und-Restore

update.sh ist der sicherste Vorgang dieses Setups: Er kündigt den Neustart im Spiel an, sichert vorher, aktualisiert per SteamCMD, startet neu, prüft die Gesundheit — und rollt bei Fehlschlag automatisch auf das Pre-Update-Backup zurück. Diese Seite erklärt den Zyklus Schritt für Schritt und was der Rollback wirklich tut.

Der Update-Zyklus im Detail

Nummerierte Folge 1:1 aus scripts/update.sh; jedes Zwischenergebnis dahinter:

1. Discord-Ankündigung — „Update-Zyklus gestartet (Server geht gleich offline)". Ergebnis: Admin weiß Bescheid (nur mit Webhook).
2. In-Game-Warnung — announce.sh || true: Countdown-Nachrichten „in 15/5/1 Minuten" via mcrcon/RCON. Ergebnis: Spieler können sich in Sicherheit bringen; Fehler hier brechen nichts ab.
3. Sauberer Stop — sudo systemctl stop zomboid. Ergebnis: Server unten (SIGTERM, siehe systemd-Referenz).
4. Pre-Update-Backup — backup.sh pre-update. Ergebnis: Archiv pre-update-<Zeitstempel>.tar.gz; das neueste davon wird als Rollback-Anker PRE_BACKUP vorgemerkt.
5. SteamCMD-Update — steamcmd.sh +force_install_dir ${PZ_SERVER_DIR} +login anonymous +app_update 380870 validate +quit. Ergebnis: Server-Binärdateien auf aktuellem Stand, Dateien validiert (App-ID 380870 = PZ Dedicated Server, Repo-Default).
6. Neu rendern — render-config.sh + mods-generate.sh. Ergebnis: INIs aus Templates + .env frisch erzeugt, Modliste aus mods.yaml neu gebaut. (Hinweis, 1:1: spawns-generate.sh läuft hier nicht mit — vorhandene generierte Spawn-Dateien werden von render-config aber mitkopiert.)
7. Start — sudo systemctl start zomboid.
8. Healthcheck nach 45 s — sleep 45, dann healthcheck.sh (Prozess, UDP-Port, Log-Scan; 45 s sind Repo-Default). Ergebnis:
   • Erfolg → Discord „Update erfolgreich, Server laeuft", Exit 0.
   • Misserfolg → weiter bei „Rollback verstehen".

Dry-Run: bash scripts/update.sh --dry-run zeigt alle Schritte nur als [DRY]-Zeilen an und endet vor dem Healthcheck mit Exit 0 (Repo-Verhalten, 1:1).

Automatisch: der Update-Timer

zomboid-update.timer (systemd) startet den oneshot-Service, der update.sh ausführt (1:1 aus den Units). Der Zeitplan wird beim Installieren aus .env templated:

Variable	.env-Default	Bedeutung
UPDATE_DAY	Tue	Wochentag (im Timer: OnCalendar=__UPDATE_DAY__)
UPDATE_TIME	03:00	Uhrzeit

Standardfenster also Dienstag 03:00 Uhr (Repo-Default aus .env.example; Persistent=true holt verpasste Läufe nach). Wichtig: Vor 03:00 startet der Countdown-Teil des Zyklus — die In-Game-Warnung beginnt rund 15 Minuten vor dem eigentlichen Stop (Repo-Default: sleeps 600/240/60 in announce.sh). Siehe auch Wartung-und-Automatik.

Manuelles Update

make update                      # sofort, mit Announce + Airbag
bash scripts/update.sh --dry-run # erst trocken durchschauen

Wann manuell starten (Heuristik):

• Hotfix von The Indie Stone ist draußen und man will nicht bis Dienstag warten
• Nach Mod-Änderungen in mods.yaml ist der komplette Render-/Restart-Pfad ohnehin nützlich (der Zyklus rendert die Modliste gleich mit)
• Vor größeren Eingriffen, um den funktionierenden Stand als pre-update-Anker zu fixieren

Mod-Updates: was validate wirklich erfasst

Ehrliche Antwort aus dem Skripttext (1:1): update.sh (wie auch install.sh) führt nur app_update 380870 validate aus — also Update und Validierung der Server-Anwendung. Ein expliziter Aufruf von workshop_download_item für die Mods steht in keinem der beiden Skripte.

Dass die Mods dennoch aktuell vorliegen, hat andere Gründe (Repo-Kontext):

• Die WorkshopItems=/Mods=/Map=-Zeilen aus mods-generate.sh referenzieren die Workshop-IDs; der PZ-Server zieht referenzierte Workshop-Inhalte beim Start selbst (Community-Quelle: PZ-Community-Doku zum Workshop-Laden)
• docs/05-wartung.md fasst den Schritt als „SteamCMD validate (Server + Workshop-Mods)" zusammen — skriptseitig belegt ist nur der Server-Teil

Manueller Nachschub einzelner Workshop-Items geht per SteamCMD (Community-Quelle: SteamCMD-Doku, Befehlsform 1:1 üblich):

steamcmd +force_install_dir <dir> +login anonymous \
  +workshop_download_item 108600 <WorkshopID> +quit

Download landet in <install>/steamapps/workshop/content/108600/<ID>/. Details und Feinheiten: SteamCMD-Referenz.

Rollback verstehen

Trigger: Allein der Healthcheck 45 Sekunden nach dem Start (Schritt 8). Schlägt er fehl (Prozess weg oder kritische Logzeilen), leitet update.sh sofort den Rollback ein.

Ablauf (1:1):

1. Rote Discord-Meldung „FEHLER - Rollback auf ${PRE_BACKUP}"
2. sudo systemctl stop zomboid
3. tar -xzf ${PRE_BACKUP} -C ${PZ_DATA_DIR} — das Pre-Update-Archiv (Inhalt: Saves/ + Server/, siehe Backup-und-Restore) wird zurückgespielt
4. sudo systemctl start zomboid, sleep 45, erneuter Healthcheck
5. Erfolg → „Rollback erfolgreich, alter Stand laeuft"; Misserfolg → „KRITISCH: Rollback-Healthcheck fehlgeschlagen - manuell pruefen!"
6. Exit-Code 1 — der Update-Lauf gilt als gescheitert, selbst wenn der Rollback geglückt ist

Was zurückrollt wird — und was nicht (wichtig, 1:1 aus dem Skript ablesbar): Nur Saves/ und Server/ aus dem Datenverzeichnis. Die Server-Binärdateien bleiben auf dem neuen Stand — SteamCMD läuft im Rollback nicht noch einmal. Passt der alte Spielstand nicht zur neuen Server-Version, kann der zweite Healthcheck ebenfalls fehlschlagen; dann heißt es manuell prüfen.

Was danach zu tun ist:

• Logs ansehen: make logs bzw. journalctl -u zomboid --since "15 min ago"
• Healthcheck einzeln bestätigen: make healthcheck
• Bei „KRITISCH": Serverstatus, Disk-Platz und Save-Integrität manuell prüfen; Notfallpfad über Troubleshooting bzw. Restore aus einem älteren Archiv (Backup-und-Restore)
• Ursache klären, bevor der nächste Timer-Lauf (Dienstag 03:00, Repo-Default) denselben Zyklus wieder fährt — sonst rollt er stumm jede Woche zurück (Heuristik: Discord auf scharf schalten und Alarme ernst nehmen)

B42-Branch: stable und die beta-Falle

• B42 stable ist der Default-Branch in Steam, seit B42.20 ist kein -beta-Opt-in mehr nötig (Community-Quelle: Community-Konsens / Faktenlage zur B42-Stable-Auslieferung). Die SteamCMD-Aufrufe dieses Repos geben entsprechend keinen Beta-Parameter an (Repo-Default).
• Unfallquelle (Heuristik-Warnung): Wer SteamCMD oder Steam manuell mit -beta beta (früherer Unstable-Kanal) oder -beta beta43 aufruft, bekommt eine andere Server-Version als die Stable-Spieler — Folge: Anmeldeprobleme/Mod-Inkompatibilität. Für dieses Setup: Finger weg von Beta-Branches, außer man weiß genau, was man tut.

Stolperfallen

• Update während Spieler online: Der Zyklus kündigt an (15/5/1 Min) und fährt dann trotzdem herunter — ein manuelles make update sollte die Ankündigung respektieren; im schlimmsten Fall hat ein Spieler 15 Minuten Vorwarnung (Repo-Default). Die RCON-Broadcasts gehen nur mit mcrcon + RCON_ENABLED=true (1:1 aus announce.sh).
• Disk voll: SteamCMD-Validate schreibt temporär; ohne Platz schlägt Schritt 5 fehl oder das Pre-Backup in Schritt 4 — vorher df -h prüfen (Heuristik).
• Watchdog-Konflikt während des Zyklus (1:1 aus den Skripten ablesbar): Zwischen systemctl stop und systemctl start ist der Server mehrere Minuten unten (Backup + SteamCMD-Validate + Render) — und update.sh legt kein .planned-stop an. Der minütliche monitor.sh-Cron sieht also „inaktiv + kein Lockfile" und kann den Server mitten im Update wieder hochziehen. Für manuelle Update-/Wartungspausen: vorher touch .planned-stop, danach löschen (Heuristik, Empfehlung aus docs/05-wartung.md); beim Timer-Lauf bleibt nur, die Discord-Alarme zu beobachten.
• validate dauert: Der Validate-Durchlauf vergleicht alle Server-Dateien und kann je nach Disk/Netz Minuten brauchen; der Timer plant dafür das 03:00-Fenster (Repo-Default).
• Restore-Kette denken: Der Rollback-Anker ist das frischeste pre-update-*.tar.gz — notfalls Stunden/Tage alt, wenn der letzte Zyklus lange her ist (1:1: ls -1t | head -n1).

Weiter: SteamCMD-Referenz · Wartung-und-Automatik · Zurück: Backup-und-Restore

Vertieft in Repo: docs/05-wartung.md.