Corrupted Valheim World: Recovery Steps That Work

A corrupted Valheim world is not always a lost world. A wrong world name, a different save directory, or an incomplete file copy can look like corruption. Stop the server, preserve the original files, and test one complete candidate in isolation before replacing anything. If every copy is damaged, no rename or hosting plan can recreate progress that is no longer present in a usable save.

Stop before you touch the world files#

If the world stopped loading after a crash, update, transfer, or unexpected restart, do not keep launching the production server to “see if it fixes itself.” A server may generate new files while you investigate, and a save process may replace an older generation. Stop the process cleanly using the operator’s normal shutdown method. Iron Gate’s dedicated-server guide says to stop its server with Ctrl+C in the command window; avoid killing the process while it is writing.

Record the first error and when it appeared. Keep a read-only copy of the current world directory, any automatic backups, and any provider snapshots in separate locations. Do not upload a replacement over the live folder, delete a newly created world, or rename files in your only copy. If the server is hosted, stop it before downloading or replacing a save and confirm that the downloaded archive finished.

Rule out a different world or save path#

First check what the active server is trying to load. In the official launch arguments, -name sets the server’s listing name, -world selects the world to load or create, and -savedir overrides where the server looks for world data. A familiar public server name does not confirm that the old world is open.

Compare those values with the folder you copied. Check the running process or current panel/service configuration, not only an old startup script. Look for a newly created folder, an extra nested directory from an upload, or a -savedir value that points somewhere else. The official guide lists the default Windows and Linux save locations and explains that -savedir changes the location.

An empty or newly generated world can be a path or selection problem rather than a corrupt save. In a separate empty-directory check on the current dedicated server, the log reported a missing .db at the selected path and created a new world there. That does not establish that the intended world was corrupt or erased. Follow the guide to finding the world a Valheim server actually loads if the save name or path is uncertain.

Preserve a complete current world and its backups#

Valheim 1.0 uses a folder-based world save, not only the older single .db and .fwl files. In our current-version dedicated-server test, a clean save folder contained _main.1.db2, _main.1.fwl2, _main.1.chunks, _main.1.ok, and a chunk file. Keep the entire matching world folder together. Do not pair a database from one save generation with a world file or chunks from another, and do not assume an old-format .db.old/.fwl.old rename recipe applies to a 1.0 folder.

Check the time and size of every candidate before testing it. Look for the same world name, a complete folder, and a backup created before the first failure. Preserve the order and names of all files. If a world has both current and older-format copies, keep both separately; do not convert, merge, or delete either one during triage.

Iron Gate documents automatic server backups through -backups, -backupshort, and -backuplong. The manual says the default keeps four backups: one short backup at a two-hour interval and three longer backups at twelve-hour intervals. Confirm the active server’s settings and inspect what copies actually exist; a configured schedule is not proof that a backup completed or contains the needed progress.

Build a recovery inventory before you launch a copy#

Make a short list of every candidate before starting another server. For each one, record where it came from, when it was created or downloaded, the folder name, the selected world name, and the sizes of its files. Keep the server’s current folder, downloaded snapshot, local copy, and any generated “new world” separate. If one candidate is a compressed archive, extract it to a fresh directory and compare the internal structure before you use it; an archive can contain an extra enclosing folder that changes the path the server sees.

A file hash can tell you whether a copy changed during transfer, but it cannot prove that the save is healthy. For example, compare a source and copied file with Get-FileHash on Windows or sha256sum on Linux. Different hashes mean the bytes differ; identical hashes only show that the copies match. Do not “fix” a mismatch by copying one file over another until you know both files belong to the same save generation.

If the candidate is a provider snapshot, confirm the download completed and keep a second copy before asking the panel to restore it. Record the snapshot timestamp and check that it predates the first failed save. These notes help distinguish a usable older recovery point from a partial transfer or a backup created after the damage started.

Test one candidate on a separate server#

Make a working copy of the complete candidate in a different save directory. Use the same current server version, set -world to that copy, and set -savedir to the isolated test location. Give the test instance a different port, keep it private, and use a separate password. Do not let players connect to the production world while you are checking recovery.

Read the test log from the world-load section onward. A successful test should name the selected world and show that the database and chunks loaded, with no load-failure error. Compare a landmark with a player only if the test client can join; a server log alone cannot prove what terrain a player will see. After checking, stop the test cleanly and preserve the successful copy until the owner approves the recovery point.

In a private Windows dedicated-server test on Valheim 1.0.20 (network version 41), a complete copied world loaded from its own -savedir; the log named the loaded world and reported its database and chunks. This verifies server-side loading of that save set, not a player’s view or the state of a different host’s panel.

Read the load error, not just the ready line#

A server can announce itself even when the world failed to load. We tested a separate copy after truncating only its .db2 file. The current dedicated server logged an EndOfStreamException, then:

World load failed mid-file. Exiting without save. Check backups!
World db couldn't load correctly, saving has been disabled to prevent .old file from being overwritten.
Game server connected

The process later skipped its world save. The final line alone would have looked reassuring, but the earlier errors showed that this was not a successful recovery. If your log says the world load failed, saving is disabled, or the database is unreadable, keep that copy untouched and do not let players build on it. Check another complete candidate in isolation.

Error messages can also point to a different problem. A missing world file, permission error, outdated save format, or unrelated server startup failure needs its own diagnosis. Preserve the exact error, server version, selected -world, and effective -savedir; remove passwords, IP addresses, player IDs, and world seeds before sharing the log. If the server never reaches its ready line, use the Valheim startup-failure checklist.

Restore only a known-good copy#

If an isolated candidate loads correctly, stop both servers before changing the live directory. Make one last separate copy of the current files, then check the complete Valheim world-file set before restoring the candidate using the panel or file workflow documented for that server. Confirm the world selector and save path again, start the production server, and inspect its world-load lines before asking players to return. Keep the pre-restore copy until the group confirms the right world and expected progress are present.

If no candidate loads, preserve all versions and ask the game or hosting support team what exact save data and logs they need. Do not run an unverified repair utility on the originals. Any tool you consider should have current documentation for the save format, clear limits, and a workflow that writes only to a disposable copy. A tool can rank or inspect files, but it cannot recreate structures or progress absent from all remaining saves.

Before choosing a managed server, check that you can download a world copy and test a restore without overwriting the active campaign. Game Hosting’s Valheim World tab supports world import and download, plus restore of Valheim’s own automatic backups; those controls still need a usable copy to work. See the Valheim panel details.

A restore test is also a useful way to check the workflow before an emergency. On a quiet day, create or select a disposable world, copy it using the same procedure you would use for a real recovery, and verify that the copied version opens with the intended world selector. Keep the test result with the backup timestamp and the path you used. Repeat after changing a panel, container mount, server version, or storage location because those changes can alter which files are available to the process.

When you return to the campaign, keep the tested backup separate from the active save until the owner decides which restore point to use. If a backup restores but omits recent progress, explain the timestamp and the lost interval before making it live. A backup is a recovery point, not a merge tool that can combine every change made after it was created.

The safest recovery is the newest complete copy that loads in isolation. Preserve the original, test before replacing it, and treat a green server status as only one part of the evidence.