Move a Game Server to a New Computer: Saves, Configuration and Cutover
Published and official references checked 2026-09-07 · SameOS operator
Moving a world folder is only part of a server migration. A new build can convert it, a different service user can prevent saves, and friends can keep joining the old host. This guide moves the same game and edition between Linux dedicated-server hosts. Converting single-player saves or changing editions requires separate procedures.
1. Inventory files and runtime requirements
Record the game build, launch method, Java/loader versions, mods/plugins, launch command, settings, actual data root, service user, ports and backup path. For Docker, record the running image ID or digest and mount mappings as well as the tag. The name latest does not guarantee the same binary later.
Confirm the paths the game reads, including Minecraft level-name and implementation-specific dimension layout, or the actual Palworld Saved tree. Copying a symlink does not necessarily copy its target or an external mod database. Even dedicated-to-dedicated moves need checks for player identity affected by platforms or mods.
2. Prepare the destination with matching versions
Keep migration separate from game upgrades so failures are easier to attribute. Prepare matching game, loader and mod versions first. Also check host architecture: the same package name does not make an x86_64 binary run on ARM.
Prepare the service user, capacity, data mount and game access rules before loading saves. Limit the destination to approved test clients and review public listing, automatic updates and backup jobs. A test server must not overwrite production backups or open the same shared files as the old server.
3. Separate rehearsal from the final copy
Use a verified backup for rehearsal. A raw copy of a live directory can mix save times and should not be treated as the final recoverable snapshot. Unless you have validated game-supported save freezing or consistent snapshots, making the final copy after graceful shutdown is simpler.
At cutover, prevent new joins, save in-game, stop gracefully, confirm the process has exited and then copy. Ensure restart policies or a control panel do not relaunch the old host. Letting both servers accept progress before copying finishes creates competing histories.
4. Verify rsync direction and trailing slashes
The example sends data from the old host to the new one. It assumes gameadmin has the necessary access on both hosts and an empty destination directory already exists. Replace documentation address 192.0.2.20 with your host. Keep both locations outside public web directories.
The trailing slash on data/ copies its contents rather than nesting the directory itself. Preview with -n, check paths and then copy. The example does not synchronize deletions. Confirm the target is a separate empty migration directory, not another live world.
rsync -an --itemize-changes /srv/minecraft/data/ [email protected]:/srv/migration/minecraft/data/
rsync -a --info=progress2 /srv/minecraft/data/ [email protected]:/srv/migration/minecraft/data/5. Verify content and ownership separately
The checksum dry run below reads both sides and can take time and I/O on large worlds. Run it while neither server writes to those paths. Investigate differences, transfer errors or unexpected modifications before launching.
Do not assume unprivileged rsync -a preserves every owner and group. Check destination service users and numeric UID/GID values, and adjust only the migration tree as needed. ACLs and extended attributes require separate preservation planning and options.
This comparison does not remove or fully inventory destination-only files. Starting empty avoids stale test data. Do not reuse a previously booted rehearsal directory for the final cutover; prepare a fresh destination.
rsync -anc --itemize-changes /srv/minecraft/data/ [email protected]:/srv/migration/minecraft/data/6. Check players and saving after the world loads
Check the logged save path and world name. In Minecraft, inspect known structures, dimensions, inventory and permissions. In Palworld, verify existing characters, guilds and ownership as well as the visible world. Validate in-game state rather than assuming a short file checklist guarantees recovery.
Save a small change and verify it survives graceful shutdown and restart. This exposes write-permission or path mistakes that a successful join can miss. Keeping ordinary players out until verification makes rollback decisions simpler.
7. Define cutover and the rollback boundary
For a LAN move, update router forwarding to the new internal address and test externally. If the public address changes, update DNS and player instructions. Cached records can still point players to the old address; keep the old game closed to joins.
Before ordinary play starts on the destination, returning to the preserved final source state is relatively simple. Once new progress exists, restarting the old host can lose it. Preserve the new saves too, choose the recovery point explicitly and do not merge world directories arbitrarily.
Complete migration only after joining the new address, saving/restarting, creating destination backups and checking recovery. Retain old saves for your chosen period and retire them only after the new backup process is proven recoverable.
Verification scope and official references
This Linux operations guide was checked against the linked documentation and command options. Paths, service names, addresses and diagnostic scenarios are illustrative, not incident reports or performance measurements from SameOS game servers. We did not induce production failures or modify production saves. Confirm paths and behavior for your game build and deployment before applying changes.