Paper aktualisieren: Server freigeben oder wiederherstellen?
Öffne einen Paper-Server nach einem Update erst wieder, wenn die vereinbarten Spielerabläufe funktionieren, die installierten Versionen dem geprüften Stand entsprechen und eine verantwortliche Person verbleibende Einschränkungen akzeptiert. Lege den spätesten Zeitpunkt für die Wiederherstellungsentscheidung vor der Wartung fest. Ein erfolgreicher Login beweist weder korrekte Rechte noch vollständige Plugin-Daten oder funktionierende Community-Angebote.
Dieser Leitfaden hilft Betreibern etablierter Communities, die Freigabe mit ihrem Technikteam oder einem beauftragten Dienstleister zu vereinbaren. Er behandelt geplante Updates von Paper und Plugins. Die Abläufe sind Vorschläge, keine von Mineando durchgeführten Tests und keine Kompatibilitätsbestätigung für bestimmte Plugins.
Grenze die Änderung nachvollziehbar ein
Erstelle einen kurzen Änderungsplan: bisherige Minecraft-Version, Paper-Build, Java-Laufzeit, Plugin-Versionen, Zielversionen, Anlass und Wartungsverantwortlicher. Ergänze Abhängigkeiten und externe Datenspeicher wichtiger Plugins. „Neueste Version“ reicht als Ziel nicht aus: Zwischen Probe und Installation kann ein weiterer Build erscheinen.
Unterscheide einen neuen Paper-Build innerhalb derselben Minecraft-Version von einem Wechsel der Minecraft-Version. Beides braucht Prüfungen; beim Versionswechsel kann die Kompatibilitätsprüfung umfangreicher werden. Müssen mehrere Komponenten wegen einer Abhängigkeit gemeinsam aktualisiert werden, dokumentiere sie als zusammengehörigen Stand. Unabhängige Optimierungen und neue Funktionen gehören in eine andere Änderung.
Prüfe die Laufzeit anhand der Java-Versionstabelle von Paper. Sie nennt derzeit Java 21 für Minecraft 1.20–1.21.11 und Java 25 für 26.1+. Halte fest, welche Laufzeit der Serverdienst tatsächlich verwendet; die Java-Version im Terminal des Administrators kann davon abweichen.
Sammle für jedes unverzichtbare Plugin die Kompatibilitätsangabe des Maintainers und die Versionshinweise des Kandidaten. Fehlende Angaben bleiben „unbekannt“. Ein erreichbarer Download ist kein Nachweis dafür, dass eure Kombination unterstützt wird.
Plane vom Wiederöffnungstermin rückwärts
Reserviere Zeit für Wiederherstellung und Kontrolle, bevor du das Zeitbudget für Fehlersuche verteilst. Dafür eignet sich folgende Planungsregel:
Späteste Wiederherstellungsentscheidung = geplante Öffnung − erprobte Wiederherstellungsdauer − Prüfzeit − Zeitreserve.
Ein rein hypothetisches Beispiel: Die Öffnung ist für 20:00 Uhr vorgesehen. Eine repräsentative Wiederherstellungsprobe dauerte 25 Minuten, die Kontrolle benötigt 15 Minuten und das Team plant 10 Minuten Reserve ein. Dann fällt die Entscheidung spätestens um 19:10 Uhr. Diese Zahlen veranschaulichen die Rechnung; sie sind keine Messwerte oder Verfügbarkeitszusagen von Mineando.
Ist dann noch ein sperrender Fehler offen, beginnt die vereinbarte Wiederherstellung oder die Wartung wird ausdrücklich verlängert. Verbraucht die Reserve nicht stillschweigend für „noch eine Einstellung“. Legt fest, wie die Community die nächste Statusmeldung erhält und wer den Öffnungstermin ändern darf.
Ohne bisherigen Wiederherstellungstest ist die benötigte Dauer unbekannt. Führt eine isolierte Backup-Wiederherstellungsprobe durch, bevor ihr ein enges Wartungsfenster darauf aufbaut. Hier nutzen wir deren Ergebnis für die Freigabeplanung; die eigentliche Wiederherstellungsanleitung bleibt ein eigener Ablauf.
Prüfe den genauen Kandidaten in einer getrennten Kopie
Bereite eine Kopie mit repräsentativen Welten und Plugin-Daten vor. Beschränke den Zugang auf Tester und verhindere Schreibzugriffe auf produktive Datenbanken, Webhooks und andere Live-Integrationen. Dokumentiere alle zur Trennung deaktivierten Funktionen, damit sie nicht versehentlich als geprüft gelten.
Spiele den vorgesehenen Stand samt Konfigurationsänderungen auf diese Kopie. Bewahre Versionsliste und Ergebnisse gemeinsam auf. Änderst du danach ein Plugin, wiederhole die betroffenen Prüfungen einschließlich der Abhängigkeiten. Das Ergebnis von gestern gibt keinen anderen Softwarestand von heute frei.
Die Update-Anleitung von Paper warnt vor dem Austausch aktiver JAR-Dateien und empfiehlt, während Updates die Logs zu beobachten. Dieser Wartungsplan sieht ein kontrolliertes Herunterfahren und Starten mit anwesendem Operator vor. Bewahre die geprüften Installationsdateien getrennt vom gesicherten Wiederherstellungsstand auf.
Nimm nicht gleichzeitig jede denkbare Verbesserung mit. Kläre zunächst, ob der geplante Stand funktioniert. Erfordert ein Fehler eine größere Umgestaltung, gehört diese aus dem laufenden Wartungsfenster heraus und in einen überarbeiteten Plan.
Prüfe Community-Abläufe statt nur den Start
Stimme die Prüfungen mit den Verantwortlichen der jeweiligen Funktionen ab. Wähle wenige Fälle, deren Scheitern die Öffnung tatsächlich verhindern würde:
| Prüfung | Erforderlicher Nachweis vor der Öffnung |
|---|---|
| Normaler Spieler verbindet sich | Erwartete Identität, Inventar und Position bleiben erhalten |
| Rechteprüfung | Spieler darf eine Teamaktion nicht ausführen; Moderator kann seine vereinbarte Aufgabe erledigen |
| Geschütztes Bauwerk | Unberechtigter Spieler kann den ausgewählten Bereich nicht verändern |
| Kritischer Plugin-Ablauf | Ein Grundstück, Punktestand oder eine Anmeldung lässt sich korrekt lesen und ändern |
| Dauerhafte Speicherung | Die kontrollierte Änderung übersteht einen sauberen Neustart |
| Externe Abhängigkeit | Eine kontrollierte Anfrage erreicht das richtige System; ihr Ergebnis wird abgeglichen |
Verwende bekannte Sollwerte aus der Testkopie. „Sieht gut aus“ ersetzt keinen Vergleich. Notiere Kontorolle, Schritte, Soll- und Ist-Ergebnis sowie Belege. Ein Fall bleibt „nicht ausgeführt“, bis ihn jemand tatsächlich prüft.
Die Paper-Dokumentation zur Plugin-Fehlersuche nennt logs/latest.log als Ausgangspunkt bei Ladefehlern und erläutert fehlende Abhängigkeiten. Ein als aktiviert angezeigtes Plugin hat zunächst nur die Ladeprüfung bestanden. Die Abläufe eures Abnahmeprotokolls sind damit noch nicht bestätigt.
Vergleiche eine repräsentative Spielsitzung unter ähnlichen Bedingungen mit vorhandenen Leistungsmessungen. Vereinbart sperrende Grenzwerte vorher. Dieser Ablauf liefert keine allgemeine Spielerzahl, keine gemessenen Tick-Zeiten und keine Garantie für bessere Leistung durch ein Update.
Halte einen zusammengehörigen Rückweg bereit
Beschränke vor der Produktionsänderung neue Aktivitäten, fahre den Server sauber herunter und koordiniere andere Prozesse, die gemeinsame Daten verändern. Sichere den Wiederherstellungsstand mit den unterstützten Verfahren der tatsächlich eingesetzten Speichersysteme. Kennzeichne zusammengehörige Dateien, Datenbanken, Versionen und Sicherungszeitpunkt.
Frage bei wichtigen Plugins nach, wie die neue Version gespeicherte Daten verändert und ob eine Rückkehr zur vorherigen Version unterstützt wird. Das alte JAR einzusetzen macht eine Datenbank- oder Konfigurationsmigration nicht zwangsläufig rückgängig. Plane mit dem gesicherten Stand vor der Änderung, sofern kein anderer Rückweg dokumentiert und erprobt wurde.
Halte den öffentlichen Zugang während der Abnahme in Produktion geschlossen. Nach der Öffnung können Spieler neuen Fortschritt erzeugen, der bei einer späteren Wiederherstellung des alten Stands verloren geht. Dann müssen Datenverlust und bereits ausgeführte externe Aktionen neu bewertet werden.
Dokumentiere die Freigabeentscheidung
Verwende drei Ergebnisse: öffnen, für eine klar begrenzte Korrektur geschlossen bleiben oder den vereinbarten Stand wiederherstellen. Fehlende wesentliche Daten, unerwartete Rechte und ausgefallene Kernfunktionen verhindern die Freigabe. Einen optionalen Darstellungsfehler könnt ihr mit Verantwortlichem, dokumentierter Auswirkung und Nachverfolgungstermin akzeptieren.
Lege nach der Öffnung eine Beobachtungsphase fest und benenne einen Operator für die vereinbarten Probleme. Dokumentiere den Verlauf einschließlich fehlgeschlagener Prüfungen und endgültiger Versionsliste. Geplante Überwachung und Live-Betreuung brauchen einen vereinbarten Umfang; eine erfolgreiche Probe bedeutet keine unbegrenzte Verfügbarkeit.
Für betreute Minecraft-Infrastruktur sind Änderungsplan, kritische Abläufe und akzeptables Wartungsfenster eine gute Gesprächsgrundlage. Mineando bietet kostenpflichtige, individuell kalkulierte Projekte an. Betrifft der Fehler ein eigenes Plugin, gehören Update- und Wiederherstellungsanforderungen in den Entwicklungsauftrag. Laufende Wartung und Support werden gesondert vereinbart.
