How to Automatically Back Up a Paper Server

Define the recovery you actually need

An automatic backup is useful only when it can return the server to a known point. Decide how much recent play you can afford to lose and how quickly the world must be available again. A quiet friends-only server may accept one nightly recovery point; a busy economy or claims server may need several points each day.

Back up the whole service state, not only the folder named world. Paper's current updating guidance names world folders, server configuration, plugin configuration and plugin JARs as the main backup set. Include every dimension and additional world, server.properties, Paper/Bukkit/Spigot settings, permissions, whitelist, operators, bans, startup files and the complete plugins directory. Record the Paper build and Java version too, because restored data is easier to validate with the software that created it.

Map anything stored outside that directory. Economy, permissions, maps, analytics and network plugins may write to MySQL, PostgreSQL, Redis, object storage or another server. A file snapshot from 02:00 paired with a database from 02:20 is not one coherent recovery point. Either capture those systems in the same maintenance workflow or document their own snapshot identifiers beside the file backup. Also exclude caches and replaceable downloads deliberately, never because the backup script happened to miss them.

• Set a maximum acceptable data-loss window and derive the backup frequency from it.
• Inventory every world, configuration file, plugin JAR, plugin data folder and external datastore.
• Record the Paper build, Java runtime, backup time and external snapshot IDs in a manifest.
• Estimate restore time as well as archive time; upload speed is not recovery speed.

Create a consistent Paper snapshot

The safest general-purpose file backup begins with a full Paper shutdown. Paper's troubleshooting documentation warns that modifying server files while the server is running can corrupt them and says only a full shutdown prevents that risk. Schedule a short maintenance window, warn connected players, stop through the console or service manager, and wait until the Java process has actually exited before the backup program reads the directory. A panel changing from “running” to “stopping” is not confirmation that files are quiet.

Do not treat save-all as a complete application backup. It asks the game to write pending world data, but a production server may still have plugin queues, open files and external database transactions. Likewise, a live filesystem snapshot is safe only when the host or storage system explicitly provides an application-consistent workflow for this server layout. If you cannot prove that contract for Paper and every stateful plugin, use stop, snapshot and start instead of trading a few minutes of uptime for an uncertain restore.

Make the sequence failure-aware. The automation should announce maintenance, stop Paper, confirm the process is gone, create the snapshot, verify that the backup command succeeded, and start Paper again even when the upload fails. It must never copy while shutdown is still in progress, silently leave the server offline, or delete the previous good backup before a new one exists. Prevent overlapping runs with the scheduler or a lock so a slow backup cannot collide with the next window.

Choose the right automation path

On managed hosting, begin with the provider's built-in backup and scheduling documentation. Confirm whether a “backup” includes all worlds and plugins, whether it briefly stops the process, where archives are stored, how many are retained, and whether you can download or restore them without support. Build one scheduled chain that stops the server, creates the backup, restarts it and reports the result. A panel schedule that runs only a compression task against live files is not equivalent to a consistent snapshot.

On a self-managed Linux host, use the service manager plus a backup program rather than a loose collection of background shell commands. A systemd timer can express a wall-clock schedule with OnCalendar; Persistent=true can catch a run missed while the host was powered down. Keep the backup operation in a separate service with explicit dependencies, timeouts and logs. Cron can also trigger a tested wrapper, but the wrapper still needs locking, reliable exit codes and a restart path.

A snapshot tool such as restic can store repeated point-in-time backups efficiently and send them to local or remote repositories. Its documentation calls each captured point a snapshot, reuses unchanged data, and recommends running restic check regularly. Treat it as one implementation option, not magic consistency: stop Paper first, back up the complete inventoried paths, attach a meaningful host or tag, and retain the snapshot ID in the job log. Test the exact version and repository backend you deploy.

Keep credentials out of the script and repository. Run the job as an unprivileged account that can read the server files and write only to its intended backup destination. A remote append-only or otherwise restricted credential limits what a compromised game-server account can erase. Store the restore or maintenance credential separately, because an attacker who can delete every remote snapshot can defeat the purpose of off-site storage.

• Prefer a documented host backup feature when it guarantees the scope and consistency you need.
• For self-hosting, schedule one auditable service with locking, timeouts, logs and a guaranteed restart step.
• Keep repository credentials outside scripts and grant the backup client the least destructive access possible.
• Run the first automation manually while watching the console, process state, archive and restart.

Use retention and off-site copies deliberately

One archive overwritten every night protects against very little. Paper recommends backups from multiple times and describes rolling backups as a common approach. Keep short-interval recovery points for recent mistakes, daily points for ordinary rollback and a smaller set of weekly or monthly points for problems discovered late. Choose counts that fit the server's activity and storage budget, then write the policy down so cleanup is predictable.

Keep at least one protected copy outside the game server and its primary account. Another directory on the same disk disappears with the same disk failure; a mounted remote share may still be reachable by malware or a stolen administrator session. CISA recommends offline, encrypted backups of critical data and regular tests of their availability and integrity. For a Minecraft community, that means separating credentials and failure domains, encrypting remote archives, and periodically proving that the repository can be reached from a clean recovery environment.

Retention and space reclamation are separate operations in some tools. With restic, forget applies a policy such as hourly, daily, weekly or monthly keeps; prune removes data no retained snapshot references. The documentation notes that pruning locks the repository and can take time, so schedule it away from backup windows and monitor free space before it starts. Test a dry run when changing policy, and never let an automated cleanup remove the last verified recovery point.

Alert on silent backup failures

A green scheduled-task entry proves only that the scheduler launched something. Define success as all required stages completing: Paper stopped cleanly, the backup tool returned success, a new snapshot exists at the destination, its size is plausible, Paper restarted, and the server passed a health or connection check. Capture start time, duration, byte count, snapshot ID and the final Paper state in one log record. Alert when any field is missing or when the newest successful backup is older than the recovery target.

Watch for the failures that accumulate quietly: expired object-storage credentials, a full local staging disk, an unreachable repository, retention never running, a timer disabled after maintenance, a backup that suddenly shrinks, or a restart that returns before Paper is ready. Send failure notifications somewhere independent of the Minecraft server. If Discord is the only channel and its plugin cannot start, the same incident can hide the alert.

Run a regular repository integrity check as well as per-job validation. Restic recommends restic check to verify the repository's internal structure, with data-reading options available for deeper verification. Checksums and repository checks can show that stored bytes are readable; they cannot prove that the chosen paths include every world or that Paper can use the result. That is why restore drills remain a separate gate.

• Alert when no successful recovery point exists inside the promised window.
• Compare archive size and file counts with recent runs to catch empty or partial inputs.
• Confirm the post-backup Java process is healthy and accepts a real server connection.
• Review job logs and repository checks from a channel that survives a game-server outage.

Prove recovery with an isolated restore drill

Restore tests should happen on a schedule and after any major change to paths, plugins, credentials or backup software. Select a specific snapshot rather than assuming latest is the right one. Restore it into a new empty directory on isolated storage, never over the live server. Restic's restore workflow supports a separate target directory and warns that an in-place restore can leave partially restored files if interrupted; that separation is useful regardless of the backup tool.

Rebuild the recorded environment: use the matching Java runtime, Paper JAR, plugin set, startup flags and external data snapshot. Bind the drill server to a private or different port, block ordinary players, and disable outbound webhooks, payment hooks and writes to production databases. Start from the beginning of the log, not just the final Done line, and inspect every plugin migration or error before joining.

Test the things the community would notice after a disaster. Join with a normal account; visit the overworld, Nether, End and any plugin-managed worlds; inspect inventory, ender chest, permissions, claims, homes, economy and whitelist; then restart the restored server and repeat a smaller pass. Measure how long download, extraction and validation take. Record the drill result and fix missing data immediately, because an untested archive is only a recovery hypothesis.

Write the recovery runbook before an incident

A short runbook prevents improvisation when a world is damaged. It should say who freezes player access, where backup credentials live, how to list recovery points, how to choose the point before the incident, where to restore it, which external snapshot belongs with it, and which acceptance checks must pass. Include rollback triggers and a communication template that explains the backup timestamp and the amount of activity that may be lost.

During recovery, stop the live service and preserve its files and logs for diagnosis. Restore the selected complete snapshot to a clean location, attach only the matching external data, validate privately, and switch traffic only after the acceptance pass succeeds. Do not repeatedly start a damaged world, mix current plugin databases with older files, or overwrite the only evidence. If the failure was caused by compromised credentials, rotate them and secure the host before reconnecting restored data.

Review the backup inventory alongside the safe update checklist at /blog/update-paper-minecraft-server-safely whenever Minecraft, Paper or critical plugins change. More server operations guides live at /blog. If measured archive and restore times outgrow the current storage, network or plan limits, compare options at /pricing after the retention policy and recovery target are clear. A modest schedule that restores reliably is more valuable than hundreds of snapshots nobody has tested.