---
title: "Enshrouded Server Backups: Saving, Restoring and Rolling Back a World"
description: "Back up and restore an Enshrouded world: the four files in savegame/, how often the server writes, and Keen's supported rollback via the -index latest key."
url: "https://www.gameserverkings.com/knowledge-base/enshrouded/backing-up-and-restoring-your-world/"
category: "Enshrouded"
category_url: "https://www.gameserverkings.com/knowledge-base/enshrouded/"
published: "2026-08-19T10:59:37.019Z"
updated: "2026-08-19T11:30:38.421Z"
source_format: "markdown"
site: "GameServerKings"
---

# Enshrouded Server Backups: Saving, Restoring and Rolling Back a World

Your Enshrouded server holds exactly one thing you cannot replace: the world. Characters are not on it — Keen Games are explicit that "Character progression is stored only on clients. The world progression is stored on the dedicated servers." So a backup strategy for an Enshrouded server is a strategy for one folder, `savegame/`, and for the small set of files inside it.

The good news is that the game already keeps ten rolling copies of every world for you, and Keen document a supported way to roll back to any of them. This guide covers what the server saves and when, how to take a backup that is actually restorable, how to roll a world back a few minutes without restoring anything, and the mistakes that turn a backup into a stale one.

## What the Server Actually Saves

Keen's Dedicated Server FAQ is precise about the split:

> "There is a file per game-world. Character save-games will not be stored on the dedicated server. Character progression is stored only on clients. The world progression is stored on the dedicated servers."

That has three consequences worth internalising before you plan anything:

- **You cannot back up a player's character from the server.** Their levels, skills, inventory and equipment live on their own machine. If a player loses their character, nothing you do on the server recovers it.
- **A world restore never rolls a player back.** Restore a week-old world and everyone still walks in with the character they had five minutes ago. Their gear survives; the bases do not.
- **A world is small.** Keen put the range at "between 1MB and 100MB", small at the start and pushing 100 MB only for worlds with a lot of large bases. Backing this up is cheap, and there is no excuse for not doing it often.

### How often it writes

Keen's two support pages give two different numbers, and rather than pick one for you, here is what each says:

| Keen source | What it states |
|---|---|
| Dedicated Server FAQ | "Save game files will be created every 5 minutes." |
| Save Game Management | "Each world save has 10 numbered rolling copies … A new copy is created every 10 minutes or when shutting down the game, overwriting the oldest copy." |

The practical reading is that the world is written frequently and a fresh *rolling copy* is rotated in on a slower cycle, but Keen have not published a single reconciled figure. Plan on the pessimistic end: assume up to ten minutes of play can be lost to an unclean stop, and take that into account before you do anything risky.

There is no setting for the interval. It is not a key in `enshrouded_server.json`, and no control panel can change it.

## The Files in `savegame/`

Each world is a set of four files sharing one hexadecimal stem. Keen publish the stems, which are assigned in order of world creation:

| World | ID | World | ID |
|---|---|---|---|
| 1 | `3ad85aea` | 6 | `37d85631` |
| 2 | `3bd85c7d` | 7 | `34d85178` |
| 3 | `38d857c4` | 8 | `35d8530b` |
| 4 | `39d85957` | 9 | `32d84e52` |
| 5 | `36d8549e` | 10 | `33d84fe5` |

A dedicated server generates one world, so on a hosted server the stem you will see is almost always `3ad85aea`. The four files are:

| File | What it holds |
|---|---|
| `3ad85aea` | The world itself — voxels, bases, altars, progress |
| `3ad85aea_info` | Metadata, including the world's name |
| `3ad85aea-index` | The pointer to which of the ten rolling copies is current |
| `3ad85aea_info-index` | The same pointer for the `_info` file |

> [!WARNING] The `-index` files are not optional
> They are the only record of *which* of the ten rolling copies is live. Copy the base file and its `_info` without the two `-index` files and a restore will load whichever copy the server happens to pick — usually an older one. Every backup and every restore must move all four files together.

The config file and any crash dumps sit alongside the server executable rather than in `savegame/`. Keen note that "the config file itself and crash dumps are automatically placed in the same directory as the server exe" — so a full backup of a server is `savegame/` plus `enshrouded_server.json`.

## Taking a Backup You Can Actually Restore

### Use the panel's Backups tab

The Backups tab in your server panel snapshots the whole server directory, which is the simplest correct answer: it captures `savegame/`, `enshrouded_server.json` and the logs in one artefact. [How to use your server panel](/knowledge-base/general/how-to-use-your-server-panel/) covers where the tab lives.

### Stop the server first when it matters

For a routine daily snapshot, taking it live is fine — the world files are small and consistent enough that you will lose at most the last few minutes. For anything you intend to rely on, stop the server first.

The reason is specific to how Enshrouded shuts down. It writes a save on a clean shutdown, so a stopped server has a world file that is current to the second rather than current to the last save tick. On a hosted server the **Stop** button sends the graceful stop signal the game expects; a **Kill** does not, and a killed server has written nothing since its last automatic save.

> [!IMPORTANT] Stop, then back up, then edit
> This is also the order that keeps your configuration. Enshrouded writes its in-memory settings back to `enshrouded_server.json` when it shuts down, so a config edited while the server is running is overwritten on the next stop. The sequence that works for both the world and the config is **stop → back up → edit → start**.

### Pull a copy off the server too

A snapshot that lives only on the same machine as the thing it protects is half a backup. Because a world is at most about 100 MB, downloading `savegame/` after any session you care about is a small job. [How to upload files via SFTP](/knowledge-base/general/how-to-upload-files-via-sftp/) covers the connection; the same route works in reverse for downloads, and it is faster and more resumable than the browser file manager for a world that has grown large.

### A rhythm that matches how the game is played

- **Daily** — a panel snapshot, unattended.
- **Before any build session you would hate to lose** — a manual snapshot, taken with the server stopped.
- **Before every game update** — a manual snapshot. See [How to update your Enshrouded server after a patch](/knowledge-base/enshrouded/updating-your-server-after-a-patch/), because this is the one moment where the cost of not having a backup is highest.
- **Before you touch `enshrouded_server.json`** — a copy of the file, not the whole server. A malformed config stops the server booting, and having the last known-good file to paste back turns a broken evening into a two-minute fix.

## Rolling a World Back Without a Restore

This is the part almost nobody knows about, and it is documented by Keen.

Every world keeps **ten numbered rolling copies**, numbered 0 to 9, and the `-index` file records which one is currently live under a key named `latest`. Keen's Save Game Management article states it plainly:

> "Each world has an accompanying -index file, in which the currently active world save number is written under 'latest'. For rollback purposes, when loading the -index file into a text editor, the number can be changed as desired to a value from 0 to 9."

So you can move a world back one rotation — or several — without restoring a backup at all. The procedure:

1. **Stop the server.** Do not do this on a running server; it holds its own copy of the state and will overwrite yours.
2. **Take a snapshot first.** Keen's own warning: "Before making any changes, it is highly recommended to create a copy of all save files, to prevent accidental loss of data." If you pick the wrong number you want to be able to get back.
3. **Open `savegame/` and check the modified timestamps.** Keen note you can "refer to the modified date in your file browser to check when which copy was created". That is how you work out which rotation corresponds to the moment you want.
4. **Edit `3ad85aea-index`** and change the value under `latest` to the copy you want, between `0` and `9`.
5. **Start the server** and check that the world is where you expect before anyone builds on it.

> [!CAUTION] The rollback window is short, not deep
> Ten copies at roughly ten minutes apart is somewhere around an hour and a half of history, and every restart consumes one. This is a way to undo the last mistake, not a way to reach yesterday. Anything older than the rotation window has to come from a real backup.

## Restoring a World

Restoring is a file swap, and the order matters:

1. **Stop the server.**
2. **Snapshot the current state**, even if you are certain it is the state you want to discard. This is the only step people skip and the only one that costs them.
3. **In `savegame/`, remove or rename the existing `3ad85aea*` files.** Renaming is safer than deleting.
4. **Upload all four files** from your backup, keeping the exact names.
5. **Start the server** and watch the console.

A healthy boot ends on the session transition and the deserialize timing:

```text
[Session] 'HostOnline' (up)!
[Session] finished transition from 'Lobby' to 'Host_Online' (current='Host_Online')!
[server] Load deserialization took 2.77 s
```

Keen list those same lines as the answer to "what is a typical indicator that the server is fully started?" — and your panel uses the first of them as the marker that flips the server to running. If the console reaches that point, the world loaded.

6. **Join and verify** before you tell anyone the restore worked. Check a base you recognise and the shroud progress, not just that the server is up.

> [!TIP] Take a fresh snapshot immediately after a successful restore
> The restored world is now your new baseline. Snapshotting it right away means the next thing that goes wrong rolls back to *here* rather than to the state you just spent an evening fixing.

## Common Backup Mistakes

- **Backing up only the base file.** Without `_info` and the two `-index` files the restore is unreliable and the world's name is gone. Take all four, always.
- **Backing up a running server before something risky.** The snapshot is up to a save cycle stale, and that is exactly the window in which the thing you were worried about happens.
- **Assuming characters are covered.** They are not on the server at all. If a player wants their character backed up, that is a job on their own PC, in `%USERPROFILE%\Saved Games\Enshrouded\` — or in `Steam\userdata\<their id>\1203620\remote` if they have Steam Cloud on for the game.
- **Keeping every backup forever and none of them off-server.** Ten daily snapshots on the same disk protect you from a bad build session and from nothing else.
- **Forgetting `enshrouded_server.json`.** The world is irreplaceable, but a config with four role passwords, a tuned difficulty block and a slot count is an hour of work you do not want to redo from memory.

## What to Read Next

- [How to update your Enshrouded server after a patch](/knowledge-base/enshrouded/updating-your-server-after-a-patch/) — the update routine that begins with a backup.
- [How to transfer your Enshrouded world to your dedicated server](/knowledge-base/enshrouded/transfer-your-world/) — bringing a world *in* from a PC, including the rename step.
- [Enshrouded server settings and config file](/knowledge-base/enshrouded/configuration-overview/) — the `enshrouded_server.json` reference, and why it gets overwritten on shutdown.
- [Getting started with your Enshrouded server](/knowledge-base/enshrouded/getting-started-with-your-server/) — first boot and where `savegame/` sits in the file layout.
- [Enshrouded server requirements](/knowledge-base/enshrouded/server-requirements/) — including how much disk a world and its backups actually need.

## FAQ

### Where are Enshrouded server saves stored?

In the folder named by `saveDirectory` in `enshrouded_server.json`, which defaults to `./savegame`. Each world is four files sharing a hexadecimal stem — on a dedicated server that is almost always `3ad85aea`.

### Does an Enshrouded server back up characters?

No. Keen state that character progression is stored only on clients and world progression only on the server. A player's character lives on their own machine and travels with them between servers.

### How often does an Enshrouded server save?

Keen's Dedicated Server FAQ says save files are created every 5 minutes. Their Save Game Management article describes a new rolling copy every 10 minutes or on shutdown. There is no configurable interval either way.

### How do I roll my Enshrouded world back a few minutes?

Stop the server, back up `savegame/` first, then edit the `latest` value in the world's `-index` file to another of the ten rolling copies, numbered 0 to 9, and start the server. Keen document this as the supported rollback method.

### How big is an Enshrouded world save?

Keen put it at 1 MB to 100 MB — small at the beginning, and closer to 100 MB for worlds with a lot of large bases.

### My restored world is hours out of date. Why?

Almost certainly because the `-index` files were not restored alongside the base file, so the server loaded whichever rolling copy the stale pointer named. Restore all four files together.

### Can I back up while the server is running?

Yes, and for a routine daily snapshot that is fine. For a backup you intend to rely on, stop the server first so the shutdown save is included — and use Stop rather than Kill, because a killed server writes nothing on the way out.

---

Made with 💜 by GameServerKings