Quick Answer
A backup is a five-field packet, not a copied folder: the live Zomboid save folder (Zomboid/Saves/Multiplayer/<server>), the server configuration (INI + SandboxVars + spawn files), the Workshop and Mods records (every ID), the copy date, and a restore test on a separate profile. Stop the server before copying — files shift mid-write. And a backup isn't real until you've loaded it: an untested copy is a hope. The 42.21 patch notes reinforce the habit: existing saves 'should not be affected', but back up manually before testing a new branch anyway.
Table of Contents
Versioned restore packet
A useful backup is more than a copied folder. Capture the live folder, the world, the configuration, the mod IDs, a timestamp — and prove it with a dated restore.
| Packet field | Capture | Passes when |
|---|---|---|
| Live folder | Zomboid/Saves/<mode>/<world> and the active profile | The copy's source is identifiable |
| Save state | Server stopped, world name, last good join | The copy has a known point in time |
| Configuration | INI, SandboxVars, spawn files, server name | The profile can be recreated |
| Mods | WorkshopItems, Mods, Map, dependencies | The restore won't omit required IDs |
| Dated restore | External copy plus a separate test profile | It loads without touching live files |
When to take a backup, on a schedule you can keep
The packet is always the same five fields — the only variable is timing. Each row is a moment where the recorded failure reports say a backup would have saved the evening.
| Trigger | Why this moment | What the packet must include |
|---|---|---|
| Before a game update | The 42.21 notes: saves 'should not be affected' — and the manual backup recommendation stands anyway | All five fields — a version change touches save format, config, and mods simultaneously |
| Before a mod batch | The patch-day reports (launch failure from one mod, the 127-mod symptom pile) all lacked a clean rollback point | The mod records matter most here: every Workshop ID, so the restore re-downloads the exact set |
| Before settings surgery | World-rule edits are partly generational — a bad edit can't be judged until the world loads | INI + SandboxVars + world save together; they only restore as a set |
| Before admin or whitelist changes | Privilege edits touch profile and account data | The configuration fields, dated — your undo button for access-control mistakes |
| On a calendar | Servers fail on their own schedule, not yours — disk, provider, host machine | Whatever cadence you'll actually keep: a weekly tested packet beats a daily ritual nobody runs |
Restore, the part nobody practices
The backup reference treats a separate restore check as a distinct field — because the restore is where backups turn out to be hopes rather than copies.
The restore protocol: copy the packet to a test profile (never over the live one), start the server on that profile, and join it once. That single join proves four things at once — the save loads, the configuration matches it, the mod records re-download the right set (WorkshopItems, Mods, Map, dependencies — four separate fields to compare), and the date on the packet corresponds to a state you'd actually want to return to. An untested backup proves none of them.
Timing discipline comes from the field list: the server must be stopped cleanly before the copy, so files aren't shifting mid-write — a backup made on a running server is a backup of whatever fraction of the world was on disk at that moment, which is a corrupted world with extra steps. And the copy lives outside the live directory, dated, because 'backup_2' and 'backup_final' are not dates and restore-by-guessing is how good saves die.
The patch-day application is the habit's payoff. The 42.21 patch notes say existing 42.20.4 saves should not be affected — but recommend manually backing up an existing save before testing it on the new branch anyway. That's the pattern: official 'should be fine' plus your own dated copy equals a testable update; official 'should be fine' alone equals a prayer with a version number. Before every branch change, every mod batch, and every settings surgery, the packet is the same five fields.
Reference data
A backup is only complete when the live save folder, configuration, mod list, date, and restore result are all recorded. A copied folder without a dated restore check is not a verified backup.
| Backup field | What to capture | Proof |
|---|---|---|
| Save | Active live folder: Zomboid/Saves/<mode>/<world> | The source and world name are identifiable |
| Configuration | Server profile and sandbox settings | The active profile name is recorded |
| Mods | WorkshopItems, Mods, Map, and dependencies | The list can be compared during restore |
| Timestamp | Last known good join and copy date | The restore point has a known state |
| Restore | A separate test profile | A dated restore loads without overwriting the live server |
FAQ
What files do I need to back up a Project Zomboid server?
Five fields: the live save folder (Zomboid/Saves/Multiplayer/<server>), the configuration (servertest.ini, SandboxVars, the two spawn files), the Workshop and Mods records with every ID, the copy date, and a restore test. A save without its matching configuration is half a server; a backup without mod IDs restores to a world that can't load its own content.
Can I back up a server while it's running?
You can copy files, but you shouldn't: a running server is mid-write, so the copy captures whatever fraction of the world was on disk at that moment. Stop the server cleanly first — the backup reference lists 'server stopped' as a save-state field, not a courtesy.
How do I test a backup without risking the live server?
Restore to a separate test profile: copy the packet there, start the server on that profile, join once. That join proves the save loads, the configuration matches, and the mod fields re-download the right set — without touching live files. 'It loads' is the only passing grade; an untested backup is a hope.
Do I need to back up before every game update?
Yes. The official 42.21 patch notes say existing 42.20.4 saves should not be affected — and still recommend manually backing up before testing on the new branch. The pattern generalizes: official 'should be fine' plus your dated copy equals a testable update; 'should be fine' alone is a prayer with a version number.