How to back up, restore and move a DayZ server

By Niko Catarino

Updated 3 October 2026

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

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.

Scroll to see all columns →

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

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

1. 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.
2. Confirm that the process has stopped writing. Keep the incident logs if something failed.
3. Copy the inventoried mission, persistence and mod-owned data into one dated set. Export external databases through their supported method.
4. Leave that source copy intact. Extract a duplicate and compare its paths, file sizes or hashes with the captured files.
5. 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

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.

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.

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.