DayZ server wipes: full and partial resets

Everything a DayZ world remembers between restarts lives in one folder: storage_<instanceId> inside the mission folder, so mpmissions/dayzOffline.chernarusplus/storage_1/ on a default Chernarus server. Characters are in players.db in that folder; tents, bases, stashes, vehicles and the economy's own state are in the binary files under data/. A full wipe is deleting the folder's contents with the server stopped. A character-only wipe is deleting players.db. A world wipe that keeps characters is deleting data/ and leaving players.db. Everything else - base decay, flag timers, what survives a restart at all - is set in a handful of XML files, and getting those right means you need fewer wipes in the first place.

This post covers persistence end to end. Loot spawning itself is in the DayZ types.xml guide, and the config key that selects the storage folder is explained in serverDZ.cfg explained.

What persists and where#

The persistence folder is chosen by instanceId in serverDZ.cfg: instance 1 reads and writes storage_1, instance 2 storage_2, always inside the mission folder named by template. Change either value and the server starts a fresh world - the old one is still on disk, simply not loaded.

Inside it you will typically find:

Treat the list of .bin files as indicative rather than fixed. Bohemia has changed how persistence is split between files over the game's life, and the names on your server are the ones that matter. List the folder before you delete anything.

players.db is an SQLite database. That matters for two reasons: it can be opened with any SQLite browser if you ever need to inspect or remove a single character, and it must never be copied or edited while the server is running, because the copy may be taken mid-write.

The mission files themselves - types.xml, events.xml, cfgeconomycore.xml and the rest - are configuration, not persistence. Editing them does not wipe anything. Deleting storage_1 does not reset them. Keeping that line clear is most of the job.

What decides what gets saved#

Which categories are saved and loaded at all is set in db/economy.xml. The vanilla file looks like this:

<economy>    <dynamic init="1" load="1" respawn="1" save="1"/>    <animals init="1" load="0" respawn="1" save="0"/>    <zombies init="1" load="0" respawn="1" save="0"/>    <vehicles init="1" load="1" respawn="1" save="1"/>    <randoms init="0" load="0" respawn="1" save="0"/>    <custom init="0" load="0" respawn="0" save="0"/>    <building init="1" load="1" respawn="0" save="1"/>    <player init="1" load="1" respawn="1" save="1"/></economy>

Animals and infected are not saved: they respawn fresh at every start, which is why restarts clear zombie trains. Dynamic objects, vehicles, buildings and players are. Compare your file with this one before you start debugging persistence - a mod or an old guide may have changed a flag, and load="0" on player makes every character start fresh at each restart while looking like a bug.

Those flags can be used for a deliberate one-off reset as well: start once with load="0" on a category, let the server write a clean state, then set it back. It works, but it is easy to forget the second half, and deleting files with a backup in hand is more predictable. Keep the flags at their vanilla values unless you have a specific reason.

Lifetimes, decay and territory flags#

Persistent does not mean permanent. Every object has a lifetime, and the cleanup system removes anything untouched for that long. That is how abandoned bases disappear without a wipe.

• Items and containers. Each type's lifetime in types.xml, in seconds, is how long it survives without interaction. Tents, barrels and buried stashes have long lifetimes in the vanilla files, on the order of weeks. Interacting with a container - opening it, moving items in it - resets its timer.
• Base parts and territory flags. A raised territory flag keeps base parts within its radius alive. The flag has to be refreshed by a player: FlagRefreshFrequency and FlagRefreshMaxDuration in db/globals.xml set how often a refresh is possible and how long a fully raised flag protects the base.
• Global cleanup. globals.xml also holds CleanupLifetimeDefault, CleanupLifetimeDeadPlayer, CleanupLifetimeDeadInfected, CleanupLifetimeRuined and similar values for things without their own lifetime.

<var name="FlagRefreshFrequency" type="0" value="432000"/><var name="FlagRefreshMaxDuration" type="0" value="3456000"/>

With those vanilla values a flag can be refreshed every five days and holds a base for up to forty. Raise them and abandoned bases linger, filling the map and the persistence files; lower them and active players lose bases when they take a holiday. Most servers leave them alone. If yours runs on a monthly wipe cycle, the decay system matters less; if it never wipes, it is the only thing keeping the world from silting up.

When the world is actually saved#

DayZ writes persistence periodically while running and once more on a clean shutdown. A process that is killed - a hard stop, a crash, the machine losing power - loses whatever changed since the last write, and in the worst case leaves a file half-written.

That has three practical consequences:

1. Always stop cleanly. Use the panel's Stop or Restart, #shutdown through RCon, or a shutdown message in db/messages.xml. On RE:NODE the Restart button sends a clean stop, so persistence is written before the process exits. A kill is for a server that has already hung.
2. Keep `storageAutoFix = 1;` in serverDZ.cfg. It lets the server repair a damaged file at start instead of refusing it. Without it, one bad shutdown can leave a server that will not boot.
3. Watch memory. If a server reaches its memory limit, it is stopped by force - on RE:NODE the container is stopped and restarted clean rather than left to swap, which is the right behaviour but is still not a clean save. A server that keeps hitting its limit is losing progress each time. Why your game server keeps restarting covers how to tell.

The kinds of wipe#

Every wipe follows the same safety routine: announce it, stop the server cleanly, take a backup, then delete. The difference is what you delete.

Full wipe

The standard monthly or seasonal reset. Stop the server, back up, delete the contents of storage_1 (or rename the folder, which doubles as a quick local backup), start. The server creates fresh storage, the economy populates the map from scratch, and every player starts as a fresh spawn. Mission files, serverDZ.cfg, BattlEye bans and admin mod configuration all live elsewhere and are untouched.

The first start after a full wipe takes longer than usual while the economy spawns the whole map's loot. Give it time before judging whether loot looks right.

Character-only wipe

Deleting players.db resets every character to a fresh spawn while every tent, base and vehicle stays where it is. This is what admins use after a duplication exploit has flooded inventories, or at the start of a new season on a server where bases are the long-term investment. Expect bases to be raided quickly by fresh characters who know where they are - announce it.

World wipe, characters kept

Delete the contents of data/ and keep players.db. The world resets - bases, stashes, vehicles, the economy's state - while characters keep what they were carrying. Useful after a broken mod left the world full of invalid objects, or when you want to reset bases without punishing players for their gear. Characters load at their saved positions, which is fine on the same map.

Removing one player

There are two routes. If your admin tooling can delete or reset a character, use it, with the player offline. Otherwise, stop the server, back up, and open players.db in an SQLite browser; characters are stored with an identifier for the player, and removing that row resets them. Do this only with a backup in hand, and only with the server stopped.

Vehicles only

There is no supported "vehicles only" wipe. On builds that keep vehicles in their own file, deleting it with the server stopped resets them to fresh spawns. On builds where vehicles live with other event objects, you will reset crash sites and other events too. Test on a copy of the folder first, as with any partial wipe that depends on file names.

When a wipe is required#

Most changes do not need one. Changing nominals, lifetimes, time of day or almost anything in serverDZ.cfg takes effect at the next restart with the world intact.

Changes that do need a wipe, or at least a careful one:

• A different map or mission. A new mission has its own storage anyway - see running a community map.
• Removing a mod that adds persistent objects. Base-building mods, storage mods and vehicle mods leave objects in persistence that no longer have a class. The server may log errors, delete them, or refuse to start. Remove such a mod at a wipe.
• Large framework changes. Adding or removing something like DayZ Expansion changes what the world contains; its own guidance is to start on clean storage. See the DayZ Expansion guide.
• Corruption that `storageAutoFix` cannot repair. If the server will not start and the logs point at persistence, the choice is a backup or a wipe.

A game update rarely requires a wipe on its own, though Bohemia has occasionally recommended one after major changes. Read the patch notes before deciding.

Backups and a wipe schedule#

A wipe deletes data, so the backup before it is not optional - it is the undo button for the day you discover a bug in the new setup, or a player proves their base vanished because of your mistake.

What to back up:

• The whole storage_<n> folder, together with the mission folder it belongs to. Restoring one without the other gives you persistence that disagrees with the economy.
• serverDZ.cfg, the BattlEye folder with bans.txt, and admin mod configuration in the profiles folder.
• Not the server binaries or Workshop mods - those can be downloaded again.

Back up with the server stopped, or at least straight after a clean restart; a copy of players.db taken mid-write may not open. On RE:NODE, backup slots come with every DayZ plan, are stored off the machine they protect and restore with a button, and the Schedules tab can chain a warning, a clean restart and a backup on a cron expression - scheduled tasks worth having has patterns for that. And restore one occasionally to prove it works: testing a restore before you need it explains how.

For the schedule itself, communities settle on one of three rhythms:

Whichever you choose, publish it and keep it. A wipe announced a week ahead is a fresh start; an unannounced one is how communities lose their regulars. The same principles from another game are in Rust wipes without losing your players.

Troubleshooting#

The world reset on its own after an update. instanceId or template changed, so the server is reading a different storage folder. The old one is still there; put the value back.

Characters reset at every restart. load or save is 0 for player in economy.xml, or players.db cannot be written. Check the flags, then the log.

The server will not start after a crash. A damaged persistence file. Confirm storageAutoFix = 1;, read the .RPT log for the file it names, and restore that storage folder from a backup if the fix fails.

Bases disappeared that should have survived. The territory flag was not refreshed within FlagRefreshMaxDuration, or the items had short lifetimes. Check globals.xml and the lifetime of the relevant types.

Start-up takes several minutes. Very large persistence. Lower lifetimes on junk, keep decay working, and plan a wipe.

A partial wipe broke something. Restore the backup you took before it - and next time, test the deletion on a copy.

FAQ#

Does editing types.xml wipe my DayZ server?

No. The economy files are configuration. Persistence is in the storage folder and is only reset by deleting it, changing instanceId, or switching mission.

How do I wipe characters but keep bases?

Stop the server, take a backup, and delete players.db from storage_<instanceId>. Every character becomes a fresh spawn and the world stays as it was.

How do I reset the world but let players keep their gear?

Stop the server, back up, and delete the contents of data/ in the storage folder while leaving players.db. Bases, stashes and vehicles reset; characters load with their inventory.

How long do bases last without a wipe?

As long as their territory flag is refreshed. In vanilla globals.xml a fully raised flag protects the base for up to forty days, and it can be refreshed every five. Unprotected objects follow their own lifetime values.

Can I undo a wipe?

Only from a backup taken before it. That is why the backup is part of the wipe routine, not an optional extra.

Why does the first start after a wipe take so long?

The economy is spawning the whole map's loot, vehicles and events from scratch. Later starts load saved state instead and are quicker.