Jak aktualizować Paper bez resetowania świata, graczy i konfiguracji

Serwer działa stabilnie, mapa jest rozwinięta, gracze mają ekwipunki, działki i osiągnięcia, a katalog plugins zawiera konfigurację budowaną przez wiele miesięcy. Pojawia się jednak nowa wersja Paper i naturalne pytanie brzmi: czy można podmienić silnik bez resetowania świata, graczy oraz ustawień? Co do zasady tak. Aktualizacja Paper nie polega na tworzeniu nowego serwera od zera, lecz na zastąpieniu pliku silnika przy pozostawieniu danych zapisanych na dysku.

Bezpieczna aktualizacja wymaga jednak rozróżnienia dwóch operacji. Czym innym jest wymiana wydania Paper w ramach tej samej wersji Minecraft Java, a czym innym przejście całego serwera na nowszą wersję gry. W pierwszym przypadku ryzyko jest zwykle ograniczone. W drugim dochodzą migracja świata, kompatybilność pluginów, wymagania dotyczące Javy oraz możliwe zmiany w konfiguracji. Najwięcej problemów powoduje nie sam Paper, lecz niezgodny zestaw: nowy silnik, stara Java, nieprzygotowane pluginy i przypadkowo usunięte pliki.

Przed rozpoczęciem aktualizacji trzeba odpowiedzieć sobie na kilka praktycznych pytań: czy zmieniam tylko plik Paper, czy również wersję Minecraft, czy mam działającą kopię zapasową, czy znam lokalizację wszystkich światów, czy pluginy obsługują nową wersję i czy potrafię wrócić do poprzedniego uruchomienia? Dopiero komplet odpowiedzi pozwala wybrać właściwy wariant migracji serwera Paper. ^[1]

Co dokładnie zostaje zachowane podczas aktualizacji Paper

Silnik serwera a dane zapisane na dysku

Paper jest silnikiem serwera, czyli programem uruchamiającym świat Minecraft Java i pośredniczącym między grą, pluginami oraz plikami konfiguracyjnymi. Najczęściej występuje jako plik .jar, na przykład wskazany w skrypcie startowym poleceniem java -jar paper.jar. Sam plik silnika nie zawiera całej mapy, ekwipunków graczy ani ustawień pluginów. Te elementy znajdują się w osobnych katalogach i plikach roboczego katalogu serwera.

Jeżeli serwer zostanie prawidłowo zatrzymany, wykonana zostanie kopia zapasowa, a następnie podmieniony zostanie wyłącznie plik Paper, świat oraz dane zapisane na dysku pozostają na swoim miejscu. Zwykle nie ma wtedy żadnego mechanizmu, który miałby „wyzerować” mapę. Problem zaczyna się dopiero wtedy, gdy administrator usuwa cały katalog, uruchamia nową instalację w innym miejscu, zmienia nazwy światów albo nadpisuje dane kopią pozbawioną właściwych plików.

Podmiana silnika nie jest więc tym samym co reinstalacja serwera. W pierwszym przypadku wymienia się jeden składnik instalacji. W drugim często tworzy się nowy katalog, generuje nowe pliki i przypadkowo pomija dotychczasowy świat oraz konfigurację. To rozróżnienie ma zasadnicze znaczenie dla pytania, jak aktualizować Paper bez resetowania świata.

Foldery świata, dane graczy i pliki dostępu

Ochroną trzeba objąć wszystkie foldery światów, a nie tylko katalog głównego świata. W typowej instalacji można spotkać osobny folder świata głównego oraz katalogi odpowiadające Netherowi i Endowi. Ich nazwy zależą od konfiguracji, sposobu utworzenia serwera oraz użytych pluginów. Nie należy zakładać, że zawsze będą nazywały się dokładnie tak samo.

W obrębie świata znajdują się między innymi chunki, dane struktur, informacje o wymiarach i pliki związane z generowaniem terenu. Dane konkretnych graczy są przechowywane przede wszystkim w podkatalogach takich jak playerdata, stats i advancements. To tam mogą znajdować się ekwipunek, poziom doświadczenia, lokalizacja, statystyki oraz osiągnięcia. Usunięcie samego świata nie zawsze oznacza usunięcie wszystkich informacji o graczach, ale przywracanie pojedynczych elementów z przypadkowej kopii bywa ryzykowne. Z tego powodu backup powinien obejmować cały katalog serwera albo spójny zestaw wszystkich jego danych.

Oprócz mapy i danych graczy należy zachować pliki określające dostęp do serwera. W zależności od instalacji są to między innymi:

• server.properties z podstawowymi ustawieniami serwera;
• pliki whitelisty, operatorów oraz banów;
• ustawienia Bukkit, Spigot i Paper;
• katalog plugins wraz z plikami .jar i konfiguracjami;
• pliki autoryzacji, połączeń z bazami oraz ustawień narzędzi administracyjnych;
• skrypty uruchomieniowe, pliki zmiennych środowiskowych i ustawienia panelu hostingowego.

Pluginy, bazy danych i konfiguracja serwera

Folder plugins to nie tylko zbiór plików wykonywalnych. W jego podkatalogach pluginy przechowują konfiguracje YAML, lokalne bazy SQLite, dane ekonomii, informacje o regionach, działkach, teleportach, karach oraz ustawieniach użytkowników. Skopiowanie samych plików .jar nie wystarczy, jeśli celem jest zachowanie dotychczasowego stanu serwera.

Niektóre pluginy korzystają z zewnętrznego MySQL lub MariaDB. Wtedy dane nie są przechowywane wyłącznie w katalogu serwera. Backup plików musi zostać uzupełniony eksportem właściwej bazy albo inną metodą uzgodnioną z administratorem systemu bazodanowego. Samo skopiowanie konfiguracji połączenia nie odtworzy ekonomii, rang czy danych działek, jeżeli faktyczne rekordy pozostaną w bazie.

Osobnej uwagi wymagają pluginy, które zmieniają strukturę świata albo przechowują własne pliki poza plugins. Przykładowo narzędzie do mapy internetowej, system kopii zapasowych lub integracja z proxy może zapisywać dane w oddzielnym katalogu. Przed migracją trzeba sprawdzić dokumentację używanych dodatków i ustalić, gdzie zapisują stan.

Co może zmienić się mimo zachowania plików

Zachowanie plików nie gwarantuje, że serwer będzie działał identycznie po aktualizacji. Nowszy Paper może wprowadzić nowe ustawienia, zmienić format konfiguracji albo przenieść część opcji do innych plików. Przy pierwszym uruchomieniu może pojawić się komunikat o migracji konfiguracji. Takie działanie nie musi oznaczać utraty danych, ale nie powinno być ignorowane.

Jeszcze większe znaczenie ma zmiana wersji Minecraft. Świat może zostać przy pierwszym starcie zaktualizowany do nowego formatu. Po takiej operacji powrót do starszej wersji nie zawsze jest bezpieczny. Z tego względu aktualizacja świata powinna odbywać się dopiero po wykonaniu kopii i po potwierdzeniu, że wymagane pluginy oraz Java są zgodne z docelowym wydaniem.

Największe ryzyko nie polega zwykle na tym, że Paper samoczynnie „wyczyści” świat. Polega na uruchomieniu niepasującego zestawu elementów. Stary plugin może nie załadować się, odrzucić nieznane opcje, utworzyć konfigurację domyślną albo działać częściowo. Dlatego nie należy łączyć aktualizacji silnika z przypadkowym porządkowaniem instalacji, usuwaniem pluginów i zmianą nazw katalogów.

Trzy warianty aktualizacji Paper i sytuacje, w których mają sens

Wariant A — podmiana Paper w obrębie tej samej wersji Minecraft

Najmniej inwazyjny scenariusz polega na zaktualizowaniu pliku Paper w ramach tej samej linii wersji gry. Świat pozostaje przeznaczony dla tej samej wersji Minecraft Java, a zmiana dotyczy przede wszystkim silnika. Przed wymianą serwer trzeba zatrzymać, wykonać backup i upewnić się, że skrypt startowy wskazuje właściwy plik.

Ten wariant ma sens, gdy nowa kompilacja poprawia błędy, zwiększa stabilność, usuwa znany problem albo poprawia zgodność z używanymi pluginami. Jest również rozsądniejszy, gdy serwer działa na produkcji i administrator nie potrzebuje natychmiast funkcji dostępnych wyłącznie w nowej wersji gry.

Główne zalety to krótki proces, niewielki zakres zmian oraz prosty rollback. W razie problemu można zatrzymać serwer i wrócić do poprzedniego pliku Paper, o ile nie wykonano po drodze nieodwracalnej migracji świata ani zmian w danych. Wadą jest brak nowych mechanik Minecraft, a także możliwość pojawienia się zmian zachowania silnika mimo pozostania przy tej samej wersji gry.

Wariant B — przejście Paper na nowszą wersję Minecraft

W tym scenariuszu zmieniany jest nie tylko plik silnika, ale również wersja gry, którą obsługuje Paper. Taka migracja może być potrzebna ze względu na nowe bloki, mechaniki, poprawki bezpieczeństwa lub wymagania aktualnych pluginów. Zakres przygotowań jest jednak wyraźnie większy.

Świat co do zasady może zostać zachowany. Przy pierwszym uruchomieniu nowy Paper może jednak zaktualizować dane świata do formatu docelowej wersji. Dotyczy to nie tylko terenu, ale także zachowania niektórych obiektów, danych chunków i mechanizmów generowania. Po takim uruchomieniu powrót do starszej wersji bez przywrócenia pełnego backupu może zakończyć się błędami lub utratą zmian.

Jeśli chcesz pogłębić ten wątek, sprawdź też: Maksymalna wydajność serwera Minecraft na Paper krok po kroku.

Plusem jest dostęp do nowej funkcjonalności i możliwość korzystania z aktualnie wspieranych wersji pluginów. Minusy to większe ryzyko niezgodności, konieczność sprawdzenia Javy, możliwość zmian w konfiguracji oraz potrzeba dokładnego testowania. Ten wariant powinien być traktowany jako migracja serwera, a nie zwykła podmiana pliku.

Wariant C — aktualizacja na kopii serwera lub osobnej instalacji

Najbezpieczniejsze podejście dla ważnego serwera polega na przygotowaniu kopii całej instalacji i przeprowadzeniu aktualizacji poza produkcją. Oryginalny serwer pozostaje wyłączony albo działa bez zmian, natomiast kopia otrzymuje nowy Paper, nową Javę i ewentualnie zaktualizowane pluginy.

Kopia powinna zawierać nie tylko świat. Potrzebne są także dane graczy, konfiguracje, pliki pluginów, lokalne bazy, skrypt uruchomieniowy i — jeśli występuje — osobny eksport zewnętrznej bazy danych. Jeżeli testowa instancja korzysta z tej samej bazy produkcyjnej, test może zmienić dane prawdziwych graczy. Bezpieczniej użyć kopii bazy lub tymczasowego połączenia, a systemy wysyłające wiadomości, płatności czy webhooki wyłączyć.

Testowa instancja pozwala sprawdzić ładowanie świata, teleportowanie, ekwipunki, działki, ekonomię, komendy administracyjne i zachowanie pluginów bez presji wynikającej z trwającej rozgrywki. Jest szczególnie cenna przy zmianie wersji Minecraft, dużej liczbie pluginów albo świecie, którego nie da się łatwo odtworzyć.

Porównanie wariantów przed wyborem

Jak przygotować backup serwera Minecraft przed zmianą

Dlaczego zatrzymanie serwera jest konieczne

Kopia wykonywana podczas aktywnej pracy serwera może być niespójna. Minecraft zapisuje chunki, dane graczy i pliki regionów w różnym czasie. Jeżeli archiwizowanie rozpocznie się w momencie zapisu, część plików może pochodzić sprzed operacji, a część już po niej. Nie każdy taki backup będzie bezużyteczny, ale nie powinien być jedyną kopią przed migracją.

Przed zatrzymaniem należy poinformować graczy o przerwie i doprowadzić serwer do kontrolowanego stanu. Można zapisać zmiany komendą administracyjną, a następnie użyć polecenia zatrzymania serwera. Nie należy zabijać procesu przez zamknięcie panelu, wymuszenie restartu systemu ani zakończenie procesu bez możliwości wykonania procedury zamykania.

Po wydaniu polecenia stop trzeba poczekać, aż proces faktycznie się zakończy. Sam brak odpowiedzi w konsoli nie zawsze oznacza, że wszystkie pliki zostały już zapisane. Dopiero po powrocie do powłoki lub po jednoznacznym komunikacie panelu można rozpocząć kopiowanie.

Co powinien zawierać kompletny backup

Najprostsza zasada brzmi: przed aktualizacją skopiuj cały katalog serwera, a nie wybrane pliki według pamięci. Takie podejście zajmuje więcej miejsca, ale ogranicza ryzyko pominięcia niestandardowego folderu. Jeżeli pełna kopia nie jest możliwa, trzeba sporządzić listę elementów i odhaczać je przed rozpoczęciem prac.

• wszystkie foldery świata, w tym wymiary dodatkowe, jeżeli są używane;
• pliki playerdata, stats i advancements;
• server.properties, whitelistę, listę operatorów i bany;
• pliki konfiguracyjne Bukkit, Spigot i Paper;
• cały katalog plugins, włącznie z konfiguracją i lokalnymi bazami;
• skrypty startowe, pliki zmiennych, ustawienia proxy i panelu;
• eksport zewnętrznych baz danych oraz informacje o ich wersji;
• niestandardowe katalogi używane przez mapy, narzędzia i systemy kopii.

Kopia powinna trafić poza katalog, który będzie modyfikowany. Jeżeli archiwum znajduje się na tym samym dysku, awaria dysku lub pomyłkowe usunięcie może pozbawić administratora zarówno serwera, jak i backupu. Przy ważnej instalacji rozsądne jest zachowanie przynajmniej jednej kopii w innej lokalizacji.

Jak sprawdzić, czy kopia jest gotowa do użycia

Po utworzeniu archiwum nie należy od razu uznawać zadania za zakończone. Trzeba sprawdzić, czy plik kopii można odczytać oraz czy zawiera właściwy katalog serwera, a nie tylko pusty folder albo niepełny fragment instalacji. Warto porównać jego zawartość z przygotowaną wcześniej listą elementów.

Szczególną uwagę należy zwrócić na foldery światów, katalog plugins, konfiguracje oraz pliki zawierające dane graczy. Jeżeli serwer korzysta z zewnętrznej bazy, sam katalog instalacji nie zastępuje jej eksportu. Kopia plików i kopia bazy powinny być opisane tak, aby później było wiadomo, z jakiego momentu pochodzą i z którą wersją serwera są związane.

Archiwum najlepiej przechowywać poza miejscem, które będzie zmieniane podczas aktualizacji. Należy również upewnić się, że można je skopiować do innej lokalizacji i odczytać bez błędów. Jeżeli backup jest uszkodzony albo nie zawiera któregoś z wymaganych elementów, trzeba przygotować go ponownie przed rozpoczęciem podmiany Paper.

Dopiero po takim sprawdzeniu można przejść do aktualizacji wybranego wariantu. Przy zmianie w tej samej wersji Minecraft zakres prac będzie mniejszy, natomiast migracja na nowszą wersję gry wymaga dodatkowo potwierdzenia zgodności Javy, pluginów i konfiguracji. W przypadku istotnego serwera bezpieczniej wykonać pierwsze uruchomienie na kopii, zamiast od razu modyfikować działającą instalację.

Jeżeli backup przeszedł weryfikację, a celem jest jedynie poprawa działania serwera, najrozsądniej rozpocząć od podmiany Paper w tej samej wersji Minecraft. Ogranicza to zakres zmian i ułatwia powrót do poprzedniego stanu. Przejście na nowszą wersję gry warto zaplanować osobno, zwłaszcza gdy aktualizacja świata lub pluginów może wpłynąć na rozgrywkę.

W przypadku serwera publicznego, rozbudowanej instalacji albo wielu zależności najlepszym wyborem pozostaje aktualizacja na kopii. Pozwala ona potwierdzić, że przygotowana kopia rzeczywiście uruchamia świat, dane graczy i konfigurację w oczekiwany sposób, zanim zmiana zostanie wykonana na produkcji. Dzięki temu decyzja o przełączeniu serwera wynika z przeprowadzonego testu, a nie wyłącznie z założenia, że zachowane pliki będą działać identycznie po aktualizacji.

Przebieg aktualizacji Paper krok po kroku

Po wyborze wariantu i przygotowaniu kopii trzeba oddzielić pliki, które są wymieniane, od tych, które mają pozostać bez zmian. W typowej aktualizacji Paper podmianie podlega plik silnika wskazany w skrypcie startowym. Foldery świata, plugins, konfiguracje i dane graczy powinny pozostać na swoim miejscu. ^[2]

Przed rozpoczęciem dobrze jest zapisać aktualny stan instalacji: wersję Paper, wersję Javy, listę pluginów oraz nazwę pliku uruchamianego przez skrypt. Przydaje się również odnotowanie argumentów startowych. Dzięki temu po aktualizacji łatwiej ustalić, czy problem wynika z nowego silnika, zmiany środowiska uruchomieniowego, pluginu albo przypadkowej modyfikacji konfiguracji.

Jeżeli pobierany jest nowy plik Paper, powinien pochodzić z oficjalnego źródła projektu. Trzeba sprawdzić, czy odpowiada wybranej wersji Minecraft oraz architekturze środowiska, na którym działa serwer. Sama nazwa pliku nie zawsze wystarcza do oceny zgodności, dlatego przy zmianie wersji gry trzeba zweryfikować także wymagania dotyczące Javy i pluginów.

Podmiana pliku silnika bez zmiany świata

W najprostszym wariancie procedura wygląda następująco:

1. zatrzymaj serwer i poczekaj na pełne zakończenie procesu;
2. wykonaj i sprawdź kopię całego katalogu instalacji;
3. zachowaj dotychczasowy plik Paper pod inną nazwą albo przenieś go do katalogu kopii;
4. umieść nowy plik w katalogu serwera;
5. zaktualizuj skrypt startowy, jeżeli odwołuje się do konkretnej nazwy pliku;
6. uruchom serwer i obserwuj konsolę od początku do zakończenia ładowania.

Nie trzeba usuwać folderów świata ani tworzyć ich ponownie. Jeżeli plik uruchomieniowy wskazuje właściwy katalog roboczy, Paper odczyta istniejące dane z tej samej instalacji. Reset świata następuje zwykle nie dlatego, że sam Paper kasuje dane, lecz na skutek uruchomienia serwera w innym katalogu, błędnej ścieżki w skrypcie albo utworzenia nowej instalacji bez przeniesienia dotychczasowych plików.

Dobrym uzupełnieniem tego tematu jest także poradnik: Najważniejsze różnice w generowaniu świata między silnikami Spigot Paper i Purpur.

Przy podmianie w obrębie tej samej wersji Minecraft można zwykle zachować poprzednie konfiguracje. Nie oznacza to jednak, że każda wersja Paper będzie interpretować je identycznie. Zmienione ustawienie może zostać pominięte, zastąpione wartością domyślną albo zapisane w innej postaci. Po uruchomieniu trzeba więc zwrócić uwagę na komunikaty dotyczące konfiguracji, a nie tylko na sam fakt poprawnego startu.

Co sprawdzić po pierwszym uruchomieniu

Pomarańczowy lub zielony status w panelu nie jest jeszcze dowodem, że aktualizacja przebiegła prawidłowo. Serwer może uruchomić się bez błędu, a mimo to mieć niedziałający plugin, nieprawidłowe uprawnienia albo problem widoczny dopiero po wejściu gracza do określonego świata.

W pierwszej kolejności trzeba sprawdzić, czy konsola nie zgłasza błędów ładowania pluginów, problemów z Javą, brakujących bibliotek i niezgodnych wersji. Ostrzeżenie nie zawsze oznacza awarię, ale powtarzające się komunikaty dotyczące tego samego dodatku wymagają wyjaśnienia. Nie powinno się ich usuwać przez kasowanie konfiguracji bez wcześniejszego ustalenia przyczyny.

Następnie warto wykonać krótki test funkcjonalny. Zakres zależy od serwera, ale zwykle obejmuje:

• wejście na konto testowe lub administracyjne;
• sprawdzenie pozycji gracza, ekwipunku, enderchesta i osiągnięć;
• teleportowanie między głównym światem a dodatkowymi wymiarami;
• otwarcie skrzyń, drzwi, działek i innych elementów chronionych przez pluginy;
• wykonanie podstawowych komend gracza i administratora;
• sprawdzenie ekonomii, sklepów, rang oraz systemów zapisujących dane;
• utworzenie lub wczytanie chunka w miejscu, które nie było ostatnio używane.

Ten ostatni test ma znaczenie zwłaszcza przy przejściu na nowszą wersję Minecraft. Samo wczytanie centrum świata nie potwierdza, że generowanie nowych obszarów działa poprawnie. Jeżeli serwer korzysta z niestandardowych generatorów, map dodatkowych albo pluginów ingerujących w teren, trzeba sprawdzić je oddzielnie.

Warto również zweryfikować, czy po zamknięciu i ponownym uruchomieniu dane nadal są zachowane. Krótki test restartu może ujawnić problemy ze skryptem, uprawnieniami do plików lub zewnętrzną bazą danych. Dopiero prawidłowy zapis i ponowny odczyt danych gracza daje rozsądną podstawę do uznania aktualizacji za zakończoną.

Aktualizacja pluginów i konfiguracji po zmianie Paper

Paper i pluginy tworzą jeden działający system, ale są aktualizowane niezależnie. Nowa wersja silnika może poprawić zgodność z dodatkiem, lecz może też ujawnić jego błąd albo zmienić sposób obsługi określonej funkcji. Z tego powodu nie powinno się automatycznie wymieniać wszystkich pluginów przy okazji każdej podmiany Paper. Im większy zakres zmian, tym trudniej ustalić, co spowodowało problem.

Przy aktualizacji w tej samej wersji gry bezpieczniejsza jest zmiana etapowa. Najpierw uruchamia się nowy Paper z dotychczasowym zestawem pluginów. Jeżeli serwer działa prawidłowo, można później aktualizować dodatki, które tego wymagają. Każdy etap powinien mieć własną kopię lub przynajmniej jasno określony punkt powrotu.

Inaczej wygląda migracja na nowszą wersję Minecraft. Wtedy część pluginów może wymagać nowych wydań, a część może nie mieć jeszcze zgodnej wersji. Nie należy zakładać, że aktualny plik dodatku będzie działał tylko dlatego, że serwer się uruchomił. Trzeba sprawdzić funkcje, z których faktycznie korzystają gracze, w szczególności systemy przechowujące dane poza samym światem.

Konfiguracji nie powinno się bezrefleksyjnie nadpisywać plikami z czystej instalacji. Taki plik może zawierać poprawne ustawienia dla nowej wersji, ale usunięcie dotychczasowych wartości może zmienić zachowanie serwera. Bezpieczniej porównać starą i nową konfigurację, a następnie przenieść tylko potrzebne ustawienia. Dotyczy to również plików Paper, Bukkit, Spigot oraz konfiguracji poszczególnych pluginów.

Jak postępować, gdy aktualizacja powoduje problem

Jeżeli serwer nie uruchamia się albo po wejściu gracza pojawiają się nieprawidłowości, nie należy od razu wykonywać kolejnych przypadkowych zmian. Najpierw trzeba zatrzymać instancję i zachować logi z nieudanego uruchomienia. Mogą być potrzebne do porównania z logami sprzed aktualizacji lub do ustalenia, który element przestał działać.

Rozpoznanie przyczyny zamiast przypadkowych zmian

Najbezpieczniej porównywać objawy z momentem, w którym problem się pojawił. Jeżeli serwer zatrzymuje się podczas ładowania konkretnego pluginu, najpierw trzeba sprawdzić jego zgodność z używaną wersją Paper i Javy. Jeżeli uruchamia się poprawnie, ale gracze tracą dostęp do określonej funkcji, przyczyną może być zmieniona konfiguracja, nieaktualny dodatek albo błąd ujawniający się dopiero podczas wykonywania konkretnej operacji. ^[3]

Nie powinno się usuwać folderu świata, plików graczy ani całego katalogu plugins tylko po to, aby sprawdzić, czy serwer wystartuje. Taki test może ukryć źródło problemu i jednocześnie pozbawić instalację danych potrzebnych do odtworzenia błędu. Jeżeli trzeba wyłączyć plugin, lepiej zrobić to tymczasowo i zachować jego pliki konfiguracyjne oraz logi.

Powrót do poprzedniej wersji Paper

Jeżeli nowa wersja powoduje awarię, a przyczyny nie da się szybko usunąć, można wrócić do poprzedniego pliku silnika. Serwer należy wcześniej zatrzymać, a następnie przywrócić plik Paper, skrypt startowy i ewentualne zmiany w konfiguracji wykonane podczas aktualizacji. Foldery świata i dane graczy powinny pozostać nietknięte, o ile problem nie wynikał z ich uszkodzenia.

Trzeba jednak rozróżnić zwykłą podmianę pliku silnika od migracji danych do nowszej wersji Minecraft. Po uruchomieniu świata na nowszej wersji niektóre dane mogą zostać zapisane w sposób, którego starsza wersja nie obsługuje prawidłowo. Z tego powodu cofanie zmian po migracji powinno odbywać się przez odtworzenie pełnej kopii wykonanej przed pierwszym uruchomieniem na nowej wersji, a nie przez samo wstawienie starszego pliku Paper.

Jeżeli aktualizacja zakończyła się częściowym zapisem świata albo przerwaniem procesu, nie należy nadpisywać kopii kolejnymi próbami. Najpierw trzeba zabezpieczyć aktualny stan, a dopiero potem zdecydować, czy naprawa będzie prowadzona na jego podstawie, czy przywrócona zostanie wcześniejsza, sprawdzona kopia.

Aktualizacja Paper bez utraty danych — najważniejsze zasady

Bezpieczna aktualizacja Paper polega przede wszystkim na kontrolowaniu zakresu zmian. Sam plik silnika można zwykle podmienić bez usuwania świata, graczy, pluginów i konfiguracji, pod warunkiem że serwer nadal korzysta z tego samego katalogu oraz właściwego skryptu startowego. Ryzyko rośnie wtedy, gdy jednocześnie zmieniana jest wersja Minecraft, Java, pluginy i ustawienia.

Przed aktualizacją trzeba przygotować działającą kopię, po zmianie przeprowadzić test konsoli i funkcji serwera, a przy problemach zachować logi oraz skorzystać z ustalonego sposobu powrotu. Przy prostym serwerze wystarczy zwykle podmiana pliku Paper w tej samej wersji gry. Przy rozbudowanej instalacji bezpieczniejsza będzie aktualizacja etapowa albo test na osobnej kopii.

Dzięki takiemu podejściu aktualizacja nie staje się resetem serwera, lecz kontrolowaną wymianą jednego elementu działającej instalacji. Świat, dane graczy i konfiguracja pozostają na swoim miejscu, a każda dodatkowa zmiana ma określony cel, punkt kontroli i możliwość odtworzenia poprzedniego stanu.

Co warto zapamiętać

• Aktualizacja Paper zwykle nie wymaga resetowania świata, graczy ani konfiguracji, jeśli podmieniany jest wyłącznie plik silnika.
• Przed każdą zmianą należy prawidłowo zatrzymać serwer i wykonać kompletną kopię zapasową katalogu serwera oraz zewnętrznych baz danych.
• Przejście na nowszą wersję Minecraft to migracja świata, a nie tylko wymiana pliku Paper.
• Trzeba sprawdzić zgodność Javy, pluginów, konfiguracji i wszystkich używanych baz danych.
• Najbezpieczniej testować aktualizację na kopii serwera, aby zachować możliwość powrotu do poprzedniej instalacji.

Źródła

• [1] PaperMC – Updating | PaperMC Docs ↑
• [2] PaperMC – Migrating to or from Paper | PaperMC Docs ↑
• [3] PaperMC – Basic troubleshooting | PaperMC Docs ↑