Project Zomboid Automatic Server Backup: Schedule and Check It

To set up a Project Zomboid automatic server backup, choose a schedule that matches your group’s acceptable progress loss, then verify the resulting archive instead of trusting a single status line. The dedicated server exposes the BackupsPeriod option, but the setting alone does not prove a job ran or that its output can be restored. This guide walks through choosing an interval, checking the archive, and testing a copy without replacing your live world.

We tested the periodic-backup setting on one isolated Project Zomboid Build 42.21.0 server. It wrote a ZIP archive, and a copy extracted into a separate same-build server that started successfully. A deliberately broken backup path also produced a misleading “Backup made” message without a new archive. The test had no connected players, so it does not verify character or player-state recovery.

Choose a schedule by the progress your group can lose#

Set the schedule from a loss window, not from a magic interval. If your group can tolerate losing at most an hour of play, the interval must be shorter than that, and you still need to account for a backup that fails or starts late. A more active world may need more frequent copies and more storage; a quiet server may need less. Decide what you can afford to lose before touching the setting.

The official server-options reference lists BackupsPeriod as an integer option. It also lists BackupsCount, BackupsOnStart, BackupsOnVersionChange, and SaveWorldEveryMinutes as separate options. The reference identifies their names and types, but it does not establish your panel’s defaults, the exact retention behavior of your build, or whether an external scheduler is also active. Check the official server options reference for the current option spelling and confirm the live values in your own server profile.

For a hosted server, check how the provider exposes configuration and backup files before choosing a cadence. For a self-hosted server, identify the active service profile and persistent data directory first. Don’t copy a value from another server and assume it fits your world, storage, or build.

Set the periodic backup option in the active server profile#

The option name is BackupsPeriod; the spelling is case-sensitive in the configuration file. The exact way to edit the active profile depends on how you launch the dedicated server or on the control panel you use. Confirm the selected profile before editing it. A change to an old or inactive INI file will not schedule anything for the running world.

The INI key is written like this, with a value chosen for your build and acceptable loss window:

BackupsPeriod=1

The value 1 is shown because it produced an archive in our isolated test; it is not a universal interval recommendation. Verify the setting’s units and behavior against your current server version and panel before applying it. If your profile already has the key, update that entry instead of adding a duplicate.

1. Identify the active profile

   Match the running service’s server name/profile to the configuration file it reads. If your panel selects a profile, verify that selection in the panel before changing a file directly.

2. Record the current values

   Save a copy of the current profile through your normal configuration workflow. Record BackupsPeriod and any other backup-related values without assuming what their defaults mean.

3. Choose and apply an interval

   Set BackupsPeriod to the interval that your current build and profile expect, following the official options reference and your provider’s instructions. Do not paste an example value from another installation without checking its units and behavior.

4. Apply the change safely

   Use the documented restart or reload path for your setup. Tell players about the maintenance window, wait for the server to stop cleanly, apply the change, and confirm that the intended world starts again.

In our isolated test, BackupsPeriod=1 caused a periodic ZIP to appear after about a minute. That is an observation from one Build 42.21.0 setup, not a recommendation for production or a statement about the unit across every version and panel. Verify your build’s behavior before using any particular number. The official 42.21 Stable release notes are useful when checking the build context; do not assume that a world can be converted between incompatible versions or branches.

Find the actual output directory and confirm a fresh archive#

The output location follows the server’s active data directory and can vary by service account, mount, container, or panel. In our isolated test, the periodic archive appeared at Zomboid/backups/period/backup_1.zip beneath that server’s data root. Check the configured volume or panel file browser for your own instance; the test path is a clue, not a universal default.

After the next scheduled run, verify all of these before considering it a successful checkpoint:

1. A new archive exists in the expected periodic-backup location.
2. Its modification time is later than the schedule change or last successful run.
3. Its size is nonzero and plausible for your server.
4. The ZIP can be opened or tested with an archive tool.
5. The server log records the relevant backup attempt, and any errors are resolved.

The test server logged Start making backup. and then Backup made in 56 ms. It created backup_1.zip with 36 entries, including server settings, databases and multiplayer world data. The archive was about 5.8 MB in that test. Those details describe the test fixture; they are not a size target for your world.

If the timestamp does not advance, the archive is empty, or the ZIP cannot be opened, treat the run as failed. Check free space, file permissions, the configured data volume, and the server log before changing retention or deleting old files. For the broader map of which live folder belongs to a dedicated server, see how to find the active Project Zomboid server world.

Check the artifact instead of trusting one success message#

A log line can help locate a job, but it is not a complete health check. In our failure test, we replaced the periodic-backup directory in a disposable copy with a regular file so the server could not create the expected ZIP. The log contained a filesystem FileNotFoundException for backups/period/backup_1.zip and then still printed Backup made in 4 ms. No new periodic archive appeared.

That is one injected failure on one isolated Build 42.21.0 instance; it does not mean every server or build reports failures the same way. It does show why a scheduled job needs an output check. If you operate an external scheduler, check its last-run result and the output file separately. If your panel reports a backup job, confirm that its reported completion corresponds to a new archive and not a stale file.

Do not delete the last known good archive to make room before you have another verified copy. A backup job that reports success but leaves no new usable artifact is not a recovery point.

Rehearse a copy without touching the live world#

An archive that opens is a useful check, but it does not prove a complete recovery. Test a copy on a separate server or isolated environment with a compatible game build. Keep the live world stopped only if your normal copy process requires it; never extract over the production data directory as a test.

Our test archive extracted into a new, separate Build 42.21.0 server profile. That test server reached its ready state. We queried its player list and it contained zero players; there was no game client or populated character in the test world. The result confirms that this archive could be opened and that the copied world let this same-build server start. It does not prove player-character state, a modded world, cross-build loading, or recovery of a community’s real save.

Record the tested archive, game build, profile, server-ready result, and what you could not verify. If the test server starts an empty world, stop: confirm that the archive contains the intended save and that the test profile points at it before making any changes. Treat this as a successful same-build startup rehearsal, not proof of a complete restore; this page owns scheduling and checking job output, not destructive restoration or save conversion.

Keep a recovery copy separate from the scheduled output#

Periodic backups are useful only while the files remain readable and reachable. A copy on the same disk can disappear with that disk, and a full volume can prevent the next archive from being written. Decide whether your setup has a separate download, snapshot or offsite copy, then verify that copy independently. The server option’s existence does not establish where a provider stores copies or how long it retains them.

For Game Hosting servers, the documented Project Zomboid service includes three backup slots and lets you schedule, restore, download or lock a backup from the panel. That can reduce the work of maintaining a separate scheduler and checking where a panel exposes its copies. It does not remove the need to choose a useful cadence and verify a recovery copy for your own world. See the Project Zomboid hosting details if you would rather manage backups through a hosted panel than maintain the server yourself.

Before you finish, make sure the active profile is the one you changed, a recent archive exists, its timestamp and contents check out, disk space is adequate, and a separate compatible test reached the expected state. Keep the previous known-good copy until a newer one passes those checks.