How to back up, restore and move a DayZ server
Your mission XML can survive a failed mod change while the players’ bases are gone. Those files define the economy; they do not replace saved characters, containers or the world. A useful recovery copy needs the configuration, saved state and any data your mods keep elsewhere.
Find the files this server actually uses
Section titled “Find the files this server actually uses”Start with the running service’s startup settings. Bohemia’s server configuration reference documents how it selects the config, mission, profiles path, instance identifier and custom storage root. An old mission folder sitting beside the active one is easy to back up by mistake.
Record these items in the recovery inventory:
| Item | What to check |
|---|---|
| Active mission | Include scripts, economy edits, custom registrations and the files they reference. |
| Persistence/storage | Resolve the actual location of the saved world and player state. |
| Profiles and mod-owned files | Check each mod’s settings and persistent-data paths. Some sit outside the mission. |
| Config and startup settings | Retain the selected server config, parameters and instance ID. |
| Mods, dependencies and keys | Record the installed versions needed to load the saved content. |
| Access settings | Include applicable admin, ban, whitelist and BattlEye/RCON settings. Protect secrets. |
| External databases | Use the database or mod author’s supported export procedure. Check its coverage separately. |
For example, a PC installation may use mpmissions/dayzOffline.chernarusplus/storage_1/. Custom missions, instance IDs or -storage can change that path. Check your service instead of treating the example as its directory.
Check inside the backup
Section titled “Check inside the backup”The VYKIX backup guide explains the file selection and backup summary. Files at 0 means no paths are selected. A higher count tells you that paths are selected; you still need to check whether they cover the mission, persistence and mod data in your inventory.
Inspect the stored paths, capture time and archive size. Keep another copy outside the hosting service, where failure of the live server’s storage cannot also remove it.
A .bak beside an edited config protects that file. A settings export may also omit saved world data. For example, the DayZ Server Manager export source selects config and economy files without persistence storage or profiles. Check the archive against your inventory before relying on it for player recovery.
Choose an interval based on the progress you can afford to lose, and retain earlier recovery points. If a mod already deleted objects, a new backup preserves the damaged state. Keep it for investigation, but look for an intact copy from before the incident.
Capture a consistent copy
Section titled “Capture a consistent copy”- Pause scheduled restarts, updates and any watchdog that could relaunch the server. Give players a maintenance window and finish the server’s supported normal shutdown.
- Confirm that the process has stopped writing. Keep the incident logs if something failed.
- Copy the inventoried mission, persistence and mod-owned data into one dated set. Export external databases through their supported method.
- Leave that source copy intact. Extract a duplicate and compare its paths, file sizes or hashes with the captured files.
- Save the build, mod versions, capture time and contents with the copy. Store passwords and other secrets privately.
Matching hashes show that files transferred intact. They cannot tell you whether DayZ will load them. Copying a running server also risks combining files from different save moments. If shutdown is unavailable, use a method your service supports for a consistent application backup; do not assume an ordinary live copy provides one.
Test the world, not just startup
Section titled “Test the world, not just startup”Use a separate instance with its own storage, the intended game branch, terrain and required mod versions. Restore into the paths that instance selects, then check file permissions.
Review the RPT and script logs on startup. Then join and inspect known state: a character’s location and inventory, a base or container, a vehicle and important mod progress. Write those checks down before the restore. An empty world that starts successfully would otherwise look like a pass.
Stop if you see persistence errors, missing classes or an unexpected fresh world. Investigate paths and compatibility against the untouched recovery copy. Repeated production starts are not a recovery method.
Check storageAutoFix before a recovery test. Bohemia documents that enabling it can replace corrupt persistence files with empty ones. Keep the untouched archive and inspect the storage messages in the RPT; a server that starts after replacing damaged data has not recovered that data.
Find why vehicles or tents disappeared after a restart
Section titled “Find why vehicles or tents disappeared after a restart”Pause automatic restarts and updates, stop the server and preserve its current storage, configuration and logs. Record which objects disappeared, where they were and when someone last saw them. Keep backups from before the incident; repeated starts can make the original failure harder to investigate.
Compare the last working startup with the first affected one. The symptom determines where to look:
| What you find | Check next |
|---|---|
| The whole world looks fresh | Compare the active mission, instanceId, any -storage argument and the RPT’s selected storage directory with the earlier startup. Check that the intended saved files are still present and readable. Keep both directories if the service selected a new location. |
| Saved objects fail to return, although the expected storage is selected | Inspect the relevant entity group’s load and save switches in economy.xml. Bohemia defines these as reading and writing saved state. Compare them with your last working configuration before changing them. |
| The loss followed an economy edit | Compare types.xml, registered overrides and economy.xml with the working copy. Check affected classnames and parse the edited XML. Restore the specific failed edit; replacing the complete file with a stock download can discard other custom settings. |
| Only particular objects disappear over time | Check their definitions, lifetime, damage and the applicable cleanup settings. Record when they vanish relative to the restart. Finding an object missing after reconnecting doesn’t establish when it was removed. |
| The RPT reports corrupt persistence or replacement with empty data | Preserve the affected files and check storageAutoFix. Its documented recovery behavior can replace corrupt files with empty ones. Reopening successfully does not prove the old objects were recovered. |
| Only modded objects or parked vehicles are missing | Check that the required classes still load and compare the installed mod versions with the backup. Include separately stored garage or other mod records in the investigation, using the sections below and that release’s author instructions. |
For a separate test instance, the documented log_ce_vehicle and log_ce_lootcleanup options can provide vehicle and cleanup diagnostics. If logging was disabled during the incident, enabling it now won’t produce the missing historical entries. Keep the original world intact while collecting a new test log.
After correcting a configuration fault, restore a duplicate of the appropriate recovery set and check known objects before and after a normal restart. Repairing an XML file cannot recreate a saved object that has already been lost. Reopen only after the restored state matches the recovery point you intend to use.
This checklist used AI-assisted research and drafting on 8 October 2026, using Bohemia’s storage configuration, persistence switches and economy diagnostics. These checks have not been tested against a reproduced vehicle or tent disappearance.
Restore or move the live server
Section titled “Restore or move the live server”Before a live restore, preserve its current state. Select the recovery set by time and contents, stop the service, then follow the panel’s restore confirmation. Wait for completion and repeat the startup and player checks. Retain the replaced state until the result is accepted.
For a provider move, rehearse the destination first. After players leave the source, take a final stopped copy and keep the source stopped during cutover. Use the destination’s assigned addresses, ports and paths. If it fails the checks, stop it before returning to the retained source, and tell players which saved point will reopen.
Game or mod compatibility requirements can still force a reset. No file-transfer procedure guarantees a move without a wipe for every installation.
Wipe a self-managed DayZ server
Section titled “Wipe a self-managed DayZ server”To start the active mission with fresh world and character data, stop the server and move its actual storage directory out of the path DayZ loads. Keep a complete backup first. This resets the saved progress in that directory for every player; it is not a way to repair an XML typo or reset one character.
This procedure is for a self-managed PC instance whose files and startup process you control. For VXPanel, use the wipe controls only after confirming their exact scope with support. The names Full Wipe, Persistence Only and Player Database Only do not establish which mod files or backups the service removes.
Check what the reset includes
Section titled “Check what the reset includes”Use the configuration and startup arguments recorded above. In the RPT, find [StorageDirs] :: Selected storage directory: when the build prints it. Compare that path with the active mission, instanceId and any -storage override before touching a directory. A panel URL or a folder named storage_1 elsewhere is not proof that it belongs to this instance.
The retained vanilla DayZ 1.29 storage inspected for this guide contains:
| Item | Role in this procedure |
|---|---|
data/ |
Saved Central Economy/world files. The restore logs identify types, events, dynamic objects, buildings and vehicles here. |
players.db |
The character database beside data/. Keep the complete file set, including any database companions your installation has. |
backup/ and other storage files |
Retain these with the directory. Don’t combine old recovery files with a newly created world. |
| Mission XML/scripts, server configuration and mods outside storage | Kept by this storage-only operation. It doesn’t reinstall the server or return its settings to defaults. |
| Profiles, mod account files and external databases outside storage | Kept unless you perform a separate, documented reset. Banking and garage records may still refer to progress from the old world. |
Bohemia’s storage configuration defines the instance and storage selection. Its economy reference distinguishes the initial start without storage from loading saved state. Confirm your installed layout; the table is not a promise that every mod stores data in these locations.
Create and check the fresh world
Section titled “Create and check the fresh world”- Announce the reset and pause restart/update automation. Shut down normally and confirm the game process has exited.
- Capture and verify the complete recovery set described above, including mod data outside storage. Keep the game and mod versions with it.
- Rename the exact active storage directory to a dated name such as
storage_1.pre-wipe-2026-10-08, using your actual directory name. Leave the original path absent. Keep the renamed directory intact; don’t rename the mission or remove its economy XML. - Start the same instance with the same mission, config and storage selection. Check the selected storage path, creation of new storage and startup logs. Stop if DayZ loads the old directory, reports persistence errors or selects another instance’s data.
- Join with a test account that had a character before the reset. Confirm a fresh character and check that a known old base, container and vehicle are absent. Also check the new economy and any mod-owned balances or records against the reset you intended.
- Stop normally, restart and reconnect. Confirm that progress made in the new world survives this restart before reopening to players.
Keep the server closed if those results disagree with the intended scope. An unchanged mod bank balance can mean its database lives outside vanilla storage; it doesn’t mean the storage rename failed.
Undo the reset
Section titled “Undo the reset”Stop the instance. Preserve the newly created storage under a different dated name, then return the complete pre-wipe directory to its exact original path. Restore any separately changed mod data from the matching recovery set. Keep the old and new sets separate rather than merging individual files, then repeat the restore checks above.
A world-only reset, an all-character reset and deletion of one character need different procedures. The current schema, companion files and cross-references for those selective edits haven’t been verified here. Don’t remove a row from players.db or individual world files using the full-reset instructions.
This section used AI-assisted research and drafting on 8 October 2026. We inspected retained 3 October DayZ 1.29.163709 storage, database schema and restore logs without running the game or reading player rows. That earlier check loaded saved economy files; no player joined. The full wipe, character reset, mod-data reset and rollback checks described here remain untested in game.
Include Garage’s separate vehicle records
Section titled “Include Garage’s separate vehicle records”If you use Krypton91’s Garage, check its profiles data as well as world storage. The 9 April 2023 source writes each player’s parked vehicles to <SteamID>.serialized in Depositary_System/PlayerData/, under the server’s active profiles path. Its loader reads that file first and falls back to the older .json file only when no serialized file exists. An old JSON file beside a newer serialized file may therefore be stale.
Include the whole Depositary_System folder in the stopped backup alongside world storage. This also preserves the mod’s settings in DepositaryConfig.json and its administration settings in AdminConfig.json. Keep both data formats if present. Don’t delete a serialized file to make the loader use an older JSON copy.
Check KeepInventory before parking a loaded vehicle. In the reviewed parking code, setting it to false keeps non-ruined direct vehicle attachments but leaves the other cargo out of the saved record. The vehicle is then removed from the world. Empty its cargo before parking when that setting is off.
Before a restore test, record one parked vehicle, its key and its contents, including items inside containers. On the separate restored instance, check the garage list, withdraw the vehicle and compare its cargo, attachments, key operation, fuel and damage. Then park it again, restart and repeat the withdrawal. Check that the vehicle appears only once. Match these checks to your installed release: the current Workshop package and a working restore were not tested in this source review.
Keep Advanced Banking balances with world data
Section titled “Keep Advanced Banking balances with world data”Krypton91’s Advanced Banking keeps its own account files. Its 11 August 2026 source declares version 2.13. Check your installed release before relying on these paths. This is a different package from the original Banking mod, which uses DC_Banking.
Include the whole KR_BANKING folder under the active server profiles path. That revision uses:
server-config.jsonfor settings, currency mappings and ATM placements, according to its path constants and configuration loader.PlayerDataBase/<Steam64 ID>.jsonfor individual accounts, including balances and clan membership.ClanDataBase/<Clan ID>.jsonfor clan accounts, including the shared balance and members.
Back up before updating the mod or restarting with edited settings. When the stored ModVersion differs from the package version, this loader attempts to copy the old configuration into OLDCONFIG, deletes the active file and writes defaults. It doesn’t check whether that copy succeeded. A JSON load error also doesn’t prevent the subsequent save. Keep an independent copy and validate edits while the server is stopped; don’t rely on the mod’s old-config folder as your only recovery point.
Restore bank data and the corresponding world and player saves from the same stopped backup. On a separate instance, compare personal balances, clan balances, membership and carried currency with your recorded values. Check them again after a restart before reopening the server. We haven’t matched this revision to the current Workshop package or tested its transaction controls and restore procedure in game.
Complete the inventory before the next mission or mod change. If you plan to move to managed DayZ hosting, confirm recovery coverage against that inventory, including any external database.