Update a Linux game server without losing its configuration

Updating a Linux game server without losing its configuration requires a controlled procedure. This maintenance concerns a Minecraft, FiveM, Rust, RedM or other multiplayer server installed on a VPS or a dedicated server. Three layers must be distinguished: the Linux system and its packages, the runtime or container that runs the game, then the game, world, mod and plugin files.

An update is not just restarting the process. The server must be shut down cleanly to finish writing the world and the database, the backups must be verifiable, then the service, the port, the firewall and the console must be checked. This method reduces the risk of lost configuration and makes it easier to return to the previous version.

Identifying the game server

Before opening an SSH terminal, note the distribution, the Linux version, the game name, the server version, the framework and the startup manager. A Pterodactyl installation is not handled like a systemd daemon or a server started by Docker Compose. Also identify the node or container involved so you do not stop another service.

• Run cat /etc/os-release to find out the distribution.
• Locate the folder for the world, resources, mods, plugins and configuration files.
• Note the game port, the SSH port, the console port and the administrator accounts.
• Check CPU, RAM and disk with free -h and df -h.
• Check recent errors in the service log.
• Keep the IP address and firewall rules before any change.

The logs let you separate a Linux package problem from a plugin or mod error. Read our guide to analyzing a Linux game server's logs with journalctl before starting the maintenance.

Preparing the maintenance window

Announce a start time, an estimated duration and a way to follow the return online to your players. For Minecraft, state whether a world conversion is possible. For FiveM or RedM, list the resources and scripts that might require adaptation. For Rust, check the version changes and the persistent data. Do not mix a Linux update, a panel migration and a complete plugin overhaul in the same operation without a separate plan.

Keep a reference state: version before maintenance, service status, folder sizes, available disk space, CPU load, RAM consumption, IP address, firewall rules and the result of a player connection. This comparison will be useful after the restart.

Backing up the configuration, the world and the mods

Stop the game server using its usual method, then wait for the process to finish. A consistent backup includes the worlds, the databases, the config files, the permissions, the whitelists, the startup scripts, the resources, the mods and the plugins. For a Pterodactyl server, copy the necessary items from the volume or use the backup mechanism provided by the panel.

Verify the archive by listing its contents and comparing a few representative files. Keep a copy independent from the machine being updated. The backup and reversibility page presents the principles to apply, and the Pterodactyl backups and restoration guide details the case of a game server panel.

Testing the restoration

An untested backup is not yet a rollback plan. Restore a copy to an isolated environment or another server, then start the process with a different port. Check the world loading, the presence of plugins and mods, console access, permissions and the connection of a test account. For a database, verify that a read and a write work.

Do not restore a copy directly onto production without keeping a second backup. Note the date, the path, the game version and the test result. This precaution is important before a Minecraft world conversion, a FiveM framework evolution or a runtime change.

Updating the Linux packages

On a distribution using APT, first refresh the index, examine the proposed packages, then apply the update during the planned window. Read the confirmation prompts and the messages flagging a service to restart. A package update is not automatically a full distribution upgrade: the latter requires separate preparation.

sudo apt update
apt list --upgradable
sudo apt upgrade

Commands vary by distribution. Use the official documentation of the installed Linux version and avoid copying a Debian or Ubuntu command onto another distribution without checking it. A root administrator must reread every shell script before execution. If the server runs in Docker, also check the image, the persistent volume, the Compose file and the runtime version. For VPS use, see Linux VPS and the guide to installing Docker on a VPS.

After a kernel or library change, Linux may recommend a restart. Schedule it explicitly, keep a backup console and confirm that the backup is accessible before running sudo reboot.

Configuring command-line administration

To administer the server, work with the intended account and use sudo when necessary. Do not run a copied command without rereading its path, its options and its impact. Before changing a server configuration, create a dated copy. Also check the partitions with df -h: a full partition can interrupt an installation or corrupt a log. After the operation, an administrator can compare the service, the configuration and the installed packages. A service or an extension should only be disabled after a backup and after identifying its dependency.

Updating the game, the framework and the plugins

Once the system is validated, update the game server separately. Keep the old version in an archive or a clearly named folder. Download only files from the official source of the game, the framework or the plugin. Respect the release notes: a FiveM resource, a Minecraft plugin or a Rust mod may require a specific version of the server, of Java, of .NET or of another dependency.

1. Stop the service, the container or the server from the usual panel.
2. Wait for the full stop and verify that the world and the database are no longer being written.
3. Copy the configuration and keep the previous version.
4. Install the new version without overwriting customized files by default.
5. Compare the configuration files and apply the necessary changes one by one.
6. Start with restricted player access, then watch the console and the logs.

Do not assume that all extensions are compatible. Temporarily disable a suspicious plugin or resource only after keeping its copy, then reintroduce the elements progressively. A private Git repository can also keep versions of config files, but it must never contain a password, an API key or a secret.

Verifying the service, the network and performance

After startup, check the status of the daemon or container, the console, the listening port, the firewall, the CPU load, the RAM and the disk space. Test a player connection, an administration command, the loading of a world or a resource, then watch the logs for several minutes. A server that starts but generates repeated errors is not yet validated.

If the VPS becomes unreachable, check in order the SSH connection, the service, the game process, the firewall and the port. Do not immediately delete UFW rules or configuration files. Our guide to network diagnosis of an unreachable VPS offers quick triage. For the first security settings, see securing a dedicated server.

Planning the rollback

If an error appears, stop the server, keep the logs and compare the versions. First return to the old version of the plugin or the binary if the change is isolated. If the data has been modified, use the validated backup and check the world or the database after restoration. Document the command, the cause and the result so as not to repeat the same operation.

A maintenance log must contain the date, the operator, the versions before and after, the archive used, the checks that passed and the final decision. This trace also helps during a migration. See migrating a FiveM server for the checks specific to an infrastructure change.

Update checklist

• The game, the world, the plugins, the mods and the distribution are identified.
• The maintenance window has been announced to the players.
• The configuration, the persistent data and the extensions are backed up.
• The restoration has been tested or the rollback plan is documented.
• The Linux packages have been examined before installation.
• The service, the console, the port, the firewall, performance and a test connection are validated.