Minecraft-Backup: Wiederherstellung sicher proben
Ob sich ein Minecraft-Backup wiederherstellen lässt, prüfst du in einer isolierten Testumgebung: Sicherung einspielen, Kopien der Abhängigkeiten anbinden und den Spielerzustand kontrollieren. Erst danach ist die gemessene Wiederherstellungszeit aussagekräftig. Ein erfolgreicher Serverstart allein reicht nicht. Welten, Berechtigungen und externe Daten müssen zusammen einen nutzbaren Wiederherstellungspunkt ergeben.
Der Ablauf richtet sich an Community-Verantwortliche vor einem größeren Update, einem Umzug oder einer Freischaltung. Voraussetzung sind ein Java-Server und jemand, der eine getrennte Testumgebung einrichten kann. Die Anleitung beschreibt die betrieblichen Entscheidungen. Die konkreten Wiederherstellungsbefehle hängen von Datenbank, Plugins und Sicherungssystem ab.
Lege fest, wann die Wiederherstellung abgeschlossen ist
Vereinbart zunächst zwei Ziele. Das Recovery Point Objective, kurz RPO, beschreibt, wie viel jüngster Fortschritt verloren gehen darf. Das Recovery Time Objective, kurz RTO, legt fest, wie lange der Dienst ausfallen darf. Diese Anforderungen bestimmt ihr mit der Projektleitung; sie ergeben sich nicht aus der Festplattengröße.
Starte bei der Probe die Zeitmessung, sobald die zuständige Person mit dem Wiederherstellungsablauf beginnt. Zähle das Auffinden der Sicherung, die Beschaffung des Zugangs, Übertragung, Datenbankwiederherstellung, Serverstart und Prüfung mit. Zeiten für Störungserkennung oder Freigaben, die ihr nicht simuliert, müssen im Bericht ausdrücklich als nicht erfasst stehen.
Klärt, wer die Wiederöffnung freigibt und welche Funktionen dafür zwingend nötig sind. Bei einer Bau-Community können Grundstücksschutz und Inventare entscheidend sein, bei einem Event der Teilnehmerzugang und die eigene Punkteverwaltung. Wenn ihr die technische Vorbereitung eines Minecraft-Events beauftragt, gehören diese Prüfungen in den vereinbarten Probenumfang.
Wähle einen zusammengehörigen Datenstand
Gib der Sicherung eine Kennung und dokumentiere Zeitpunkt und Zeitzone. Halte Minecraft-Version, Server-Build, Java-Laufzeit, Plugin- oder Mod-Versionen, Weltverzeichnisse und externe Abhängigkeiten fest. Bewahre die Originalsicherung unverändert auf und verwende eine Arbeitskopie.
Die Update-Dokumentation von Paper nennt Welten, Serverkonfiguration, Plugin-Konfiguration und Plugin-JARs als Sicherungsbestandteile. Zusätzlich brauchst du die tatsächlich verwendeten Plugin-Daten. Eine externe Berechtigungs- oder Wirtschaftsdatenbank ist nicht automatisch gesichert, wenn du den Plugin-Ordner kopierst.
Für eine einfache geplante Sicherung vereinbarst du ein Wartungsfenster, fährst den Spielserver sauber herunter und pausierst weitere Dienste, die zusammengehörige Daten verändern. Sichere anschließend die Datenbank mit einem von ihr unterstützten Verfahren und erfasse die Serverdateien, bevor Schreibzugriffe wieder erlaubt werden. Dokumentiere diesen Zeitraum. Bei einer vorhandenen Sicherung aus dem laufenden Betrieb muss nachvollziehbar sein, wie Konsistenz hergestellt wurde. Ähnliche Dateizeitstempel sind kein Nachweis.
PostgreSQL beschreibt beispielsweise, dass pg_dump einen intern konsistenten Datenbankstand erzeugt. Damit ist dieser Stand noch nicht mit einer zu einem anderen Zeitpunkt gespeicherten Minecraft-Welt synchronisiert. Für eine laufende SQLite-Datenbank gibt es unterstützte Verfahren wie die Online Backup API. Eine beliebige Kopie einer geöffneten Datei ist damit nicht gleichzusetzen. Das sind Beispiele für bestimmte Datenbanken, keine Empfehlung zum Wechsel des Speichersystems.
Isoliere die Kopie vor dem ersten Start
Ein anderer Minecraft-Port verhindert keine Schreibzugriffe auf produktive Datenbanken oder Integrationen. Prüfe deshalb die wiederhergestellte Konfiguration, bevor du Prozesse startest:
- Verwende ein getrenntes Verzeichnis oder einen anderen Rechner, ohne produktive Datenvolumes mit Schreibrechten einzubinden.
- Spiele Datenbanken in getrennte Instanzen oder Namensräume ein. Testzugänge dürfen keine Schreibrechte auf produktive Daten haben.
- Sperre produktive Ziele auf Netzwerkebene. Entferne oder ersetze kopierte Webhooks, Bot-Tokens und zeitgesteuerte Automatisierungen.
- Binde den Testserver nicht in das öffentliche Proxy-Routing ein. Beschränke den Zugang auf benannte Testpersonen und erhalte die für Spielerprüfungen nötige Authentifizierung und Identitätszuordnung.
- Verwende kontrollierte Testziele für Integrationen. Halte fest, welche externen Funktionen deaktiviert bleiben.
Zugangsdaten gehören nicht in den Prüfbericht. Die zuständige Person braucht einen sicheren Zugriffsweg, keine Passwortsammlung im Dokument. Bei individuellen Plugins und Integrationen sollten Umgebungstrennung und Wiederherstellungsanleitung ausdrücklich zur Übergabe gehören.
Stelle zuerst die ursprüngliche Software wieder her
Reproduziere den dokumentierten Softwarestand, bevor du Updates ausprobierst. Wenn du gleichzeitig Rechner, Minecraft-Version und Plugins wechselst, lässt sich ein Fehler schlechter zuordnen.
Behalte die Weltstruktur der konkreten Version bei. Papers Migrationsdokumentation unterscheidet aktuelle Strukturen von denen vor 26.1. Gewohnte Ordnernamen für Nether und Ende gelten daher nicht pauschal. Diese Probe stellt die ursprüngliche Umgebung wieder her; ein Wechsel der Serverimplementierung ist dafür nicht nötig.
Stelle die Testdatenbanken wieder her, kontrolliere die Verbindungsziele und starte dann den isolierten Server. Sichere relevante Startfehler und vergleiche geladene Komponenten mit dem Versionsverzeichnis. Legt ein Plugin unerwartet eine leere Datenbank an, ist die Wiederherstellung fehlgeschlagen, auch wenn der Beitritt funktioniert.
Arbeite mit einer vorher festgelegten Abnahmetabelle:
| Bereich | Zu dokumentierender Nachweis |
|---|---|
| Welten | Bekannte Bauwerke und Koordinaten in jeder benötigten Dimension |
| Spieler | Erwartetes Inventar, Endertruhe und Position ausgewählter Testidentitäten |
| Zugriff | Normale Spieler dürfen keine Teamaktionen ausführen; Teamrollen haben die vorgesehenen Rechte |
| Plugin-Daten | Ausgewählte Grundstücke, Kontostände oder Punktestände entsprechen dem Sicherungsstand |
| Speicherung | Eine kontrollierte Teständerung bleibt nach sauberem Neustart der isolierten Kopie erhalten |
| Isolation | Testaktionen haben keine produktiven Daten verändert oder Nachrichten ausgelöst |
Ermittle Sollwerte aus Aufzeichnungen zum gesicherten Datenstand. Die Live-Welt nach weiteren Spieltagen ist dafür kein geeigneter Vergleich. Kennzeichne jeden Punkt als bestanden, fehlgeschlagen oder nicht getestet und nenne die verantwortliche Person.
Bewerte Zeiten und offene Fehler gemeinsam
Ein erfundenes Planungsbeispiel: Die Projektleitung akzeptiert 30 Minuten Fortschrittsverlust und 60 Minuten Wiederherstellungszeit. Liegt der letzte nutzbare, zusammenhängende Datenstand 90 Minuten vor dem Vorfall, ist das RPO verfehlt, selbst wenn das Einspielen nur 25 Minuten dauert. Benötigen Wiederherstellung und Prüfung 45 beziehungsweise 20 Minuten, wird auch das RTO überschritten. Diese Zahlen erklären die Rechnung; sie sind weder Mineando-Messwerte noch Leistungszusagen.
Gib den Server nicht allein wegen einer kurzen Laufzeit frei. Fehlende Dimensionen, unerwartete Rechte, widersprüchliche Kontostände oder ein unbekannter Sicherungszeitpunkt verhindern die Abnahme, bis sie geklärt sind. Eine zur Isolation abgeschaltete Funktion bleibt ungeprüft. Plane dafür einen kontrollierten Folgetest ein.
Zum Abschluss dokumentierst du Sicherungskennung, Softwarestand, Konsistenzverfahren, Änderungen zur Isolation, gemessene Arbeitsschritte, Prüfergebnisse und offene Probleme. Wiederhole die Probe nach wesentlichen Änderungen an Speicher, Software oder Integrationen sowie in einem zum Projektrisiko passenden Rhythmus. Eine erfolgreiche Probe bestätigt diesen Wiederherstellungsweg, nicht sämtliche künftigen Sicherungen.
Wenn ihr den Ablauf gemeinsam entwickeln und proben möchtet, kann Mineandos verwaltete Minecraft-Infrastruktur Sicherungsstrategien und Wiederherstellungsverfahren im individuell vereinbarten Umfang einschließen. Bringt eure Abhängigkeiten, den vertretbaren Datenverlust und die Freigabekriterien mit. Zuständigkeiten für Wartung und Support werden gesondert vereinbart.
