How to Restore a Valheim World From a Backup
Restoring a Valheim world is a file swap, not a command: stop the server, set the current files
aside rather than deleting them, copy the .db and .fwl pair from your backup into
worlds_local under the exact world name your server launches with, then start the server and
check before you tell anyone it’s fixed. The two rules that matter are the server must be
stopped and both files travel together. Everything else is bookkeeping.
Know what you’re restoring
Each world is two files:
<World>.db— the world itself: terrain changes, structures, containers, everything.<World>.fwl— the metadata and the seed.
Valheim also keeps .db.old and .fwl.old — the previous save. That’s a free one-step
rollback and it’s often all you need, but it’s a rolling copy that gets overwritten, so it only
helps if you act before it’s replaced.
The world files live in the Valheim data directory:
Windows: %USERPROFILE%\AppData\LocalLow\IronGate\Valheim\worlds_local\
Linux: ~/.config/unity3d/IronGate/Valheim/worlds_local/
Docker: <your config mount>/worlds_local/
On Linux that’s the home directory of the user running the server, which is where people look in the wrong place and conclude their world is gone.
Step 1: Stop the server, and mean it
A running server holds the world in memory and will write it back over whatever you just copied in, silently undoing your work. Worse, it may write the broken state on top of your good backup.
sudo systemctl stop valheim
Or in Docker:
docker compose down
Then confirm nothing is left running:
ps aux | grep -i valheim
On Windows, check Task Manager for a leftover server process. An orphaned process is the number one reason a restore “didn’t take”.
Step 2: Set the current files aside — don’t delete them
Even a broken world is evidence, and sometimes it turns out to be less broken than the backup is old. Move, don’t remove:
cd ~/.config/unity3d/IronGate/Valheim/worlds_local
mkdir -p ~/valheim-broken-$(date +%Y%m%d)
mv Midgard.db Midgard.fwl Midgard.db.old Midgard.fwl.old ~/valheim-broken-$(date +%Y%m%d)/
If you’re restoring because of griefing rather than corruption, this copy is also how you can go back and retrieve something you’d forgotten was lost.
Step 3: Try the .old pair first
Before reaching for an archive, consider the rollback copy the server made for you. If you moved it aside in step 2, bring it back under the live names:
cp ~/valheim-broken-*/Midgard.db.old ./Midgard.db
cp ~/valheim-broken-*/Midgard.fwl.old ./Midgard.fwl
This costs you whatever happened since the previous save — usually minutes. Try it before you lose hours to an older archive.
Step 4: Restore from a real backup
Extract your archive somewhere temporary so you can see what’s in it before it touches the live directory:
mkdir -p /tmp/restore && tar xzf ~/valheim-backups/valheim-20260726-040000.tar.gz -C /tmp/restore
ls -R /tmp/restore
Then copy the pair into place:
cp /tmp/restore/Midgard.db ~/.config/unity3d/IronGate/Valheim/worlds_local/
cp /tmp/restore/Midgard.fwl ~/.config/unity3d/IronGate/Valheim/worlds_local/
Three things to get right:
- Both files, from the same backup. A
.dbpaired with a.fwlfrom a different point in time is asking for trouble. - The filenames must match your launch argument. If the server launches with the world named
Midgard, the files must beMidgard.dbandMidgard.fwl. If your backup used a different name, either rename both files or change the launch argument — consistently. - File ownership. If you extracted as root or as your own user,
chownthem to the service user or the server won’t be able to write saves:
sudo chown valheim:valheim ~/.config/unity3d/IronGate/Valheim/worlds_local/Midgard.*
Step 5: Start and verify before announcing anything
sudo systemctl start valheim
journalctl -u valheim -f
Watch for the world loading without errors, then join yourself and check something concrete: your base is standing, a chest has the contents you remember, the map is explored as far as it should be. Only then tell the group.
If the world loads but looks older than you expected, you restored an earlier archive than you meant to. Stop the server immediately — before play writes over it — and try the next archive. Every minute of play makes going further back more expensive.
Restoring on Windows
Same logic with Windows paths. Stop the server process, then:
$worlds = "$env:USERPROFILE\AppData\LocalLow\IronGate\Valheim\worlds_local"
Expand-Archive -Path "$env:USERPROFILE\valheim-backups\valheim-20260726.zip" -DestinationPath "$env:TEMP\restore"
Copy-Item "$env:TEMP\restore\Midgard.db","$env:TEMP\restore\Midgard.fwl" -Destination $worlds -Force
Move the existing pair somewhere else first, exactly as above.
Restoring in Docker
Bring the stack down, replace the files in the mounted config folder on the host — not inside the container — and bring it back up:
docker compose down
cp /tmp/restore/Midgard.* ~/valheim/config/worlds_local/
docker compose up -d
docker compose logs -f valheim
Because the data lives on the host, restoring never involves rebuilding the container. Layout in Running a Valheim Dedicated Server in Docker on Linux.
What a restore can’t fix
- Player characters. Characters are stored client-side, so a world rollback doesn’t restore someone’s inventory or skills. Their character is whatever their own game has.
- Anything after the backup. Obvious, but worth saying out loud to the group before you do it: a rollback undoes everyone’s evening, not just the damage.
- The underlying cause. If the world corrupted because the server is being hard-killed, or the disk is failing, you’ll be back here. See What to Do When Your Valheim Server Keeps Crashing.
Make the next restore boring
- Run the console
savecommand before taking a backup, so the archive holds current state. - Back up on a schedule and prune automatically, per Essential Valheim Admin Commands and Automated Backups.
- Keep copies off the machine. A backup on the same disk doesn’t survive the disk.
- Test a restore once, deliberately, onto a spare world name while nobody’s playing. An untested backup is a hypothesis.
- Back up the permission files too — they’re tiny and annoying to reconstruct.
Do that, and the day you actually need this page it’s a ten-minute job with a known outcome.