Backup und Restore

Backup und Restore

← Home · Zurück: Updates-und-Rollback

Backups sind der Airbag dieses Setups: Das nächtliche tar.gz sichert Spielstände und Server-Konfiguration, das interaktive Restore spielt sie zurück — und der Update-Zyklus baut vor jedem Update ein eigenes Pre-Update-Backup als Rollback-Anker.

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

Was gesichert wird

backup.sh packt genau zwei Ordner aus dem Datenverzeichnis (1:1 aus dem Skript):

tar -czf "$DEST" -C "$PZ_DATA_DIR" Saves Server

Inhalt	Gesichert?
Saves/ (Spielstände, Welten, Spieler)	Ja (Repo-Default)
Server/ (gerenderte INIs, Sandbox-Vars, Spawn-Lua)	Ja (Repo-Default)
SteamCMD-Installation (STEAMCMD_DIR)	Nein — per Skriptverhalten: taucht im tar nicht auf (Repo-Verhalten)
Server-Binärdateien / Workshop-Downloads	Nein — werden per SteamCMD neu geladen statt gesichert (Repo-Verhalten, aus install.sh/update.sh ablesbar)
.env, mods.yaml, Repo-Dateien	Nicht Teil des tar — gehören ins Git (Repo-Regel: jede Änderung = Commit)

Konsequenz (aus dem Skriptverhalten abgeleitet): Ein Restore stellt Spielstand und Konfiguration wieder her; Server-Programmdateien und Mods besorgt SteamCMD/der Server neu. Ein frisches make install plus Restore reicht für einen Neuaufbau (Heuristik als Arbeitsablauf, Bausteine sind Repo-Verhalten).

Archivformat: tar.gz, Name ${LABEL}-${YYYYmmdd-HHMMSS}.tar.gz im BACKUP_DIR (Repo-Default).

Backup ausführen

make backup                    # = bash scripts/backup.sh (Label "daily")
bash scripts/backup.sh daily   # dasselbe, explizit
bash scripts/backup.sh weekly  # wöchentliches Archiv mit eigenem Label
bash scripts/backup.sh pre-update   # Pre-Update-Anker (wird von update.sh aufgerufen)

Erfolgsmeldung inklusive Größe erscheint im Log (du -h); bei Fehlschlag gibt es Exit 1 und eine rote Discord-Nachricht (nur mit Webhook).

Automatisch: zomboid-backup.timer startet täglich um 04:00 den oneshot-Service, der backup.sh daily ausführt (Repo-Default, 1:1 aus der Unit; Persistent=true holt verpasste Läufe nach). Siehe systemd-Referenz.

Rotation und Aufbewahrung

Zwei Hebel aus .env (Wirkung 1:1 aus backup.sh):

Variable	.env-Default	Wirkung
BACKUP_DIR	/opt/pzserver/backups	Zielordner aller Archive
RETENTION_DAILY	7	Behält die 7 neuesten daily-*.tar.gz
RETENTION_WEEKLY	4	Löscht daily-Archive älter als 4 × 7 = 28 Tage

Alle Werte: Repo-Default aus .env.example bzw. lib/common.sh-Defaults.

Details, die man kennen sollte (1:1 aus dem Skript):

• Die ls -1t ... | tail -n +N-Rotation greift nur auf daily-*.tar.gz
• Der find -mtime-Lauf löscht ebenfalls nur daily-*.tar.gz — Archive mit anderem Label (weekly-*, pre-update-*, pre-restore-*) bleiben unangetastet liegen
• Die Discord-OK-Meldung „Naechtliches Backup OK" feuert nur bei Label daily

Restore ausführen

Der interaktive Weg (empfohlen)

make restore    # = bash scripts/restore.sh, vollständig interaktiv

Ablauf 1:1 aus restore.sh:

1. Listet alle *.tar.gz im BACKUP_DIR — neueste zuerst, mit Nummern
2. Keine Backups vorhanden → Abbruch mit Fehler (exit 1)
3. Nummer wählen; ungültige Eingabe → Abbruch (exit 1)
4. Sicherheitsabfrage „Aktueller Stand wird ueberschrieben! [j/N]" — Abbruch mit exit 0 ist der Default (alles außer j/J/y/Y)
5. sudo systemctl stop zomboid
6. Snapshot des aktuellen Stands: backup.sh pre-restore — der Stand vor dem Restore ist damit selbst wieder ein Archiv
7. tar -xzf des gewählten Archivs nach ${PZ_DATA_DIR} (überschreibt Saves/ und Server/)
8. sudo systemctl start zomboid
9. 45 s warten (Repo-Default), dann Healthcheck; bei Erfolg Discord-Meldung „Restore erfolgreich"

Der manuelle Weg (Alternative)

Wenn restore.sh nicht passt (z. B. Scripted/Remote), dieselbe Folge von Hand — Schritte entsprechen dem Skript, Reihenfolge 1:1:

touch .planned-stop                      # Watchdog ruhigstellen
bash scripts/backup.sh manual-$(date +%F) # Sicherheitskopie des Stands
sudo systemctl stop zomboid
tar -xzf /opt/pzserver/backups/daily-<TS>.tar.gz -C "$PZ_DATA_DIR"
sudo systemctl start zomboid
sleep 45 && bash scripts/healthcheck.sh
rm .planned-stop                         # Watchdog scharf schalten

Pfadangaben: Repo-Defaults (BACKUP_DIR, PZ_DATA_DIR aus .env).

Verifikation danach (Heuristik — sinnvolle Prüf-Reihenfolge):

1. make status bzw. healthcheck.sh → Exit 0
2. ls -lt ${PZ_DATA_DIR}/Saves bzw. Zeitstempel der Save-Dateien mit dem Backup-Zeitpunkt abgleichen
3. Kurzer Spieler-Test: Anmeldung + Spawn am erwarteten Punkt (Coop-Spawns: Spawn-System)

GCP-Sync (Kurzabriss)

gcp/sync-backups.sh spiegelt den kompletten BACKUP_DIR per gsutil -m rsync -r in den Bucket gs://${GCP_BUCKET} (1:1). Der GCP-Failover-Server zieht beim Notfall-Start das neueste daily-*.tar.gz aus diesem Bucket. Laut gcp/README.md läuft der Sync per Cron auf dem Hauptserver — 04:30 ist ein Vorschlag aus dem gcp/README („z. B. 04:30", direkt nach dem nächtlichen Backup), keine feste Repo-Vorgabe. Details: GCP-Failover.

Empfehlungen

• Retention: Die Defaults (7 tägliche, daily-Archive max. 28 Tage — Repo-Default) passen für einen Coop-Server; großzügiger setzen, wenn Spieler viel Zeit investieren (Heuristik)
• Backup vor jedem manuellen Eingriff: Vor Config-Änderungen, Modwechsel oder Experimenten ein make backup mit sprechendem Label — der Restore hat damit immer einen sauberen Anker (Heuristik; das Repo macht es im Update-Zyklus exakt so, 1:1)
• Offline-Kopie: gsutil-Sync schützt vor Host-Ausfall, nicht vor Löschungen im Bucket — gelegentlich ein Archiv offline sichern (Heuristik)
• Platz im Blick behalten: Archive wachsen mit der Welt; du -h-Ausgabe des Backup-Logs regelmäßig anschauen und RETENTION_* darauf abstimmen (Heuristik)

Weiter: GCP-Failover · Wartung-und-Automatik · Zurück: Updates-und-Rollback