A completed backup job proves that a job finished. To establish whether it can recover your server, restore one selected backup into an isolated environment, join the intended world, and verify a new save after a restart. Keep the live instance and the original backup untouched throughout the exercise.
This procedure applies to Linux game servers generally. The save command, world selection and database requirements depend on the game. Set aside enough storage for the downloaded backup, extracted files and a writable test copy; a nearly full recovery machine can invalidate the exercise.
Define what recovery must preserve#
Pick a specific backup identifier and record its creation time, game version, mod or plugin versions, and the world or save name. Choose evidence you can recognize: a building at known coordinates, a player's inventory, progression and an allowlist entry. Use a backup old enough to exercise recovery from your actual off-machine storage.
Agree on two separate targets. The acceptable age of recovered state describes how much progress you can lose. The recovery-time target describes how long players can remain unable to play. Start a real timer when retrieval begins; downloading dependencies and finding the decryption key count toward recovery time.
Build a complete, consistent recovery set#
An archive containing only the world directory may omit player databases, permissions, mod configuration or an external SQL database. Make a short inventory before creating the backup:
| Item | What to identify |
|---|---|
| Saved state | Selected world, dimensions, player files, shared databases |
| Runtime | Game build, executable source, Java/runtime version, mods |
| Configuration | Launch arguments, service user, working directory, permissions |
| Dependencies | Database export, encryption key location, required extensions |
For a straightforward baseline, announce maintenance, perform the game's normal save and graceful stop, and confirm the process has exited. Freeze every writer that contributes related state before copying files or making database exports. An external database needs its supported backup method and a coordinated recovery point; copying its live data directory is not a substitute.
If downtime is unacceptable, follow the game's documented save-flush or snapshot integration instead. A filesystem snapshot alone does not settle application consistency. Restart production after the backup is complete and independently confirm it works; the remaining drill uses the copy.
If you administer your own hosts through a panel such as Nexardo, include independent host-access instructions in the recovery record. The drill should remain possible when that panel is unavailable.
Retrieve the copy and check its bytes#
Download using the credentials and instructions you would have after losing the original machine. Retrieve required encryption keys from their separate protected location. A backup readable only through credentials stored on the failed disk is an incomplete recovery plan.
For a tar backup with a separately retained checksum, an example check is:
cd "$HOME/recovery-inbox"
sha256sum --check server-backup.tar.gz.sha256
tar --list --gzip --file server-backup.tar.gz
Use the actual filenames and a checksum file that names only your intended archive. Matching hashes establish that the retrieved bytes match the recorded copy; they cannot establish that the source world was healthy. Repository tools have similar distinctions: restic separates structural checks from reading stored data. Budget time and bandwidth for the check you select.
Restore into a separate, restricted environment#
Use a separate unprivileged account or disposable VM, with no write access to production paths. Create a fresh empty destination. Inspect archive entries before extraction and reject absolute paths, .. traversal, symbolic links, hard links and special files for this ordinary game-data restore. Set a storage quota or equivalent size limit; a small compressed archive can expand dramatically.
Choose an extractor with suitable safety controls; Python documents extraction filters and remaining limitations. Do not unpack as root or reuse a destination containing old links. Backups legitimately using links require an explicit inventory and a separate reviewed restoration procedure.
Recover the matching game/runtime and mod versions. Do not silently upgrade the save during the drill: a conversion would test a second operation and may prevent comparison with the original state.
Prevent the recovered copy from acting as production#
Before launching anything, inspect copied launch scripts, absolute paths, scheduled tasks and environment files. Disable production database connections, webhooks, payment or moderation integrations, automatic updates and backup schedules. Use test-only credentials and a separately restored database; restrict outbound access where needed.
Bind to loopback or an isolated private interface when the game supports it. Otherwise enforce an inbound firewall allowing only the tester and allocate distinct game, query and administration ports. Do not publish the copy in a public browser. Check actual listeners and process ownership after launch, including optional interfaces enabled by configuration.
Verify the world, then save and restart#
Join with a compatible real game client through the private test endpoint. Check the landmarks, player state and permissions selected earlier. Review logs for missing content, failed database connections or a newly generated empty world.
Make an unmistakable disposable change in the test world. Save using the game's normal mechanism, stop gracefully, restart the same recovered instance and reconnect. The change must persist. A successful process start or open port does not replace this check.
Record the backup identifier, recovered versions, checks performed, actual elapsed time and any missing dependency. Store the procedure and evidence where another administrator can access them during an outage. Stop the test instance and remove only its owned resources when finished. Keep the original backup; repeat the drill after changing the backup format, runtime, mods or storage provider. A server-backup discussion on Admincraft illustrates why having an archive and knowing how to recover it are separate operational tasks.
