World State & Persistence

Summary: DayZ keeps the world alive between restarts by writing selected objects — bases, tents, barrels, vehicles, and player characters — into the storage_1/ folder inside the server profile. This chapter is the canonical reference for what lives in storage_1/, how the save cycle works, the four kinds of server wipe, and a backup strategy that survives disk failure and botched wipes. The economy-side cleanup timers referenced here are documented in full in Loot Economy Deep Dive; the surrounding mission and server folder layout is in Directory Structure & Mission Folder.

---

Table of Contents

• How Persistence Works
• What Persists and What Does Not
• The storage_1/ Directory
• When the Server Saves
• Territory Flags and Base Decay
• Hoarder Containers
• cfggameplay.json Base and Container Damage
• Cleanup Timers
• Server Wipe Procedures
• Backup Strategy
• Common Mistakes

---

How Persistence Works

DayZ stores world state in the storage_1/ directory inside your mission folder (for example, mpmissions/dayzOffline.chernarusplus/storage_1/). The cycle is straightforward:

1. The server writes world state to storage_1/ on a recurring engine timer and again on graceful shutdown.
2. On restart, the server reads storage_1/ and reconstructs every persisted object — vehicles, bases, tents, barrels, and player characters — at the position and state it held when last saved.
3. Objects that do not persist (most ground loot) are regenerated by the Central Economy (CE) on each boot rather than restored from disk.

If storage_1/ does not exist on startup, the server creates a fresh world: no built structures, no stored vehicles, and every connecting player spawns as a new character.

---

What Persists and What Does Not

Persistence is not all-or-nothing. The economy.xml toggles (documented in Directory Structure & Mission Folder) decide which subsystems save their state. In the vanilla configuration:

Category	Persists?	Notes
Player characters	Yes	Position, inventory, health, and status effects are saved per character.
Base-building parts	Yes	Walls, gates, watchtowers, and fences, as long as their territory flag is active.
Deployed storage	Yes	Tents, barrels, sea chests, wooden crates, and buried stashes, plus their contents.
Vehicles	Yes	Position, attachments, and cargo.
Dynamic events	Yes (vanilla)	Helicopter crashes, convoys, and similar events save their spawned state into data/.
Ground loot	No	Regenerated by the CE each boot; individual items are never written to disk.
Infected and animals	No	Respawned by the CE; their positions are not saved.
Weather	No	Driven by cfgweather.xml and re-simulated from that config on every boot — it is not stored in storage_1/.

The distinction matters when you plan a wipe: deleting persistence removes only the "Yes" rows. Loot, infected, animals, and weather always regenerate regardless of what you delete.

---

The storage_1/ Directory

storage_1/ holds the persistent state and contains these entries:

Path	Contents
data/	The bulk of persistence: serialized world objects — base-building parts, deployed storage, vehicle positions, and saved dynamic-event state. Read on boot to reconstruct the world.
players/	Binary character records, one per character. Each record holds position, inventory, health, and status effects. These are opaque files written only by the server process — never human-readable and never safe to hand-edit.
spawnpoints.bin	Binary spawn-point data used by the persistence system.
backup/	Automatic engine-side copies of persistence data, rotated by the server. This is a convenience, not a substitute for your own external backups.

The data/ folder is where base building and deployed storage live; players/ is where characters live. A wipe targets one or both, depending on what you want to reset (see Server Wipe Procedures).

The character records in players/ are keyed internally by the player's persistent identity, not stored as readable per-SteamID files. Treat the folder as an opaque database: back it up or delete it wholesale, but do not open or edit individual records.

For the full mission and server directory layout surrounding storage_1/, see Directory Structure & Mission Folder.

---

When the Server Saves

The server writes persistence in two situations:

• On a recurring timer. The engine flushes world and character state periodically while the server runs. This interval is managed by the engine itself; there is no mission-config value that sets it, so do not assume a precise figure when planning maintenance — treat a save as something that can happen at any time the server is up.
• On graceful shutdown. A clean stop (an orderly shutdown, not a crash or a killed process) triggers a final save so the world reflects its exact last state.

Two consequences follow from this:

1. A hard crash loses everything since the last timed save. Whatever players built, looted, or moved after the previous flush is gone. This is why scheduled, graceful restarts matter — they force a save.
2. Never copy or delete storage_1/ while the server is running. A save can land mid-copy, giving you a half-written backup, or mid-delete, corrupting the live world. Always stop the server first (see Backup Strategy).

---

Territory Flags and Base Decay

Territory flags are the core of base persistence. Two globals.xml values govern how long a base survives without attention:

• FlagRefreshFrequency (vanilla 432000 seconds = 5 days) — how often a player must interact with the flag ("Refresh" action) to keep the territory active.
• FlagRefreshMaxDuration (vanilla 3456000 seconds = 40 days) — the maximum accumulated protection time. Each refresh tops the timer back up, but the total can never exceed this cap.

When a flag's timer expires:

1. The flag itself becomes eligible for cleanup.
2. The base-building parts attached to that territory lose their persistence protection.
3. On the next cleanup cycle, the unprotected parts begin despawning.

Lowering FlagRefreshFrequency forces more frequent base visits; lowering FlagRefreshMaxDuration wipes abandoned bases sooner. Adjust both together to match your server's pace. These two variables, along with the full globals.xml parameter set, are documented in Loot Economy Deep Dive.

---

Hoarder Containers

In cfgspawnabletypes.xml, storage containers are tagged with <hoarder/>:

<type name="SeaChest">
    <hoarder />
</type>

In vanilla, the hoarder containers are the four barrel colors, all tents, SeaChest, SmallProtectorCase, WoodenCrate, and UndergroundStash.

The tag has one meaning, and it is easy to get wrong: it does not impose a per-player limit on how many containers a player may place. It controls whether items stashed inside the container still count toward the Central Economy's world population. An item inside a hoarder container is counted by the CE only if that item's types.xml entry sets count_in_hoarder="1". For every item where that flag is 0, stashed copies silently leave the economy — the CE stops seeing them and keeps spawning fresh copies into the world.

This is why high-value loot squirreled away in barrels and buried stashes can effectively multiply on a server: with count_in_hoarder="0", ten stashed AKMs do not suppress a single new AKM spawn. The counting mechanics, and how to set the flag correctly, are covered in Loot Economy Deep Dive.

---

cfggameplay.json Base and Container Damage

cfggameplay.json in the mission folder controls whether bases and storage can be damaged:

{
  "GeneralData": {
    "disableBaseDamage": false,
    "disableContainerDamage": false
  }
}

Setting	Default	Effect
disableBaseDamage	false	When true, base-building parts (walls, gates, watchtowers) cannot be damaged. This effectively disables raiding.
disableContainerDamage	false	When true, storage containers (tents, barrels, crates) cannot take damage, so items inside stay safe.

Setting both to true produces a PvE-friendly server where bases and storage are indestructible. Most PvP servers leave both at false. Neither setting affects whether objects persist — an indestructible base still decays if its territory flag expires.

---

Cleanup Timers

Persistence works alongside the CE's cleanup system, which removes dead bodies, ruined items, and untouched loot on a timer. The relevant globals.xml values (dead-player body lifetime, ruined-item lifetime, cleanup avoidance radius, and so on) are not unique to persistence — they belong to the economy and are documented once, in full, in Loot Economy Deep Dive.

The one interaction worth calling out here: CleanupAvoidance (vanilla 100 meters) stops the CE from despawning objects near active players. A dead body or expired item within that radius of any player is protected until the player leaves, so cleanup timers are a floor, not an exact schedule.

---

Server Wipe Procedures

There are four practical ways to reset persistence, each targeting a different slice of the world. Always stop the server before any of them — deleting persistence files under a running server corrupts state and can crash the next boot.

Full Wipe (fresh world)

Stop the server and delete the entire storage_1/ folder. On next boot the server creates a clean world: no bases, no vehicles, no deployed storage, and every character reset to a fresh spawn. The CE repopulates loot from scratch.

Object Wipe (keep characters)

Stop the server and delete storage_1/data/ while leaving storage_1/players/ intact. Players keep their characters and inventories, but every placed object — bases, tents, barrels, vehicles, and saved dynamic-event state — is removed. Use this to clear a cluttered map without punishing players for their gear.

Character Wipe (keep the world)

Stop the server and delete storage_1/players/. Every character resets to a fresh spawn, but bases, storage, and vehicles remain in the world. Use this for a "reset the population, keep the builds" wipe.

Loot Re-randomize (no persistence deletion)

If you only want to shuffle ground loot after editing economy files — not wipe anything persistent — set RestartSpawn to 1 in globals.xml for one restart, then set it back to 0. This re-randomizes loot positions without touching storage_1/. This is an economy operation, detailed in Loot Economy Deep Dive.

There is no separate "weather wipe." Weather is regenerated from cfgweather.xml on every boot and is never stored in storage_1/. Saved dynamic events (helicopter crashes and similar) live inside data/, so an Object Wipe already clears them.

---

Backup Strategy

Persistence data is irreplaceable once lost. Follow these practices:

• Back up while stopped. Copy the entire storage_1/ folder only when the server is not running. Copying during runtime risks catching a mid-save, partial, or corrupted state.
• Schedule backups before restarts. If you run automated restarts, add a step that copies storage_1/ before the server process starts. Because a scheduled restart forces a graceful save, the copy you take right before boot reflects the most recent clean state.
• Keep multiple generations. Rotate backups so you always have at least three recent copies. If your latest backup is corrupted, you can roll back to an earlier one.
• Store off-machine. Copy backups to a separate drive or to cloud storage. A disk failure that takes the server also takes any backup sitting on the same disk.
• Do not rely on storage_1/backup/ alone. The engine-side backup folder is a convenience that lives on the same disk as the live data. It is not a disaster-recovery plan.

A minimal backup step, run before the server starts:

BACKUP_DIR="/path/to/backups/$(date +%Y%m%d_%H%M%S)"
mkdir -p "$BACKUP_DIR"
cp -r /path/to/mission/storage_1 "$BACKUP_DIR/"

---

Common Mistakes

These come up repeatedly in server-admin communities:

Mistake	What Happens	Prevention
Deleting or copying storage_1/ while the server runs	A timed save can land mid-operation, producing a corrupted world or a half-written backup.	Always stop the server first.
Relying on a hard crash to preserve progress	Everything built or looted since the last timed save is lost; only graceful shutdowns force a final save.	Use scheduled, graceful restarts.
Not backing up before a wipe	If you delete the wrong folder, there is no recovery.	Back up storage_1/ before every wipe.
Expecting a "weather wipe" file	Weather is config-driven (cfgweather.xml) and regenerates each boot — there is no persistence file to delete.	Edit cfgweather.xml to change weather; leave storage_1/ alone.
Assuming <hoarder/> limits placement	The tag governs CE counting via count_in_hoarder, not a per-player cap on containers.	Read the counting rules in Loot Economy Deep Dive.
Flag not refreshed in time	After FlagRefreshMaxDuration the territory expires and all attached base parts become eligible for cleanup, so players lose the base.	Remind players of the refresh interval; lower FlagRefreshMaxDuration on low-pop servers.
Editing globals.xml or cfggameplay.json while the server runs	Changes are not picked up until restart, and the server may overwrite your edits on its next save.	Edit config files only while the server is stopped.