GameHosting.pl

Notatki operatora

Kopie zapasowe serwera Minecraft: backupy i automatyzacja

Praktyczny przewodnik po tym, jak nie stracić świata, w który gracze włożyli setki godzin. Co backupować, jak zrobić bezpieczną kopię przy żywym serwerze (save-off, save-all flush, save-on), jak ją zautomatyzować skryptem z tar i cronem na Linuksie, jak rotować archiwa, trzymać kopię off-site i, co najważniejsze, jak sprawdzić, że kopia naprawdę działa. Z perspektywy kogoś, kto już raz odbierał telefon „mapa zniknęła”.

Opublikowano · ~9 min czytania

W skrócie: Backupuj foldery świata (world, a na Paper/Spigot także world_nether i world_the_end), server.properties, configi i plugins. Przy działającym serwerze rób kopię w sekwencji save-off → save-all flush → kopiowanie → save-on, żeby nie złapać plików w połowie zapisu. Automatyzuj skryptem z tar uruchamianym przez cron, rotuj stare archiwa, jedną kopię trzymaj poza serwerem (off-site) i raz na jakiś czas przetestuj odtworzenie. Jeśli nie chcesz tego klepać ręcznie, weź hosting z automatycznymi backupami w panelu.

Po co w ogóle backup, skoro jest autosave

Autosave w Minecraft zapisuje świat na bieżąco, ale to nie jest kopia bezpieczeństwa, tylko bieżący stan. Jeśli świat się uszkodzi, ktoś wykasuje pół spawnu, wadliwy plugin nadpisze działki, albo dysk padnie, autosave nie ma czego przywrócić, bo on właśnie utrwalił ten zepsuty stan. Backup to cofnięcie się w czasie: wczorajsza, sprzed tygodnia albo sprzed aktualizacji wersja świata, do której możesz wrócić.

Najczęstsze powody, dla których backup ratuje serwer: griefing i pomyłki graczy (przypadkowe /fill przez admina to klasyk), nieudana aktualizacja Minecraft lub pluginu, uszkodzenie chunków po crashu, no i zwykła awaria sprzętu. Każdy z tych scenariuszy potrafi skasować postępy społeczności w jednej chwili, a to najszybsza droga, żeby gracze odeszli i nie wrócili.

Co dokładnie backupować

Sercem każdej kopii są foldery świata. To w nich siedzi teren, budowle, zawartość skrzyń i pozycje graczy. Na serwerach Spigot i Paper (a to dziś standard) dimensje są rozbite na osobne katalogi:

Warto wiedzieć, skąd ten podział. W czystym, waniliowym serwerze wszystkie wymiary leżą wewnątrz jednego folderu world (Nether w podkatalogu DIM-1, End w DIM1). Dopiero serwery oparte na Bukkit (Spigot, Paper) wyciągają je do osobnych folderów world_nether i world_the_end. Jeśli backupujesz Paper i pominiesz te dwa katalogi, po odtworzeniu wrócą Ci tylko Overworld, a Nether i End będą wygenerowane od zera. Jeśli masz dodatkowe światy (na przykład z Multiverse), one też mają własne foldery do skopiowania.

Poza światem warto zgrać też resztę, żeby po odtworzeniu serwer był sobą, a nie świeżą instalką:

W praktyce najprościej archiwizować cały katalog serwera i wykluczyć tylko śmieci, których nie chcesz wozić: logi, foldery cache i sam plik silnika serwera, który zawsze pobierzesz na nowo. Nie musisz backupować pliku .jar Papera, ale zapisz sobie gdzieś jego dokładną wersję, bo świat z nowszej wersji nie wczyta się poprawnie na starszej.

Bezpieczna kopia: zatrzymanie zapisu

Najczęstszy błąd przy backupie żywego serwera to skopiowanie plików świata w trakcie, gdy Minecraft akurat je zapisuje. Wynik to uszkodzone, niespójne archiwum, które wygląda na kompletne, dopóki nie spróbujesz go odtworzyć. Są dwie poprawne drogi.

Wariant 1: serwer wyłączony

Najbezpieczniej. Zatrzymujesz serwer komendą stop z konsoli, czekasz aż proces się zakończy, dopiero wtedy kopiujesz pliki. Skoro nic nie pisze do plików świata, kopia na pewno jest spójna. Minus jest oczywisty, serwer jest na ten czas offline, więc to rozwiązanie pasuje do nocnych okien serwisowych albo małych serwerów.

Wariant 2: serwer działa, wstrzymujesz tylko zapis

Tu wchodzą trzy komendy konsoli serwera, które trzeba znać na pamięć:

KomendaCo robi
save-offWyłącza zapisywanie plików świata na dysk. Zmiany w grze trafiają do kolejki i czekają, plik na dysku przestaje się zmieniać, więc można go bezpiecznie skopiować.
save-all flushWymusza natychmiastowy zapis wszystkich chunków i danych graczy na dysk. Dopisek flush (Minecraft 1.16+) gwarantuje, że nic nie zostaje w buforze. Dzięki temu kopia łapie aktualny, kompletny stan świata.
save-onPrzywraca normalne zapisywanie. Wykonaj koniecznie po zakończeniu kopiowania, inaczej serwer dalej kolejkuje zmiany i przy crashu stracisz wszystko, co zaszło od save-off.

Właściwa kolejność jest taka:

  1. save-off, zatrzymaj zapis do plików.
  2. save-all flush, zrzuć aktualny stan świata na dysk.
  3. Skopiuj foldery świata i konfigurację (kopia, zip albo tar).
  4. save-on, włącz zapis z powrotem.

Z doświadczenia: najgroźniejszy jest scenariusz, w którym skrypt zrobi save-off, kopiowanie się wywali (skończy się miejsce, padnie sieć), skrypt zakończy się błędem i nigdy nie wykona save-on. Serwer chodzi dalej z wyłączonym zapisem i przy najbliższym restarcie cofa się do stanu sprzed backupu. Dlatego dobry skrypt wywołuje save-on w bloku, który wykona się zawsze, niezależnie od tego, czy tar się udał.

Metody backupu

Ręcznie: kopia folderu lub zip

Najprostsza droga na początek. Wyłączasz serwer (albo robisz save-off i save-all flush), a potem kopiujesz folder serwera w inne miejsce lub pakujesz do archiwum. Na Linuksie zwykle:

tar -czf backup-2026-06-04.tar.gz world world_nether world_the_end \
    plugins server.properties bukkit.yml spigot.yml paper-global.yml

Plus: zero zależności, robisz to w 30 sekund. Minus: to człowiek musi pamiętać, żeby kliknąć, a człowiek nie pamięta. Backup ręczny sprawdza się przed jednorazowym ryzykiem (aktualizacja wersji, instalacja nowego pluginu, większa przebudowa spawnu), nie jako stała ochrona.

Plugin do automatycznych kopii

Jeśli wolisz trzymać wszystko w samej grze, sięgnij po sprawdzony plugin. Dwa realne, popularne wybory na Spigot/Paper to:

Plugin jest wygodny, bo działa od środka i sam zna komendy save-off/save-on. Ma jednak wadę: jeśli pakuje na ten sam dysk co serwer, to nadal jedna lokalizacja, więc i tak potrzebujesz wynoszenia kopii poza maszynę.

Skrypt plus cron na Linuksie

To rozwiązanie, które poleca większość operatorów na VPS lub serwerze dedykowanym, bo jest niezależne od pluginów i daje pełną kontrolę. Zakłada, że serwer chodzi w sesji screen (albo udostępnia RCON), żeby skrypt mógł wysłać do niego komendy.

Przykładowy skrypt backup.sh dla serwera uruchomionego w screen o nazwie mc:

#!/bin/bash
set -u

SERVER_DIR="/opt/minecraft"
BACKUP_DIR="/opt/backups/minecraft"
SCREEN_NAME="mc"
STAMP=$(date +%F-%H%M)
ARCHIVE="$BACKUP_DIR/mc-$STAMP.tar.gz"

mkdir -p "$BACKUP_DIR"

# wyslij komende do konsoli serwera w sesji screen
mc_cmd() { screen -S "$SCREEN_NAME" -p 0 -X stuff "$1$(printf '\r')"; }

# 1) wstrzymaj zapis i zrzuc stan na dysk
mc_cmd "save-off"
mc_cmd "save-all flush"
sleep 10

# 2) zawsze wlacz zapis z powrotem, nawet gdy tar sie wywali
trap 'mc_cmd "save-on"' EXIT

# 3) spakuj swiat i konfiguracje
tar -czf "$ARCHIVE" \
    -C "$SERVER_DIR" \
    world world_nether world_the_end \
    plugins server.properties \
    bukkit.yml spigot.yml paper-global.yml paper-world-defaults.yml

# 4) rotacja: skasuj archiwa starsze niz 7 dni
find "$BACKUP_DIR" -name 'mc-*.tar.gz' -mtime +7 -delete

Kilka rzeczy, które tu naprawdę ważą:

Nadaj skryptowi prawo wykonywania (chmod +x backup.sh) i dodaj wpis do crontab (edytujesz przez crontab -e), na przykład codzienna kopia o 4 nad ranem, gdy ruch jest najmniejszy:

# minuta godzina dzien miesiac dzien_tygodnia  polecenie
0 4 * * *  /opt/minecraft/backup.sh >> /opt/backups/backup.log 2>&1

Pięć pól crona to kolejno: minuta, godzina, dzień miesiąca, miesiąc, dzień tygodnia. Powyższy wpis czyta się jako „o godzinie 4:00 każdego dnia”. Przekierowanie >> ... 2>&1 dopisuje wynik (i błędy) do logu, dzięki czemu po cichej awarii masz gdzie zajrzeć. Upewnij się, że narzędzia używane w skrypcie są w PATH crona i że użytkownik crona ma prawa do plików serwera.

Gotowiec wart uwagi: zamiast pisać skrypt od zera możesz użyć sprawdzonego, otwartego skryptu nicolaschan/minecraft-backup. Sam obsługuje sekwencję save-off/save-all flush/save-on przez RCON, screen, tmux albo Dockera, pakuje do tar lub do deduplikowanego repozytorium restic i ma wbudowaną rotację (tryb „thin”: ostatnie 24 godzinne, 30 dziennych, reszta tygodniowe, albo zwykłe kasowanie od najstarszej). Wpinasz go w crona tak samo jak własny skrypt.

Rotacja i przechowywanie poza serwerem

Codzienny backup bez rotacji to bomba zegarowa, w którymś momencie archiwa zapchają dysk i serwer się wywróci. Dlatego ustalasz, ile kopii trzymasz, i kasujesz starsze. Najprostsza rotacja po czasie to pokazany wyżej find ... -mtime +7 -delete (trzymaj 7 dni). Wygodny schemat to kilka dziennych, kilka tygodniowych i kilka miesięcznych, żeby móc cofnąć się i o dzień, i o miesiąc, nie magazynując setek plików.

Druga, ważniejsza sprawa: kopia na tym samym dysku co serwer nie jest backupem, jest tylko drugą szansą przy pomyłce gracza. Gdy padnie dysk, skasujesz maszynę albo dostaniesz ransomware, ginie oryginał i kopia naraz. Dlatego jedną kopię wynosi się poza serwer (off-site). W praktyce po spakowaniu archiwum wysyłasz je w inne miejsce, na przykład:

# kopia na inny serwer przez rsync (po SSH)
rsync -az "$ARCHIVE" backup-user@backup-host:/backups/minecraft/

# albo do magazynu obiektowego zgodnego z S3
# aws s3 cp "$ARCHIVE" s3://moj-bucket/minecraft/

Taką linijkę dokładasz na końcu skryptu, po spakowaniu. Wtedy lokalne archiwum chroni przed pomyłką, a kopia off-site przed utratą całej maszyny.

Reguła 3-2-1 i dobre praktyki

Branżowy standard, który warto przyjąć od pierwszego dnia, to zasada 3-2-1:

Do tego garść praktyk, które oddzielają działający backup od pobożnych życzeń:

Test odtworzenia: krok, którego nie wolno pominąć

To najczęściej pomijana część całej układanki i jednocześnie ta, która decyduje, czy backup w ogóle coś jest wart. Kopia, której nigdy nie odtworzono, to tylko nadzieja. Archiwum może być obcięte, spakowane w trakcie zapisu, pozbawione folderu world_nether albo zawierać niezgodną wersję, a dowiesz się o tym dokładnie w najgorszym momencie, gdy będziesz go potrzebować naprawdę.

Dlatego co jakiś czas (przyjmij sobie na przykład raz w miesiącu) przeprowadź próbny restore:

  1. Rozpakuj archiwum na bok, najlepiej na osobnym, testowym serwerze, a nie na produkcji.
  2. Uruchom je na tej samej wersji Minecraft i Papera, z której pochodzi kopia.
  3. Sprawdź, czy świat się wczytuje, czy Nether i End są na miejscu, czy gracze mają swoje przedmioty i pozycje.
  4. Zerknij do logu startowego, czy pluginy wstają bez błędów (regiony WorldGuard, rangi LuckPerms i tak dalej).

Dopiero udane uruchomienie potwierdza, że masz prawdziwą kopię bezpieczeństwa, a nie plik, który tylko udaje backup. Przy okazji ćwiczysz samą procedurę, więc w realnym kryzysie odtwarzasz świat spokojnie i z głowy, a nie czytając poradniki pod presją.

Najczęstsze pytania

Co dokładnie backupować na serwerze Minecraft?

Foldery świata: world, a na Paper/Spigot także world_nether i world_the_end, do tego server.properties, configi, folder plugins/ oraz listy uprawnień i banów (ops.json, whitelist.json, banned-players.json). Najprościej archiwizować cały katalog serwera bez logów i cache.

Czy mogę robić kopię przy działającym serwerze?

Tak, w sekwencji save-off → save-all flush → kopiowanie → save-on, żeby nie złapać plików w połowie zapisu (flush działa od 1.16). Bezpieczniejsza, choć z przestojem, jest kopia przy wyłączonym serwerze.

Jak zautomatyzować backupy na Linuksie?

Skryptem powłoki uruchamianym przez cron: skrypt wysyła save-off i save-all flush do serwera, pakuje folder przez tar, robi save-on i kasuje stare archiwa przez find -mtime. Można też użyć gotowego skryptu nicolaschan/minecraft-backup.

Po co trzymać kopię poza serwerem?

Bo kopia na tym samym dysku ginie razem z serwerem przy awarii dysku, skasowaniu maszyny czy ransomware. Zasada 3-2-1 zakłada jedną kopię off-site, którą wysyłasz rsynciem albo klientem S3 w inne miejsce.

Czy muszę testować odtwarzanie kopii?

Tak. Backup, którego nigdy nie odtworzono, to tylko nadzieja. Co jakiś czas rozpakuj archiwum na testowym serwerze i sprawdź, czy świat się wczytuje, gracze mają swoje rzeczy, a pluginy startują bez błędów.

Powiązane