So you've been running a DayZ server somewhere else and you want to bring your world across to LOW.MS. Maybe your group has spent months building bases at Tisy, or you've finally got the loot economy tuned the way you like it. Good news: DayZ keeps everything in a handful of files, and once you know where to look, moving a server is mostly drag and drop.
DayZ doesn't really do "singleplayer saves" the way most survival games do. There's no Local vs Cloud prompt, no folder of named save slots in %LOCALAPPDATA%. Player progress, base structures, vehicles, stashed gear and the whole map state live entirely on the server, inside a folder called storage_1. Migrate that folder and your players reconnect to the world they left.
Where DayZ saves live on the server
Everything DayZ persists sits inside the active mission folder:
mpmissions/dayzOffline.chernarusplus/
That's the path for Chernarus, the default map. If you're running Livonia it's mpmissions/dayzOffline.enoch/, and Sakhal (the Frostline DLC map) is mpmissions/dayzOffline.sakhal/. Community maps from the Workshop each have their own mission folder name, so check the map's Workshop page if you're not sure.
Two subfolders inside the mission folder matter:
mpmissions/dayzOffline.chernarusplus/
├── db/ <- loot economy config (types.xml, events.xml, globals.xml)
└── storage_1/ <- the save state
├── players.db <- player accounts and inventories (SQLite)
└── data/ <- world state: bases, vehicles, stashed loot, dynamic events
├── vehicles.bin
├── events.bin
├── dynamic_*.bin
└── (other persistence binaries)
storage_1/ is the part that updates while the server runs. players.db is a SQLite database holding every player's character: health, inventory, position, alive/dead state. The .bin files in storage_1/data/ are binary blobs that store everything currently existing in the world – built bases, parked vehicles, dropped loot, tents, barrels, fences, the lot.
Quick note on the 1 in storage_1. That number comes from the instanceId in serverDZ.cfg. Default is 1, so default storage is storage_1. If you or your old host changed instanceId, the folder on disk will match (storage_2, and so on). Worth checking before you start copying things across.
The db/ folder next to it is a different beast. That's your loot economy config: types.xml, events.xml, globals.xml, messages.xml. It controls what can spawn, not what currently exists. If you've spent time tuning loot rates, that work lives here, and you'll want to copy it across alongside storage_1/ when you migrate.
The other config file worth knowing about is serverDZ.cfg in the server root. The line that picks which mission folder to load is nested inside the Missions class:
class Missions {
class DayZ {
template = "dayzOffline.chernarusplus";
};
};
If your old host was using a custom mission name, this has to match on the new server too.
Before you do anything
Two things. Both important.
Stop both servers before copying anything. DayZ writes to storage_1/ actively while running. Pulling the files out from under a live server gets you half-written .bin files and a corrupt save. Stop the service on your old host through whatever panel they give you. On LOW.MS, head to control.low.ms, find your DayZ service, and stop it there too.
Back up the LOW.MS server's existing save first. Even on a fresh install where there's nothing to lose, get into the habit. In the LOW.MS Control Panel, go to Cloud Backup in the sidebar and create a backup. Takes seconds, gives you a fall-back if the migration goes sideways.
Pulling the files off your old host
Most DayZ hosts give you FTP or SFTP access. Connect with WinSCP or FileZilla using the credentials from your old panel and download:
- The entire
storage_1/folder from insidempmissions/dayzOffline.chernarusplus/(or whichever mission your server runs) - The
db/folder from the same location, if you've customised loot serverDZ.cfgfrom the server root (handy as a reference even if you don't import it wholesale)- Any
@-prefixed mod folders from the server root, plus thekeys/folder
A vanilla storage_1/ runs a few hundred megabytes after a busy wipe. Heavily modded servers with lots of base building can push past a gigabyte. Either way, SFTP handles transfers more reliably than a browser upload.
Uploading via File Manager
The panel's built-in File Manager works fine for smaller migrations. For the typical case, a fresh LOW.MS server where you're dropping in your old world:
- Log into control.low.ms and select your DayZ server
- Click File Manager in the sidebar
- Navigate to
mpmissions/dayzOffline.chernarusplus/(or your map's mission folder) - If a
storage_1/folder already exists from the server's first boot, delete it - Upload your old
storage_1/folder in its place - If you're bringing custom loot config, do the same with the
db/folder. Back up the existing one first, or merge by hand if you've got LOW.MS-specific tweaks
File Manager handles folder uploads, but past about 500 MB the browser starts struggling. Once storage_1/ grows large (and it will, on any long-running server), SFTP is the better choice.
Uploading via SFTP
SFTP is on port 8822. You'll need a client like WinSCP or FileZilla. Your connection details live in Service Settings on the panel.
- Protocol: SFTP
- Host: your server's address (shown in Service Settings)
- Port: 8822
- Username/Password: same as your panel credentials for this service
Once you're connected, navigate to mpmissions/dayzOffline.chernarusplus/ on the server side, delete the existing storage_1/ if there is one, and drag your local copy across. SFTP gives you a proper progress bar and resumes cleanly if the transfer drops.
If you're also moving mods, drop the @-prefixed folders into the server root and copy each mod's .bikey files into the keys/ directory. Mod load order is set through Commandline Manager in the panel. See the DayZ server configuration guide for the syntax.
Pointing serverDZ.cfg at the right mission
This is the step people forget, and then they wonder why the server boots into an empty Chernarus when they were expecting Livonia or a modded map.
Open serverDZ.cfg in the server root via Configuration Files in the panel. Find the template line inside class Missions:
template = "dayzOffline.chernarusplus";
If your migrated storage_1/ came from a Livonia server, this needs to be dayzOffline.enoch. Sakhal is dayzOffline.sakhal. Modded maps use whatever name the map mod ships. Namalsk, Deer Isle and Banov each have their own. The string here has to exactly match the folder name inside mpmissions/, or the server falls back to defaults and ignores your imported save entirely.
Save the file.
Starting up
Start the server back up from the panel. First boot after importing a populated storage_1/ runs a bit slower than a fresh start, because DayZ has to index every persisted object before it accepts connections. On a well-built server that's a minute or two, occasionally longer.
Open Web Console from the sidebar to watch the startup logs. You're looking for the line that says the mission has finished loading and the server is accepting players. Once that appears, grab your connection details and join in DayZ via the Direct Connect option in the server browser.
Walk to where one of your old bases used to stand. If the structures, vehicles and stashed gear are all there, the migration worked. If you're staring at an empty field, double-check that template = in serverDZ.cfg matches the mission folder you uploaded into.
Wipes, mod updates and when to reset
Sometimes you want the opposite of a migration, a clean slate. DayZ has two flavours of wipe:
Map wipe (keeps players). Stop the server, delete everything inside storage_1/data/, and leave players.db alone. Bases, vehicles and dropped loot vanish; player accounts and characters stay. On next boot the world regenerates from defaults.
Full wipe. Stop the server and delete the whole storage_1/ folder. The server recreates it from scratch on first boot, including a fresh players.db. Everyone starts naked on the coast.
Mod updates sometimes force a wipe whether you want one or not. Major DayZ Expansion updates and base-building mod updates often change how persisted objects are stored, and the existing .bin files become incompatible. The mod's Workshop page or changelog will usually flag this. If a mod update boots into a server full of broken bases or invisible vehicles, a map wipe is the fix.
DayZ itself ships major patches a few times a year, and those occasionally invalidate persistence too. The official patch notes call it out when it happens.
A few things to know
The .bin files in storage_1/data/ aren't human-editable. They're proprietary binary blobs and the format shifts between versions. Don't try to merge persistence files from two servers, and don't open them in a text editor expecting to find anything useful.
players.db is SQLite, so technically you can open it with a tool like DB Browser for SQLite. The table you care about is Players, with four columns: Id, Alive, UID and Data. The Data column is a binary blob (player inventory, position, status), so there's not much you can usefully edit – mark a player alive or dead, delete a character record, and that's about it.
Version mismatches between your old and new server cause real problems. If the old host was running DayZ 1.27 and LOW.MS provisioned 1.28, the persistence format may have shifted enough that some objects don't load. Check the version on your old server before pulling the files, and if there's a gap, let the LOW.MS server update fully before importing.
If anything goes wrong after the migration, that's what your backup is for. Go to Cloud Restore, pick the backup you made earlier, and you're back to where the server was before you touched anything. For more on serverDZ.cfg, the loot economy and mod setup, see the DayZ server configuration guide.