Plane bei einer gemeinsam genutzten Spielwelt drei Dinge getrennt: wie häufig ein neuer Sicherungsstand entstehen soll, welche älteren Generationen du behalten möchtest und wie viel Spielfortschritt die Gruppe im Notfall höchstens verlieren will. Der letzte Punkt ist ein Recovery Point Objective (RPO), also ein Planungsziel. Es verspricht nicht, dass jeder Auftrag pünktlich und erfolgreich abgeschlossen wird.
Intervall, Generationen und RPO sind verschiedene Angaben
Das Backup-Intervall beschreibt, wie oft ein neuer Sicherungsstand geplant ist. Eine Generation ist ein tatsächlich vorhandener Stand mit Zeitstempel. Die Aufbewahrung legt fest, welche dieser Stände für einen späteren Rücksprung erhalten bleiben. Ein geplanter Lauf ist noch keine abgeschlossene Generation: Prüfe deshalb Datum, Status und Umfang der tatsächlich vorhandenen Sicherungen.
Das RPO beschreibt, auf welchen Zeitpunkt vor einem Ausfall die Gruppe ihre Daten zurückführen können muss. Für eine Spielwelt kann die Frage lauten: «Wie viel zuletzt gespeicherter Bau- oder Spielfortschritt wäre im schlimmsten Fall noch akzeptabel zu verlieren?» NIST ordnet die Backup-Häufigkeit an solchen Recovery-Point-Zielen aus; das macht ein RPO zu einer Vorgabe für die Planung, nicht zu einer Zusage über den nächsten Sicherungslauf. NIST SP 800-34 Rev. 1.
Ein Ziel von beispielsweise sechs Stunden beschreibt, wie alt der jüngste brauchbare Rückkehrpunkt höchstens sein soll. Daraus leitest du ein passendes Intervall mit Reserve ab und kontrollierst später die Zeitstempel erfolgreicher Läufe. Ein verspäteter, fehlgeschlagener oder unvollständiger Lauf kann das Ziel verfehlen. Die Zahl selbst garantiert weder einen Sicherungsdienst noch eine Wiederherstellung.
Einen passenden Aufbewahrungsplan aufstellen
1. Festlegen, was zur gemeinsamen Welt gehört
Schreibe auf, welche Daten die Gruppe wiederfinden muss: den Weltstand, passende Konfigurationen und – sofern für die Spielserver-Software nötig – Erweiterungen oder Datenbanken. Die Ablage unterscheidet sich je nach Spiel und Einrichtung; übernimm keine pauschalen Pfade aus einer Anleitung für ein anderes Spiel. Für Minecraft beschreibt die Anleitung zum Erstellen eines Server-Backups typische zusammengehörige Daten. Eine laufende Welt kann sich während des Kopierens ändern; nutze den dokumentierten Speicher- oder Stoppweg des konkreten Spiels.
2. Kurzfristige und ältere Rücksprünge benennen
Lege zuerst fest, wie viele aktuelle Punkte bei häufigen Problemen helfen sollen. Ergänze danach gröbere Tages-, Wochen- oder Monatsgenerationen, wenn ihr auch nach später entdeckten Änderungen zu einem älteren Stand zurückkehren müsst. Bestimme gemeinsam, welche Generation als ältester bekannter guter Stand erhalten bleiben soll, etwa vor einem grossen Versions- oder Weltumbau. Notiere ihre Kennung und ihr Datum, damit du prüfen kannst, ob sie nach einer Regeländerung weiterhin verfügbar ist. Beurteile Regeln anhand ihrer Zeitstempel und des tatsächlich verfügbaren Verlaufs, nicht allein anhand einer Zahl wie «sieben Backups».
Die Werkzeuge setzen solche Regeln unterschiedlich um. Borg dokumentiert --keep-daily 7 als den jüngsten Stand pro Tag für bis zu sieben der jüngsten Tage, an denen Sicherungen vorhanden sind. Fehlt ein Lauf, entsteht dadurch keine Generation für diesen Tag. Borgs prune entfernt Archive, die nicht zu den Retentionsregeln passen; den dadurch frei werdenden Repository-Speicherplatz gibt erst borg compact frei. Kopia führt Snapshot-Intervall und Regeln wie keep-daily oder keep-weekly als getrennte Policy-Einstellungen. Das sind Beispiele für diese Werkzeuge; prüfe immer die Dokumentation und Version deiner eigenen Sicherungslösung. Borg: prune · Borg: compact · Kopia: policy set · Kopia: Einstieg und Policies.
3. Speicherbedarf beobachten und Speicherort klären
Mehr Generationen können mehr Speicher benötigen, aber der genaue Zuwachs hängt von Änderungen, Ausschlüssen, Kompression und der Sicherungstechnik ab. Kopia beschreibt seine Snapshots beispielsweise als inkrementell; daraus lässt sich keine genaue Speicherprognose für eine andere Software ableiten. Vergleiche nach mehreren abgeschlossenen Läufen den realen Speicherverbrauch und die Zahl der verfügbaren Generationen. Für die Messung des Serverdateisystems und des Serverordners hilft die Anleitung zur Gameserver-Speicherbelegung.
Kläre ausserdem, wo die Sicherungen laut der konkreten Panel- und Anbieter-Konfiguration liegen. Pterodactyl dokumentiert sowohl lokale Wings-Speicherung als auch einen konfigurierbaren S3-kompatiblen Speicher. Das beschreibt mögliche Betreiberkonfigurationen und beweist keinen bestimmten Speicherort oder eine externe Kopie für deinen Server. Pterodactyl: zusätzliche Konfiguration, Backups.
4. Regeln erst nach einer Bestandsaufnahme ändern
Lies vor einer Änderung die bestehende Policy und liste die betroffenen Generationen anhand ihrer Kennungen, Daten und Serverzuordnung auf. Eine Aufbewahrungsregel kann ältere Sicherungen automatisch entfernen. Lösche oder bereinige keine Generationen nur wegen einer Speicherwarnung: Kläre zuerst, welche Welt oder Instanz die Sicherung enthält und ob ein älterer Stand noch gebraucht wird. Wenn du ein eigenes Borg-Repository betreibst, weist die Dokumentation ausdrücklich auf das Löschrisiko von prune und auf eine vorherige Vorschau hin. Eine Vorschau ersetzt nicht die Entscheidung, welche Daten die Gruppe behalten muss.
Aufbewahrung ersetzt keinen Restore-Test
Eine passende Anzahl an Generationen zeigt, welche Zeitpunkte verfügbar sind. Sie beweist nicht, dass Dateien vollständig lesbar sind oder die Spielwelt mit der passenden Version startet. Plane daher eine getrennte, regelmässige Testwiederherstellung in einer separaten Umgebung. Der Gameserver-Backup-Test behandelt diesen Ablauf und seine Erfolgskriterien.
Quellen
- NIST SP 800-34 Rev. 1: Contingency Planning Guide – Definition des Recovery Point Objective und Zusammenhang zwischen Backup-Häufigkeit und RPO-Zielen.
- Borg 1.4.5:
borg prune– Generationenregeln, Bedeutung von--keep-daily, Löschen durchpruneund empfohlene Vorschau. - Borg 1.4.5:
borg compact– Repository-Speicherplatz wird erst durch die Kompaktierung tatsächlich freigegeben. - Kopia:
policy set– getrennte Policy-Felder für Snapshot-Intervall und stündliche, tägliche, wöchentliche, monatliche oder jährliche Aufbewahrung. - Kopia: Getting Started – Policy-Ebenen sowie inkrementelle Snapshots und Aufbewahrungsbeispiele.
- Pterodactyl: Additional Configuration – Backups – lokale Wings- und S3-kompatible Backup-Speicher als konfigurierbare Varianten.