Chapter 9.7: World State & Persistence

Home | << Previous: Player Spawning | Next: Performance Tuning >>

DayZ persistence keeps the world alive between restarts. Understanding how it works lets you manage bases, plan wipes, and avoid data corruption.

Table of Contents

• How Persistence Works
• The storage_1/ Directory
• globals.xml Persistence Parameters
• Territory Flag System
• Hoarder Items
• cfggameplay.json Persistence Settings
• Server Wipe Procedures
• Backup Strategy
• Common Mistakes

---

How Persistence Works

DayZ stores world state in the storage_1/ directory inside your server profile folder. The cycle is straightforward:

1. The server saves world state periodically (default every ~30 minutes) and on graceful shutdown.
2. On restart, the server reads storage_1/ and restores all persisted objects — vehicles, bases, tents, barrels, player inventories.
3. Items without persistence (most ground loot) are regenerated by the Central Economy on each restart.

If storage_1/ does not exist on startup, the server creates a fresh world with no player data and no built structures.

---

The storage_1/ Directory

Your server profile contains storage_1/ with these subdirectories and files:

Path	Contents
data/	Binary files holding world objects — base parts, placed items, vehicle positions
players/	Per-player .save files indexed by SteamID64. Each file stores position, inventory, health, status effects
snapshot/	World state snapshots used during save operations
events.bin / events.xy	Dynamic event state — tracks heli crash locations, convoy positions, and other spawned events

The data/ folder is the bulk of persistence. It contains serialized object data that the server reads on boot to reconstruct the world.

---

globals.xml Persistence Parameters

The file globals.xml (in your mission folder) controls cleanup timers and flag behavior. These are the persistence-relevant values:

<!-- Territory flag refresh -->
<var name="FlagRefreshFrequency" type="0" value="432000"/>      <!-- 5 days (seconds) -->
<var name="FlagRefreshMaxDuration" type="0" value="3456000"/>    <!-- 40 days (seconds) -->

<!-- Cleanup timers -->
<var name="CleanupLifetimeDefault" type="0" value="45"/>         <!-- Default cleanup (seconds) -->
<var name="CleanupLifetimeDeadPlayer" type="0" value="3600"/>    <!-- Dead player body: 1 hour -->
<var name="CleanupLifetimeDeadAnimal" type="0" value="1200"/>    <!-- Dead animal: 20 minutes -->
<var name="CleanupLifetimeDeadInfected" type="0" value="330"/>   <!-- Dead zombie: 5.5 minutes -->
<var name="CleanupLifetimeRuined" type="0" value="330"/>         <!-- Ruined item: 5.5 minutes -->

<!-- Cleanup behavior -->
<var name="CleanupLifetimeLimit" type="0" value="50"/>           <!-- Max items cleaned per cycle -->
<var name="CleanupAvoidance" type="0" value="100"/>              <!-- Skip cleanup within 100m of a player -->

The CleanupAvoidance value prevents the server from despawning objects near active players. If a dead body is within 100 meters of any player, it stays until the player moves away or the timer resets.

---

Territory Flag System

Territory flags are the core of base persistence in DayZ. Here is how the two key values interact:

• FlagRefreshFrequency (432000 seconds = 5 days) — How often you must interact with your flag to keep it active. Walk up to the flag and use the "Refresh" action.
• FlagRefreshMaxDuration (3456000 seconds = 40 days) — The maximum accumulated protection time. Each refresh adds up to FlagRefreshFrequency worth of time, but the total cannot exceed this cap.

When a flag's timer runs out:

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

If you lower FlagRefreshFrequency, players must visit their bases more often. If you raise FlagRefreshMaxDuration, bases survive longer between visits. Adjust both values together to match your server's play style.

---

Hoarder Items

In cfgspawnabletypes.xml, certain containers are tagged with <hoarder/>. This marks them as stash-capable items that count toward per-player storage limits in the Central Economy.

The vanilla hoarder items are:

Item	Type
Barrel_Blue, Barrel_Green, Barrel_Red, Barrel_Yellow	Storage barrels
CarTent, LargeTent, MediumTent, PartyTent	Tents
SeaChest	Underwater storage
SmallProtectorCase	Small lockable case
UndergroundStash	Buried stash
WoodenCrate	Craftable storage

Example from cfgspawnabletypes.xml:

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

The server tracks how many hoarder items each player has placed. When the limit is reached, new placements either fail or the oldest item despawns (depending on server configuration).

---

cfggameplay.json Persistence Settings

The file cfggameplay.json in your mission folder contains settings that affect base and container durability:

{
  "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. Items inside remain safe.

Setting both to true creates a PvE-friendly server where bases and storage are indestructible. Most PvP servers leave both at false.

---

Server Wipe Procedures

You have four types of wipe, each targeting a different part of storage_1/. Always stop the server before performing any wipe.

Full Wipe

Delete the entire storage_1/ folder. The server creates a fresh world on next boot. All bases, vehicles, tents, player data, and event state are gone.

Economy Wipe (Keep Players)

Delete storage_1/data/ but leave storage_1/players/ intact. Players keep their characters and inventories, but all placed objects (bases, tents, barrels, vehicles) are removed.

Player Wipe (Keep World)

Delete storage_1/players/. All player characters reset to fresh spawns. Bases and placed objects remain in the world.

Weather / Event Reset

Delete events.bin or events.xy from storage_1/. This resets dynamic event positions (heli crashes, convoys). The server generates new event locations on next boot.

---

Backup Strategy

Persistence data is irreplaceable once lost. Follow these practices:

• Back up while stopped. Copy the entire storage_1/ folder while the server is not running. Copying during runtime risks capturing a partial or corrupted state.
• Schedule backups before restarts. If you run automated restarts (every 4-6 hours), add a backup step to your restart script that copies storage_1/ before the server process starts.
• Keep multiple generations. Rotate backups so you have at least 3 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 cloud storage. A disk failure on the server machine takes your backups with it if they are on the same drive.

A minimal backup script (runs before server start):

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

---

Common Mistakes

These come up repeatedly in server admin communities:

Mistake	What Happens	Prevention
Deleting storage_1/ while the server is running	Data corruption. The server writes to files that no longer exist, causing crashes or partial state on next boot.	Always stop the server first.
Not backing up before a wipe	If you accidentally delete the wrong folder or the wipe goes wrong, there is no recovery.	Back up storage_1/ before every wipe.
Confusing weather reset with full wipe	Deleting events.xy only resets dynamic event positions. It does not reset loot, bases, or players.	Know which files control what (see the directory table above).
Flag not refreshed in time	After 40 days (FlagRefreshMaxDuration), the flag expires and all attached base parts become eligible for cleanup. Players lose their entire base.	Remind players of the refresh interval. Lower FlagRefreshMaxDuration on low-pop servers.
Editing globals.xml while server is running	Changes are not picked up until restart. Worse, the server may overwrite your edits on shutdown.	Edit config files only while the server is stopped.

---

Home | << Previous: Player Spawning | Next: Performance Tuning >>