Moving a Minecraft server to a new host or VPS without losses

In short: prepare the new machine with the same Java and the same server build, and lower your DNS record's TTL in advance. Then stop the server with stop, archive the server folder, dump the databases with mysqldump and move everything over. Test the copy by IP, and only then change the A record. Don't delete the old machine until the new one has run for a few days. The DGuard key moves along with the plugins folder.

The moving plan#

Prepare the new machine#

• The same Java. Paper 26.1 and newer needs Java 25; 1.20–1.21.11 runs on Java 21. Compare java -version on both machines. Installing Java on Ubuntu and Debian is covered in Minecraft server on Linux.
• The same version and build. A move is no time to update: carry over the same jar and update separately, later — see updating the Minecraft version.
• User, folder, autostart. A dedicated minecraft user, the same folder (say, /opt/minecraft), the systemd unit and the backup cron jobs — move those too.
• Firewall. Game port and SSH inbound, HTTPS outbound. Don't expose RCON or the ports of servers behind a proxy — see server IP and port.
• Database server. If plugins write to MySQL or MariaDB, install it beforehand — see MySQL for plugins.

What to copy#

The simplest approach is to move the whole server folder except logs, cache, libraries and versions — Paper recreates those. It's the same set as for a backup — more in server backups.

Archive, dump and copy#

Only copy a stopped server: an archive of a world the server is writing at that moment can arrive with corrupted chunks. Announce a maintenance window, stop the server and run:

# old machine: the server is stopped (sudo systemctl stop minecraft or stop in the console)
cd /opt/minecraft
sudo tar -czf /root/mc-move.tar.gz \
  --exclude=./logs --exclude=./cache --exclude=./libraries --exclude=./versions .
# plugin MySQL databases; credentials live in ~/.my.cnf
mysqldump --single-transaction --databases minecraft > /root/mc-db.sql
# copy to the new machine
rsync -aP /root/mc-move.tar.gz /root/mc-db.sql admin@203.0.113.20:/tmp/

# new machine
sudo mkdir -p /opt/minecraft
sudo tar -xzf /tmp/mc-move.tar.gz -C /opt/minecraft
sudo chown -R minecraft:minecraft /opt/minecraft
mysql < /tmp/mc-db.sql          # a --databases dump creates the database itself

• --single-transaction dumps InnoDB tables as a consistent snapshot; --databases adds the statements that create the databases themselves.
• A dump of selected databases doesn't include MySQL users: create a user on the new machine with the same name and password your plugin configs use. If the configs pointed at an external database address, update it.
• rsync -a keeps file permissions and modification times; -P shows progress and resumes an interrupted transfer. You can also copy the server folder directly without an archive: rsync -aP /opt/minecraft/ admin@203.0.113.20:/opt/minecraft/ — that user needs write access to the target folder.

File ownership and common errors#

Files unpacked as root belong to root, and a server running as the minecraft user can't write them: access errors show up in the log, and the world and plugin data stop saving. So after unpacking, run chown -R minecraft:minecraft on the whole folder.

If the server sits behind a proxy, update its address in the [servers] section of velocity.toml and the firewall rule that only lets the proxy's IP in — see setting up Velocity.

Test the copy before switching#

1. 1

   Start it and read the log

   Wait for the Done line and look through logs/latest.log for plugin errors — see logs and crashes.

2. 2

   Join by IP

   DNS still points to the old machine, so connect to the new one's address: 203.0.113.20 or 203.0.113.20:port.

3. 3

   Go through the checklist

   Worlds and builds, inventories, claims, permissions, economy, teleports; /plugins — every plugin loaded.

4. 4

   Check the anticheat

   /dguard license shows the plan, the license state and the PacketEvents version.

Switching DNS: A and SRV#

Players join by domain, so changing the A record to the new machine's IP is enough. An SRV record _minecraft._tcp.<domain> points not to an IP but to a name with an A record, so you only touch it if the port changed.

play.example.com.                  300  A    203.0.113.20
_minecraft._tcp.play.example.com.  300  SRV  0 5 25565 play.example.com.

Check the records with dig play.example.com A and dig _minecraft._tcp.play.example.com srv (nslookup -q=srv on Windows). The Minecraft Wiki warns that depending on the player's resolver, changes can take up to a day. Until caches refresh, keep the old machine with the server stopped: if it keeps running, some players will play on the old copy and lose that progress. If the domain is on Cloudflare, the game record must be "DNS only". More on records in server IP and port.

DGuard during a move#

DGuard — the best anticheat for a modern Minecraft server — moves with the plugins folder: the key lives in plugins/DGuard/config.yml (license.key), and you don't need a new one. It needs the latest PacketEvents release next to it, and the new machine needs outbound HTTPS to the DGuard site — the anticheat needs no inbound ports.

Don't start the copy with the same key while the old server is running. On startup the copy becomes the key's owner, and DGuard on the old server locks until a restart, with a message that the key is running on another server. Stop the old server first — or remove the key from the copy's config while you test it.

The panel tracks the server by the heartbeat it sends every minute: as soon as the new machine starts, the server shows as "Online" again. If a server is silent for 10 minutes, DGuard messages you and your team's admins on Telegram or by e-mail — and again when it's back. A long move will trigger that message, which is expected; you can switch off the server's "Alert me if it goes silent" toggle for the duration.

FAQ#