Save Migration: Local to Dedicated

You can move a singleplayer or peer-hosted co-op world onto a dedicated server without losing the world, the bases, or anyone's character progress. The mechanics: 7 Days to Die stores the world's terrain, the placed blocks, and each player's character data in clearly-separated folders, and the dedicated server reads them from the same layout. Match the names, copy the files, point serverconfig.xml at them — done. This guide covers the file locations, the exact properties to match, and the snags that catch people.

How a 7D2D Save Is Organized

A single playable world lives at <saves-root>/<GameWorld>/<GameName>/. Inside that folder, the relevant subdirectories:

Subfolder / fileContents
Region/The placed-block data (your bases, dug-out areas, harvested trees). Each r.X.Y.7rg file is one map region.
Player/Per-player character files. Each player has a file named after their EOS ID (or Steam ID for older saves). Contains level, perks, inventory, status effects.
main.ttpWorld-level state (current day, time, weather state, blood-moon counter).
map_*.datPer-player map exploration data.

The terrain itself (the heightmap and POI placement) lives in a separate Worlds folder, organized by GameWorld name. For Navezgane this is shipped with the game. For RWG worlds, it's generated once and cached.

Where to Find the Files

Where the save livesPath
Singleplayer / peer-hosted (Windows client)%APPDATA%\7DaysToDie\Saves\<GameWorld>\<GameName>\
Singleplayer (Linux client)~/.local/share/7DaysToDie/Saves/<GameWorld>/<GameName>/
RWG world terrain (client, Windows)%APPDATA%\7DaysToDie\GeneratedWorlds\<world-name>\
RWG world terrain (client, Linux)~/.local/share/7DaysToDie/GeneratedWorlds/<world-name>/
Dedicated server (default)Under the server's user-data folder; structure is the same (Saves/<GameWorld>/<GameName>/).
Dedicated server (overridden)Wherever UserDataFolder and/or SaveGameFolder in serverconfig.xml point.

The dedicated server's actual save root depends on whether UserDataFolder or SaveGameFolder are set in serverconfig.xml — both are commented-out by default but easy to add. Check those two properties first; if they're set, that path is the source of truth.

Migration Procedure

  1. Stop the dedicated server. Use shutdown in the console (graceful) — never kill -9. See Scheduling Automated Restarts for the safe sequence.
  2. Locate the source save. On the client, navigate to the path from the table above. The folder you want is named after your GameName setting; it sits inside a folder named after GameWorld.
  3. Locate the world terrain. If you used Navezgane (the shipped map), skip this — the dedicated server already has it. If you used any RWG world, you also need the matching folder from GeneratedWorlds/ on the client.
  4. Decide on names. Pick the GameWorld name (terrain folder name) and GameName (save folder name) you'll use on the dedicated server. The simplest approach: use the same names you had on the client — fewer moving parts.
  5. Copy to the server:
    • The whole client save folder → server's Saves/<GameWorld>/<GameName>/
    • The whole RWG terrain folder (if applicable) → server's GeneratedWorlds/<world-name>/
    Use scp or rsync on Linux, or your hosting panel's file-manager / SFTP. Preserve the directory structure exactly.
  6. Edit serverconfig.xml:
    • GameWorld = the terrain folder name (e.g. Navezgane, or your RWG world name)
    • GameName = the save folder name
    • If you're using an RWG world that already exists in GeneratedWorlds/, leave WorldGenSeed and WorldGenSize alone — they're only used to generate a new world if no matching name is found.
  7. Start the dedicated server. Watch the log (see Log Masterclass) — you should see "Loading world" with your GameWorld name, then "Loading save" with your GameName.
  8. Have a player join. Their character file under Player/ should load. They should arrive at the position they last logged off at, with their level and inventory intact.

Player Characters Don't Carry Across Servers

One detail catches everyone: in 7D2D, your character is per-save, not per-account. The character data file is named after the player's identity (Steam ID or EOS ID) and lives in that save's Player/ folder. So:

  • If you migrate the save folder including its Player/ subdirectory, the original co-op players keep their characters — their ID-named file is in there.
  • If a brand-new player joins after migration, they get a fresh level-1 character, as expected.
  • If a player who used to play locally joins from a different account/ID (e.g. they signed in on a different platform), their old character stays in the file system but they won't see it — the game looks them up by their current ID.

Steam ID vs. EOS ID can be confusing because V2.6 supports both Steam-only and Steam+EOS sessions. If a player ends up at level 1 after migration, the most common cause is an ID mismatch: their character file is named for one ID, the game's looking for another. Check the file names in Player/ against the IDs the dedicated server logs when they connect.

Common Issues

SymptomMost-likely cause
Server starts but world is fresh / blankGameWorld or GameName in serverconfig.xml doesn't match the uploaded folder names. The server falls back to creating a new world with whatever you specified. Stop the server, fix the names, restart.
Players join at level 1The migrated save's Player/ folder didn't include the right ID file, or the player is connecting via a different ID than they did locally. See the section above.
"World not found" errors in logMissing GeneratedWorlds/<world-name>/ on the server. RWG worlds need both the save folder and the terrain folder.
Bases are gone but the player is at the right spotThe Region/ subfolder didn't copy correctly. Verify the r.*.7rg files are present.
Days-survived / blood-moon counter is wrongThe main.ttp file didn't copy or was overwritten by a stale one. The world counter lives there, not in player files.

Backups and Reversibility

Always keep an unmodified copy of both the client save and the server's pre-migration save. If the migration goes wrong, you can:

  • Restore the dedicated server's old save folder, restart, and try again.
  • If you don't have a backup, the corrupted state may be recoverable with chunkreset on specific regions — see Admin Commands.

The 7D2D dedicated server has no built-in versioning, so backups are your responsibility. A daily snapshot of the save root (cron + tar, or your hosting panel's snapshot feature) takes seconds and saves the project the day someone runs kill -9 on the server.