How to Back Up and Transfer a Don’t Starve Together World

Mental model first: what a DST world actually is

A Don’t Starve Together world is a cluster folder. On a local machine you usually see names like Cluster_1, Cluster_2 and so on. On a dedicated server the folder can be named anything. Inside that folder sit the cluster-wide files, then one folder per shard: Master for the overworld and Caves if caves are enabled.

The part people call “the save” is not one file. Each shard has its own save folder, and inside that are a shardindex file plus the current session tree with numbered snapshots and one folder per player. That is why copying only a session folder, only Master, or only a few files from inside save tends to fail: the server needs the shard index and the matching session state together.

Settings sit beside the save, not inside it. cluster.ini names the world. Each shard also has its own server.ini, modoverrides.lua, and sometimes worldgenoverride.lua or leveldataoverride.lua. On dedicated servers you also have cluster_token.txt. So there are really several layers: world state, shard settings, mod settings, and server identity. A transfer goes wrong when you copy the wrong layer, or overwrite host-specific values with values from another machine.

Cluster_1/
├─ cluster.ini                  # cluster_name lives here
├─ cluster_token.txt            # dedicated server token; keep private
├─ adminlist.txt                # created once used
├─ whitelist.txt
├─ blocklist.txt
├─ Master/
│  ├─ server.ini
│  ├─ modoverrides.lua
│  ├─ worldgenoverride.lua      # optional user world settings
│  ├─ leveldataoverride.lua     # optional, written by the game
│  └─ save/
│     ├─ shardindex
│     └─ session/
│        └─ <session ID>/
│           ├─ 0000000001       # world snapshot
│           ├─ 0000000002
│           └─ KU_xxxx_/        # one folder per player
└─ Caves/                       # only if caves are enabled
   ├─ server.ini
   ├─ modoverrides.lua
   ├─ worldgenoverride.lua
   ├─ leveldataoverride.lua
   └─ save/
      ├─ shardindex
      └─ session/...

The practical rule is simple: if you are protecting the whole world, copy the whole cluster. If you are merging a world into a rented server’s existing cluster shell, copy the whole save folder for each shard so shardindex and the matching session stay together.

Find the right world on your PC before you copy anything

Start from the game, not from guesswork in Documents. The main menu Data button opens the save area. For a specific world, go to Host Game, select the world, open Manage World, then use Open World Folder. On Linux and Steam Deck there is no button, so you need the path directly.

Local worlds live here:

• Windows: Documents\Klei\DoNotStarveTogether\<numbered folder>\Cluster_N
• Mac: ~/Documents/Klei/DoNotStarveTogether/<numbered folder>/Cluster_N
• Linux: ~/.klei/DoNotStarveTogether/<numbered folder>/Cluster_N

The <numbered folder> part is just the account slot area. The reliable way to identify the world is cluster_name inside cluster.ini. If you have several Cluster_N folders, open their cluster.ini files and look for the name you recognise.

Watch for Steam Cloud Save worlds. In the Manage World screen, the save type tells you if the world is Steam Cloud Save or Local Save. Cloud worlds are stored under CloudSaves and you will see Master.zip and Caves.zip there, not a normal local cluster tree. For transfers, use Convert To Local Save first, then copy the new local cluster folder. If you like, use Duplicate World before you start; the game makes a “Copy of <worldname>”, which is a good safety net before editing or uploading.

One easy mistake is the client_save folder. It is not a world. Do not upload it to a server, and do not use it as your backup source.

Rollback is for recent mistakes; backup is for real protection

DST creates a snapshot every time the world saves. That includes the normal end-of-day autosave and a save on shutdown. The server keeps up to max_snapshots, which is 6 by default. Rollback simply tells the shard to load an earlier snapshot from that same save history.

That is useful when the problem is recent and the save folder is still intact: a griefing incident, an accidental burn, a bad boss pull, or a mod problem you noticed straight away. Hosts can use the Rollback tab, players can vote to “Rollback the server to a previous save.” when voting is enabled, and the console command gives you more precise control.

The important nuance is that rollback counts saves, not “days” in a strict technical sense. End-of-day autosaves are the usual save points, but a manual save or shutdown also creates one. If you do it right after a save, use an explicit count so you know exactly how far back you are stepping.

c_save()
c_rollback(2)
c_rollback(0)
c_shutdown()

c_rollback(count) rolls back by save count. c_rollback() and c_rollback(1) roll back to the last save if it has been longer than 30 seconds. c_rollback(0) is the same as c_reset(), so it restarts from the last save rather than stepping back further. You can use rollback more than once if you need to go back further.

Do not confuse that with a backup. Snapshots live in the same shard save folder on the same machine. If the folder is deleted, a transfer overwrites it, or the host has a storage problem, your rollback history goes with it. Raising max_snapshots gives you a longer rollback history at the cost of more disk space, but every one of those snapshots still sits in that same folder.

Also, keep your hands off c_regenerateworld() unless you truly want a new map. It creates a brand-new world and destroys the current one. It is not a repair command.

[MISC]
max_snapshots = 6
autosaver_enabled = true

If you turn autosaver_enabled off, the game still saves on shutdown and with c_save(), but you lose the end-of-day snapshots that rollback relies on. Leave it on, and keep a separate copy anyway: that copy is the thing that actually protects you.

A backup routine that actually protects the cluster

Back up the world before game updates, before changing mods, before uploading or restoring anything, and on a regular schedule that suits how much progress you can afford to lose. The more valuable the current in-game day is, the more often you should make an external copy.

1. Run c_save() so the latest state is written immediately.
2. Stop the game or stop the server cleanly. Copying while it is still running risks catching one shard mid-save, which is how you end up with mismatched shardindex and session data.
3. Zip the whole cluster folder, not just Master/save.
4. Keep at least one copy off the server or off the PC that hosts the world.
5. Treat any backup containing cluster_token.txt as private.

Zipping the whole cluster costs a bit more disk than a narrow save-only copy, but it preserves the exact relationship between world state, shard settings, mods settings, and cluster-wide files. That makes restores far less ambiguous.

Move a local world to a rented dedicated server

Do the version check first. If the local world was saved by a newer game build than the server is running, the destination may show “Not playable – saved data from newer game version”. Update the server before you try to load the upload. This is a read-compatibility problem, not a sign that the save is bad.

Before the final save, get everybody out of the caves if you can. Master and Caves are separate shard servers, and players are stored in the shard they were in when saved. If someone is still in caves and the Caves shard is the part that goes wrong, that character data is exactly where the problem will be.

1. Close the game. If the world is a cloud save, use Convert To Local Save. If you want a fallback, use Duplicate World first.
2. Use Open World Folder and zip the local cluster.
3. On the rented server, stop the server fully.
4. Back up the server’s current cluster before touching it.
5. Find the live cluster folder. If the panel is unclear, search for cluster.ini. Dedicated servers use <persistent_storage_root>/<conf_dir>/<cluster>/; the default conf_dir is DoNotStarveTogether and the default -cluster is Cluster_1.

Method A: copy only the save folders into the host’s existing cluster

This is the safer method on rented servers because it keeps the host’s own network shell intact. Back up the host’s current Master/save and Caves/save, then remove or rename them. As long as a save already exists in save/, the server will not generate a new world, so you need that old save out of the way before replacing it.

Now copy in your local Master/save and Caves/save. Also copy the matching modoverrides.lua and worldgenoverride.lua for each shard. This carries over the actual world state plus mod settings and world settings, while leaving the host’s token, shard link details and ports alone.

Method B: upload the whole cluster, then restore the host’s own values

This is quicker when you want the server to mirror the source cluster exactly, but it is also the easy way to break connectivity. A dedicated server has environment-specific values in cluster.ini and server.ini. If you overwrite those with values from another machine, the shards may fail to link, or the server can become unreachable because the panel expects different ports and keys.

[SHARD]
shard_enabled =    # keep your host's value
bind_ip =          # keep your host's value
master_ip =        # keep your host's value
master_port =      # keep your host's value
cluster_key =      # keep your host's value

Keep the host’s own cluster_token.txt as well. In each shard’s server.ini, keep the host’s port settings too. The same point applies here: those values belong to the machine and panel, not to the save data.

Mods need a separate check. modoverrides.lua tells the server which mods and settings the world expects, but the actual dedicated server still needs the Workshop IDs listed for download. If your world uses mods, set that part up before first boot; our guide to installing mods on a DST server covers the server-side steps.

If you run into very old advice telling you to paste only a session folder into Master/save/session/, ignore it for modern cluster worlds. The cluster and shard structure already exists; move the proper shard save folders instead.

Move between hosts or from a server back to your PC

Between dedicated hosts

The logic is the same as a local-to-server move, just without the local numbered folders. Stop the source server, zip its cluster, stop the destination server, back up the destination cluster, then either copy only the shard saves into the destination cluster or upload the whole cluster and restore the destination host’s own shard-link and port values afterwards.

Save-only copying is still the cleaner option when the destination panel has already generated a working server shell for you. It keeps networking details stable and reduces the number of files that can clash.

From a dedicated server back to your PC

Maybe the group has shrunk, or you are switching to hosting on your own PC. Moving a world back is easiest when you let the game create a fresh local folder structure first. Create or duplicate a local world so you have a valid Cluster_N inside the correct numbered folder, then replace that local world’s Master/save and Caves/save with the server copies. Bring over modoverrides.lua and worldgenoverride.lua if you want the same mod and world settings.

Check cluster_name in cluster.ini so you know which local cluster is the right one. If you want the world in Steam Cloud later, confirm the local version works first, then use the in-game cloud conversion afterwards.

Check the move worked before everyone joins back

A transfer is only finished once you verify the live result. Start the server and check the basics in this order:

• World name: does it match the expected cluster_name?
• Day count: is it the day you expect, rather than a fresh Day 1 or an older checkpoint?
• Player data: are the expected characters present, especially anybody who was last saved in caves?
• Shard link: if caves are enabled, confirm the caves shard is the correct one and linked to the same world, not a separate fresh generation.
• Mods: did the server load the expected mod set from modoverrides.lua?

If any of those are wrong, stop the server again before players make new progress. That prevents mixing a bad upload with fresh new saves, which makes the next restore much messier.

What matters in a host if you plan to move and restore saves

For this job, the useful host features are straightforward. You want a proper file manager or SFTP access so you can see the real cluster tree, your own backups and restore tools so a bad upload is reversible, and a simple way to enter or preserve the cluster token without hunting through odd panel menus. Clear stop and start controls matter too, because copying live shard files is how partial saves happen.

Access to cluster.ini and each shard’s server.ini is also important. If the host hides those files completely, whole-cluster transfers are harder because you cannot restore the environment-specific values that should stay with the host.

Troubleshooting after a move or restore

Most DST transfer problems come down to one of four causes: wrong folder, wrong layer, mismatched shards, or overwritten host values. Start there.

If you need a quick diagnosis path, use this flow to decide whether the problem is the path, the shard pair, or the host settings layer.

Don’t Starve Together server FAQ

Where are Don’t Starve Together save files stored?

Local worlds are stored under the Klei documents folder, inside a numbered folder and then a Cluster_N folder. On Windows that is Documents\Klei\DoNotStarveTogether\<numbered folder>\Cluster_N; on Mac it is under ~/Documents/Klei/DoNotStarveTogether/; on Linux it is under ~/.klei/DoNotStarveTogether/. For server work, the save you care about is inside each shard’s save folder, not in client_save.

How do I roll back a Don’t Starve Together server?

You can use the host controls, the in-game Rollback option, player voting if enabled, or the console command c_rollback(count). DST creates a snapshot every time the world saves, including end-of-day autosaves and shutdown saves, so rollback steps back through those save points. It is good for undoing a recent mistake, but it is not a substitute for a separate backup.

Can I move my Don’t Starve Together world to a dedicated server?

Yes. The safest method is to stop the destination server, back up its current cluster, then copy in your matching Master/save and Caves/save plus the shard modoverrides.lua and worldgenoverride.lua files. If you upload the whole cluster instead, restore the host’s own shard-link, port and token values before starting it.

Why did my DST server start a new world after I uploaded my save?

Usually because the save went into the wrong cluster folder, only part of the save structure was copied, or the server is still using a different live cluster than the one you edited. Search the file manager for cluster.ini to find the real cluster path, then make sure the full shard save folders are in the right place. Also confirm you did not upload client_save by mistake.

Do I need to copy the Caves folder too?

Yes, if the world uses caves. Master and Caves are separate shard servers with separate saves, and they need to come from the same moment. Skipping Caves, or mixing Caves from a different backup point, is one of the main causes of broken transfers and missing character state.

More Don’t Starve Together server help

Set up the rest of your server, or compare hosts that give you real file access and backups.