Jak przenieść serwer Minecraft na inny hosting bez utraty danych

Przenosiny serwera Minecraft brzmią groźniej, niż są w rzeczywistości. Cała "magia" serwera to w gruncie rzeczy zestaw plików w jednym katalogu (czasem plus zewnętrzna baza danych), a samo przeniesienie polega na tym, żeby przegrać je w komplecie, uruchomić na nowej maszynie i przełączyć adres, którym łączą się gracze. Problem w tym, że jeśli pominiesz jeden plik, zapomnisz o bazie danych albo pomylisz wersję, możesz stracić świat, uprawnienia operatorów albo całą ekonomię na pluginach. Dlatego w tym poradniku Zespół NobleNodes pokazuje migrację tak, jak robimy ją u siebie: metodycznie, z backupem przed każdym ryzykownym krokiem i z testem zanim cokolwiek zobaczą gracze.

To jest przewodnik manualny, między dowolnymi hostingami, bez znaczenia, czy zostajesz u obecnego dostawcy, czy przenosisz się gdzie indziej. Jeśli natomiast przenosisz serwer akurat do nas i wolisz oddać całą robotę w ręce supportu, napisz do naszego zespołu, a przeprowadzimy transfer za Ciebie. Tutaj skupiamy się na tym, jak zrobić wszystko samodzielnie.

Powodów do przeprowadzki bywa wiele. Czasem to lagi i za słaby sprzęt (jeśli to twój przypadek, zanim zapłacisz za nowy hosting, sprawdź, czy nie da się odzyskać wydajności na miejscu, opisujemy to w tekście o tym, dlaczego serwer Minecraft laguje i jak to naprawić), czasem rosnąca społeczność, która nie mieści się w obecnym pakiecie RAM, a czasem po prostu lepsza oferta gdzie indziej. Niezależnie od motywacji, procedura jest taka sama.

Zanim zaczniesz: pełny backup to fundament

Pierwsza zasada migracji brzmi prosto: nie ruszaj niczego, dopóki nie masz kompletnej kopii. Backup robisz na starym hostingu, najlepiej przy zatrzymanym serwerze, bo wtedy żaden plik nie jest w trakcie zapisu.

Zatrzymaj serwer komendą stop z konsoli, a nie przez ubicie procesu. To ważne, ponieważ stop wymusza zapis świata na dysk (save-all) i poprawnie zamyka pliki. Gdy proces wciąż chodzi, kopia świata może być uszkodzona albo niespójna.

Najwygodniej spakować cały katalog serwera do jednego archiwum. Jeśli masz dostęp do konsoli SSH, jedno polecenie załatwia sprawę, ale zwróć uwagę na flagę -C:

tar -czf backup.tar.gz -C /sciezka/do/serwera .

Przełącznik -C mówi, żeby wejść do katalogu serwera, a kropka na końcu pakuje jego zawartość względem tego katalogu, a nie pełnej ścieżki absolutnej. Dzięki temu przy rozpakowaniu pliki trafią dokładnie tam, gdzie powinny, a nie do zagnieżdżonego podkatalogu w stylu sciezka/do/serwera/.... To drobiazg, który potrafi popsuć całą migrację, gdy świat i konfiguracja wylądują o jeden folder za głęboko i serwer ich "nie widzi".

Mniejsze archiwum przenosi się szybciej, a przy okazji unikasz sytuacji, w której FTP zerwie się w połowie tysiąca drobnych plików świata. Kopię zachowaj również lokalnie na swoim komputerze, nawet jeśli planujesz transfer bezpośrednio między serwerami. Druga kopia kosztuje kilka minut, a ratuje cały projekt, gdy coś pójdzie nie tak.

Co dokładnie przenieść

Nie wszystko w katalogu serwera jest tak samo ważne, ale przy migracji bezpieczniej skopiować całość niż zgadywać. Mimo to warto wiedzieć, co odpowiada za co, bo to pomaga przy weryfikacji po stronie nowego hostingu.

Świat (world)

To serce serwera. Standardowo są to trzy foldery: world (główny wymiar), world_nether oraz world_the_end. Na Paperze i podobnych silnikach wymiary mogą być rozdzielone na osobne katalogi, więc sprawdź, czy nie pominąłeś Netheru i Endu. Pominięcie któregokolwiek oznacza, że gracze stracą budowle w tym wymiarze. Jeśli używasz pluginów do wielu światów (Multiverse), przenieś każdy z nich. Pamiętaj też o folderze world/playerdata/, gdzie siedzą ekwipunki i statystyki graczy.

Pluginy lub mody i ich konfiguracje

Folder plugins/ (Bukkit/Spigot/Paper) albo mods/ (Forge/Fabric) to drugi krytyczny element. Kluczowy szczegół, o którym łatwo zapomnieć: same pliki .jar to za mało. Wewnątrz plugins/ znajdują się podfoldery z konfiguracją i danymi, na przykład bazy ekonomii, regiony WorldGuard, rangi LuckPerms. Skopiuj cały folder z zawartością, inaczej postawisz pluginy "puste", bez żadnych ustawień ani zapisanych danych graczy. Przy modach z Forge lub Fabric dochodzi folder config/ w głównym katalogu, gdzie modpacki trzymają większość ustawień.

Uwaga: część pluginów trzyma dane nie w plikach płaskich w plugins/, tylko w zewnętrznej bazie MySQL/MariaDB. To częsty przypadek na większych serwerach i obsługujemy go w osobnej sekcji niżej, bo skopiowanie samego folderu wtedy nie wystarczy.

Listy graczy: whitelist, ops, banlist

Te pliki JSON leżą w głównym katalogu i decydują o tym, kto ma jakie uprawnienia:

whitelist.json, czyli lista dopuszczonych graczy, jeśli serwer jest zamknięty
ops.json, czyli operatorzy z uprawnieniami administracyjnymi
banned-players.json i banned-ips.json, czyli blokady

Pominięcie ops.json to klasyczny błąd. Po migracji nagle nikt nie ma uprawnień admina. Na szczęście da się z tego wyjść awaryjnie, opisujemy to przy weryfikacji niżej, ale i tak najprościej po prostu skopiować ten plik. Te pliki ważą kilka kilobajtów, więc kopiuj je razem z resztą.

server.properties i pozostałe ustawienia

server.properties przechowuje konfigurację samego serwera: nazwę świata (level-name), tryb gry, trudność, view-distance, simulation-distance, port i wiele innych. Tu jest pułapka: jeśli na starym hostingu twój świat nazywał się inaczej niż domyślne world, to po przeniesieniu serwer wygeneruje pusty świat, bo level-name wskaże na nieistniejący folder. Dlatego przenieś server.properties razem z folderami świata i upewnij się, że nazwa się zgadza.

Do tego dochodzą pliki silnika. W głównym katalogu znajdziesz bukkit.yml, spigot.yml oraz eula.txt. Natomiast na nowszych Paperach (1.19 i wyżej) pliki paper-global.yml i paper-world-defaults.yml leżą w podfolderze config/, a nie w katalogu głównym. Jeśli będziesz je weryfikować ręcznie po stronie nowego hostingu, szukaj ich pod ścieżkami config/paper-global.yml i config/paper-world-defaults.yml. W praktyce, gdy kopiujesz cały katalog jako archiwum, masz to wszystko za jednym zamachem, łącznie z folderem config/. To zresztą argument za podejściem "spakuj całość": mniej decyzji, mniej rzeczy do zapomnienia.

Migracja bazy danych: część, o której najłatwiej zapomnieć

Tu kryje się najgroźniejsza pułapka dla poważnych serwerów. Pluginy takie jak EssentialsX, LuckPerms, CoreProtect czy systemy ekonomii często nie trzymają danych w plikach w plugins/, tylko w zewnętrznej bazie MySQL lub MariaDB. Jeśli tak masz, skopiowanie samego folderu plugins/ przeniesie konfigurację, ale nie przeniesie rang, sald graczy ani logów CoreProtect. Efekt jest okrutny: folder wygląda kompletnie, a po starcie ekonomia i uprawnienia są puste.

Jak sprawdzić, czy plugin używa bazy zewnętrznej? Zajrzyj do jego config.yml. Szukasz sekcji w stylu storage-method: MySQL, database: albo bloku z polami host, port, username, password, database. Jeśli widzisz tam adres bazy i dane logowania, plugin gada z MySQL/MariaDB, a nie z lokalnym plikiem.

Migracja takiej bazy wygląda następująco:

Eksport ze starego hostingu. Zrzuć bazę poleceniem mysqldump -u uzytkownik -p nazwa_bazy > baza.sql. Jeśli twój dostawca daje phpMyAdmin, możesz wyeksportować bazę do pliku .sql przez zakładkę Export.
Utworzenie bazy na nowym hostingu. Załóż nową bazę i użytkownika u nowego dostawcy. Dane dostępowe (host, port, nazwa bazy, login, hasło) zwykle znajdziesz w panelu.
Import. Wgraj zrzut poleceniem mysql -u uzytkownik -p nowa_baza < baza.sql, albo przez zakładkę Import w phpMyAdmin.
Podmiana credentiali w config.yml. To krok, który najłatwiej przeoczyć. W konfiguracji każdego pluginu korzystającego z bazy zaktualizuj host, port, database, username i password na dane nowej bazy. Jeśli zostawisz stare wartości, plugin po starcie będzie próbował łączyć się ze starym serwerem bazy, co skończy się błędem połączenia albo, jeszcze gorzej, pisaniem do starej bazy.

Jeśli nie masz pewności, czy któryś plugin korzysta z bazy, potraktuj eksport jak tani backup i zrób go na wszelki wypadek. Brak importu da się naprawić, ale skasowanej starej bazy już nie odzyskasz.

Transfer plików: FTP czy SFTP

Mając archiwum i ewentualny zrzut bazy, czas wgrać je na nowy hosting. Większość paneli (Pterodactyl, który wykorzystujemy w NobleNodes, oraz inne) daje dostęp przez FTP albo SFTP. Wybieraj SFTP, kiedy tylko jest dostępny, bo szyfruje połączenie i dane logowania nie lecą przez sieć otwartym tekstem. Klasyczne FTP nadal działa, ale to rozwiązanie z innej epoki.

Do połączenia najwygodniej użyć klienta typu FileZilla lub WinSCP. Dane dostępowe (host, port, login, hasło) znajdziesz w panelu nowego hostingu. Po połączeniu wgraj archiwum, a następnie rozpakuj je już na serwerze, jeśli panel ma menedżer plików z taką opcją, albo przez konsolę, znów z flagą -C, żeby pliki trafiły wprost do katalogu serwera:

tar -xzf backup.tar.gz -C /sciezka/do/serwera

Jeśli rozpakowujesz w katalogu, w którym już jesteś (np. menedżer plików otwiera Cię w głównym folderze serwera), wystarczy tar -xzf backup.tar.gz, bo archiwum spakowane z -C zawiera ścieżki względne i wypakuje się dokładnie do bieżącego miejsca. Rozpakowanie po stronie serwera jest dużo szybsze i pewniejsze niż wgrywanie kilkudziesięciu tysięcy pojedynczych plików świata przez FTP. Jeśli twój hosting umożliwia transfer bezpośrednio z maszyny na maszynę (scp albo rsync po SSH), to jeszcze lepiej, bo dane nie robią objazdu przez twoje łącze domowe.

Po wgraniu sprawdź uprawnienia plików. Czasem po rozpakowaniu właściciel plików się nie zgadza i serwer nie może zapisać świata. Większość paneli ma przycisk naprawiający uprawnienia, a w razie wątpliwości pisz do supportu nowego hostingu.

Weryfikacja wersji: najczęstsze źródło katastrof

To moment, w którym ginie najwięcej serwerów podczas migracji. Wersja silnika na nowym hostingu musi się zgadzać z tą, na której świat był prowadzony, albo być nowsza i kompatybilna.

Kilka twardych zasad z praktyki:

Nie cofaj wersji. Świat zapisany w 1.21 nie otworzy się poprawnie na 1.20. Format zapisu się zmienia i ryzykujesz uszkodzenie chunków.
Trzymaj ten sam silnik, a zmiany rób w górę, nie w dół. Jeśli stary serwer chodził na Paperze, postaw Paper. Przejście w górę (Vanilla lub Spigot do Papera, Paper do Purpura) zwykle przebiega bezboleśnie, bo te silniki są wstecznie zgodne. Ale przejście w dół (z Papera/Purpura na Spigot lub Vanilla) potrafi uszkodzić świat, bo Paper i Purpur zapisują w nim własne struktury, których "uboższy" silnik nie rozumie. Jeśli musisz zejść niżej, najpierw zrób backup i przetestuj na kopii.
Sprawdź zgodność pluginów i modów z nową wersją. Plugin pod 1.20 może w ogóle nie wystartować na 1.21. Zanim przełączysz graczy, przejrzyj logi pod kątem błędów ładowania.
Przy modpackach z Forge lub Fabric wersja musi być identyczna co do builda. Inny build loadera albo brakujący mod potrafi wywalić cały świat. Pamiętaj, że Forge i Fabric różnią się architekturą i modów nie da się między nimi mieszać.

Najprościej: zanotuj dokładną wersję ze starego serwera (widać ją w konsoli przy starcie albo w nazwie pliku .jar) i ustaw dokładnie taką samą na nowym.

Test przed przełączeniem adresu

Tu jest sztuczka, która oszczędza nerwów: nowy serwer testujesz pod jego tymczasowym adresem IP i portem, zanim ktokolwiek dowie się o przeprowadzce. Stary serwer w tym czasie najlepiej trzymać wyłączony lub w trybie offline, żeby gracze nie grali na nim dalej i nie tworzyli nowych danych, które potem znikną.

Uruchom nowy serwer i przejdź przez konsolę linijka po linijce. Szukasz błędów ładowania pluginów, brakujących zależności, ostrzeżeń o niezgodności wersji oraz, co istotne po migracji bazy, błędów połączenia z MySQL. Następnie wejdź na serwer jako gracz, korzystając z surowego adresu IP i portu z panelu. Sprawdź konkretne rzeczy, a nie tylko to, czy serwer "wstał":

Czy załadował się właściwy świat, a nie świeżo wygenerowany (rozpoznasz po spawnie i swoich budowlach)
Czy działają pluginy: ekonomia, rangi, regiony, ochrona terenu (jeśli ranga jest pusta, podejrzewaj nieprzeniesioną bazę danych)
Czy twoje konto ma uprawnienia operatora
Czy whitelist i bany są na miejscu

Co zrobić, gdy ops.json jednak przepadł. Jeśli okaże się, że nie masz uprawnień admina, nie panikuj i nie zaczynaj migracji od nowa. Wejdź do konsoli serwera w panelu (nie do gry) i wpisz op TwojNick. Konsola ma uprawnienia poziomu serwera niezależnie od ops.json, więc nada Ci operatora od ręki. Ten sam trik ratuje sytuację, gdy plik operatorów był pusty lub uszkodzony.

Dopiero gdy wszystko gra, przechodzisz do finalnego kroku. To podejście oddziela "serwer się uruchomił" od "serwer naprawdę działa", a różnica między nimi potrafi być bolesna.

Przełączenie adresu i minimalizacja downtime

Gracze łączą się zwykle przez adres typu gra.twojadomena.pl, który wskazuje na IP serwera. Jeśli używasz własnej domeny, masz w panelu DNS rekord A (na IP) lub rekord SRV (gdy port jest niestandardowy). Migracja polega na zmianie tego rekordu, by wskazywał na nowy adres.

Żeby skrócić przestój, zrób jedną rzecz z wyprzedzeniem: na dzień lub dwa przed migracją obniż TTL rekordu DNS do niskiej wartości, na przykład 300 sekund. TTL mówi, jak długo dostawcy internetu trzymają w pamięci stary adres. Domyślne kilka godzin oznacza, że część graczy po przełączeniu jeszcze długo trafia na stary, martwy serwer. Niski TTL skraca to do minut.

Kolejność na dzień migracji wygląda tak: wyłącz stary serwer, zrób ostatni backup świata oraz ostatni zrzut bazy danych (oba mogły się zmienić od poprzedniej kopii), przenieś tę najświeższą wersję, sprawdź ją na nowym hostingu, a dopiero potem przełącz rekord DNS. Po przełączeniu można podnieść TTL z powrotem.

Jeśli łączysz się czystym IP bez domeny, sprawa jest jeszcze prostsza, ale mniej wygodna: nowy serwer ma nowe IP i musisz je rozdać graczom. Dlatego własna domena to inwestycja, która zwraca się dokładnie w takich momentach, bo następnym razem zmienisz tylko jeden rekord, a gracze nie zauważą różnicy.

Checklista po migracji

Gdy gracze są już na nowym serwerze, przejdź przez krótką listę kontrolną, żeby wyłapać to, co umyka na pierwszy rzut oka:

Świat się zgadza, spawn i budowle na miejscu
Wszystkie pluginy lub mody wystartowały bez błędów w logach
Baza danych podłączona, rangi i ekonomia mają realne dane, nie pustkę
Uprawnienia operatorów (ops.json) działają
Whitelist i banlist przeniesione i aktywne
view-distance i simulation-distance ustawione pod nowy sprzęt, bo nowy host może mieć inny zapas mocy
Aikar's flags w parametrach startu JVM (zalecane praktycznie zawsze przy 2 GB heap i więcej, nie tylko na dużych serwerach, bo to tuning garbage collectora G1GC, który redukuje lag-spiki)
TPS w okolicach 20 i MSPT poniżej 50 ms pod realnym obciążeniem graczy
Automatyczne backupy włączone na nowym hostingu od pierwszego dnia
Stary hosting trzymany jeszcze przez tydzień lub dwa jako zapas, zanim go skasujesz

Ten ostatni punkt to nasza twarda zasada. Nie kasuj starego serwera ani starej bazy danych od razu po migracji. Trzymaj je w gotowości, dopóki nie masz pewności, że nowy działa stabilnie i nikt nie zgłasza zaginionych danych. Kilka dni dodatkowej subskrypcji to śmieszny koszt wobec utraconego świata.

FAQ: najczęstsze pytania o migrację serwera Minecraft

Czy podczas migracji stracę progres graczy? Nie, o ile przeniesiesz folder world/ w całości (w tym world/playerdata/) oraz, jeśli pluginy z niej korzystają, zewnętrzną bazę danych. Ekwipunek i statystyki siedzą w playerdata, a salda i rangi często w MySQL.

Czy mogę przenieść serwer bez wyłączania go ani na chwilę? Realnie nie. Krótki downtime jest konieczny, żeby zrobić spójny finalny backup i przełączyć DNS. Niski TTL skraca przerwę do kilku minut, ale zero przestoju przy pojedynczym serwerze nie jest osiągalne bez sieci proxy.

Skopiowałem cały folder, a ekonomia i rangi są puste. Dlaczego? Najpewniej plugin trzyma dane w zewnętrznej bazie MySQL/MariaDB, a nie w plikach. Wykonaj eksport i import bazy oraz podmień dane logowania w config.yml, tak jak opisujemy w sekcji o migracji bazy danych.

Czy mogę przy okazji zmienić wersję Minecraft? Tak, ale tylko w górę i ostrożnie. Aktualizacja na nowszą wersję zwykle działa, cofnięcie wersji uszkadza świat. Zawsze rób to na kopii i sprawdzaj zgodność pluginów przed wpuszczeniem graczy.

Po migracji nie mam uprawnień admina. Co teraz? Wejdź do konsoli serwera w panelu i wpisz op TwojNick. Konsola nada Ci operatora niezależnie od zawartości ops.json.

Jeśli przy okazji przeprowadzki dobierasz nowy pakiet albo wahasz się między typami hostingu, na spokojnie policz potrzeby. Pomoże w tym przewodnik o tym, jak wybrać hosting serwera Minecraft, a gotowe konfiguracje pod różne wielkości społeczności i wersje gry znajdziesz w naszym konfiguratorze. Dobrze przeprowadzona migracja to taka, której gracze w ogóle nie zauważyli, poza tym, że serwer nagle przestał lagować.