Valheim server backups and world corruption

A Valheim world is two files - Name.db and Name.fwl - and a server keeps three kinds of copy of them: the .old pair written on every save, the automatic backups controlled by -backups, -backupshort and -backuplong, and whatever real backups you take off the machine. Restoring any of them is the same operation: stop the server, put the right .db and .fwl pair in worlds_local under the world's name, and start it again. Corruption almost always comes from the process dying or the disk filling during a save, and the fix is almost always the most recent good pair. This post covers where everything lives, what each flag does, how to restore, and how to recover a world that loads wrong or not at all.

The rest of server setup is in the Valheim dedicated server guide. If you are moving a world onto a server for the first time rather than recovering one, how to upload a Valheim save is the better starting point.

What a Valheim world is on disk#

Everything about a world is in two files with the same base name:

The .fwl is small but not optional. It carries the seed, and the seed is what generates the terrain the .db file's modifications are applied to. A .db from one world paired with a .fwl from another loads, but the buildings sit on the wrong landscape. Always move, copy and restore the two as a pair, taken from the same moment.

On a Linux server the default location is under the user's Unity data folder:

~/.config/unity3d/IronGate/Valheim/worlds_local/

On a Windows server it is %USERPROFILE%\AppData\LocalLow\IronGate\Valheim\worlds_local\. If the server is started with -savedir /some/path, worlds go in /some/path/worlds_local/ instead, alongside the admin, ban and permitted list files in /some/path. Hosted servers usually set -savedir so the world sits inside the server's own folder where the file manager can reach it.

What is not on the server: characters. Each player's character, inventory and skills are stored on their own machine in characters_local. A world restore never touches a character, which is why a rollback can leave players holding items that no longer exist in the world - and why a corrupted character is a client problem the server cannot fix.

How the server saves#

The world lives in memory and is written to disk every -saveinterval seconds, 1800 by default. A clean shutdown also writes it. Each save does three things in turn:

1. Writes the new world data.
2. Keeps the previous .db and .fwl as .old.
3. Logs a line with the save duration.

World saved ( 912.48ms )

The exact wording has changed slightly between versions, but the line is there on every save. It is the most useful line in the log for this subject, because it tells you when the last good save happened and how long the world takes to write.

Anything that ends the process without that line - a kill, an out-of-memory stop, a host crash - loses everything since the previous one. And anything that ends the process during that line, while the file is half-written, is how worlds get corrupted.

The built-in backup flags#

Valheim has a backup system of its own, configured by three launch arguments:

With the defaults, the first backup happens two hours after the server starts and then every twelve hours, and the four newest are kept. Backups are full copies of the .db and .fwl with _backup_auto- and a timestamp in the name, stored in the same worlds_local folder as the world.

A tighter setup for an active group:

-saveinterval 900 -backups 6 -backupshort 3600 -backuplong 21600

That saves every fifteen minutes, takes the first backup an hour in and then one every six hours, and keeps six - a day and a half of history.

The built-in backups are useful and you should leave them on. They are also not backups in the sense that matters. They sit on the same disk, in the same folder, as the file they protect. They protect against a bad save; they do not protect against a deleted server, a disk failure, a mistaken delete in the file manager, or someone with file access removing the folder. And they rotate, so a problem nobody notices for two days is in every one of them by the time anyone looks.

Raising -backups costs disk space - each one is a full copy of the .db - so on a 150 MB world, twenty backups is three gigabytes. Keep enough to cover the time it takes your group to notice a problem, not more.

Real backups: off the machine and on a schedule#

A real backup is a copy of the world somewhere the server cannot write to, taken on a schedule, and restored occasionally to prove it works. Backups that actually restore makes the long version of that argument; the short version is that a backup nobody has restored is a hypothesis.

The awkward part with Valheim is consistency. The vanilla server has no console you can send a save command to from outside the game - save is an in-game admin command. So a backup taken while the server runs captures the files as of the last save, which is fine, unless a save happens to be in progress at that moment. The clean pattern is to stop the server, take the copy, and start it again:

1. Stop the server. A clean stop writes the world.
2. Wait for the process to exit.
3. Copy worlds_local - or at least the current .db and .fwl - somewhere else.
4. Start the server.

On RE:NODE, the Schedules tab does this without you: a schedule on a cron expression with ordered tasks and delays - a stop power action, a backup a minute later, then a start. Backup slots are included on every Valheim plan, stored off the machine they protect, downloadable, and lockable so a known-good copy is not rotated away. Restoring is a button. One caution worth knowing: deleting a server deletes its backups too, locked ones included, so download a copy of anything you want to keep before cancelling.

cron:   0 5 * * *task 1: power action - stoptask 2: backup (delay 60 seconds)task 3: power action - start (delay 30 seconds)

If you schedule restarts anyway, put the backup straight after the stop, and you get both in one quiet window. Scheduled tasks worth having and cron expressions explained cover the syntax.

Take an extra backup by hand before every game update, before adding or removing a mod, and before changing world modifiers. Those are the moments a world breaks.

Restoring an older save#

Whichever copy you restore from, the procedure is the same.

1. Stop the server and wait until it has fully exited.
2. Move the current files aside rather than deleting them. Rename Midgard.db and Midgard.fwl to something like Midgard.db.broken and Midgard.fwl.broken. If the restore turns out worse, you can go back.
3. Put the chosen pair in place under the world's exact name: Midgard.db and Midgard.fwl. For an automatic backup, that means copying Midgard_backup_auto-...db and its matching .fwl and renaming them. For the previous save, rename Midgard.db.old to Midgard.db and Midgard.fwl.old to Midgard.fwl.
4. Check the world name in the start arguments still matches, capitals included.
5. Start the server and watch the log for the world loading by name rather than a new world being generated.
6. Join and check a recent build you remember, to confirm you got the moment you wanted.

Which copy to use depends on what went wrong:

A panel restore replaces the server's files with the backup's in one step, which covers steps 2 to 3. It restores everything in the backup, not just the world, so if you changed mod configs since then, those revert too.

Recognising a corrupt world#

Corruption shows up in a few recognisable ways.

The server generates a new world. The log reports a new world being created instead of loading yours. Usually this is not corruption at all: the world name does not match the file name, so the server made a fresh world beside the old one. Check the name before anything else; your original files are still there.

The server fails to start, with an exception during world load. The .db is damaged - typically truncated because the process died or the disk filled mid-save. The .db file may be much smaller than it should be, or zero bytes.

The world loads but something is wrong. Terrain does not match the buildings (a .db paired with the wrong .fwl), or a large area has reverted (the server ran for hours without a successful save, then restarted). These are not corruption in the strict sense, but the cure is the same: restore a known-good pair.

The world loads but players report missing items. Check whether it is the world or their characters. Chests and builds are in the world; inventories are on each player's machine. A player whose inventory reset has a client-side character problem.

The quickest check on a suspect file is its size. List worlds_local with sizes and compare the .db with .db.old and the latest automatic backup. A current .db far smaller than its neighbours is the corrupt one.

$ ls -lh ~/.config/unity3d/IronGate/Valheim/worlds_local/

What causes corruption, and how to stop it#

Almost every corrupt Valheim world traces back to a save being interrupted.

• Killing the process. Force-killing a server - the panel's Kill rather than Stop, or kill -9 - mid-save leaves a half-written file. Use Stop, and wait.
• Out of memory. A container stopped at its memory limit dies wherever it happens to be, including mid-save. Saving briefly needs extra memory, so a server running near its limit is most likely to be stopped exactly then. On RE:NODE a server at its limit is stopped and restarted clean rather than swapped, which is the right behaviour for the machine but is still an unsaved stop; watch the memory graph and move up a tier before it happens, and read why your game server keeps restarting if it already does.
• A full disk. A save that cannot finish writing produces a truncated file. Rotating backups and old logs fill disks slowly; check free space when you raise -backups.
• Mods writing to the world. Mods that add custom data can leave a world that only loads with that mod present. Removing such a mod can make objects vanish or the world refuse to load. Back up before changing the mod list - Valheim mods with BepInEx covers the safe way.
• Editing world files in external tools. World editors are useful, but a file edited and saved by an out-of-date tool can be unreadable to the current game. Edit a copy.

Shortening -saveinterval does not prevent corruption, but it does shrink how much a bad stop costs, and it makes the .old pair more recent.

Testing a backup before you need it#

Restoring a backup for the first time during an emergency is how people discover their backups were empty, or the wrong world, or six weeks old. Test one on a quiet evening:

1. Download a backup from the panel or copy it off the server.
2. On your own PC, put the .db and .fwl pair into your local worlds_local folder under a test name - rename both files consistently.
3. Start Valheim, choose Start Game, select the world, and tick Start Server so it runs locally.
4. Walk to the main base and check it is the state you expect.

This takes ten minutes and turns a hope into a fact. Testing a restore before you need it has a fuller drill for any game.

FAQ#

How far back can I roll a Valheim world?

As far as your oldest copy. The .old pair is one save back; automatic backups reach back -backups times -backuplong seconds, two days with defaults; off-machine backups reach as far as you keep them. Anything older than all three is gone.

Do backups include players' characters?

No. Characters live on each player's computer, not on the server. A restore rolls back the world - builds, chests, terrain, tamed animals - but each player keeps the inventory and skills they have now.

Can I restore just one base instead of the whole world?

Not with vanilla tools. The world is one file and a restore is all of it. World editors can copy areas between files, but that is fiddly and risky; take a backup of the current state before trying.

Why are the automatic backups not enough?

They sit on the same disk and in the same folder as the world. They survive a bad save but not a deleted server, a disk failure or a mistaken folder delete, and they rotate quickly enough that a problem noticed late is in all of them.

The server made a new world after an update. Is mine gone?

Almost certainly not. Check worlds_local - the old files are usually still there and the world name in the start arguments no longer matches them. Correct the name and restart.

How big do Valheim backups get?

Each one is a full copy of the .db, so roughly the size of your world: a few megabytes early on, often 50 to 150 MB for a long-lived world. Multiply by the number you keep.