If a familiar server opens a new landscape or an older base after an update, stop normal play before copying anything over it. First establish which world the running process selected and where that process reads its data. A reachable server with the expected display name can still be loading another world.
This guide covers dedicated servers, the Valheim 1.0 save-format change and older backups. Have the startup definition, service account/container configuration, logs and retained data. Recover on copies; preserve pre-update originals and the unexpected current data.
Preserve the state before another restart#
Ask players to disconnect, stop the server gracefully through its existing management procedure and preserve the logs before rotation. Confirm that the writer has stopped. Copy the complete actual save root to a separate protected location, together with its launch configuration, build, branch and mod versions. Keep backups outside the active save directory and preferably off the host.
Do not let repeated test starts generate saves into your only candidate directory. A new empty world is evidence to retain, not a file to merge into an older world. Distinguish different terrain, familiar terrain without buildings and an older checkpoint.
Compare the world argument with the display name#
Iron Gate's dedicated-server manual distinguishes -name, the server's displayed name, from -world, the world to load or create. An update may have replaced a startup script or a service may use a different script than the one you edited.
Inspect the effective launch definition. For example, these are argument fragments, not a complete startup command:
-name "Friends server"
-world "Midgard"
-savedir "/srv/valheim-data"
Friends server identifies the server in a list; Midgard selects the world. Replace both examples with the intended values. Check spelling and capitalization against the retained data. Do not change a known world name merely to make it resemble the display name.
Read the startup log for the selected world, save path when reported, loading failures and world creation. Retain those lines. A successful process start does not prove it found your settlement and progression.
Resolve the save root as the actual server account#
-savedir overrides the save root, which contains world and permission data. It is not simply the path to one world file. With the documented layout, worlds_local sits under that root; pointing -savedir at worlds_local itself can make the process look in a different place than intended.
When the flag is absent, default paths depend on the user running the server. On Linux, the documented root is ~/.config/unity3d/IronGate/Valheim; on Windows it is under that account's %USERPROFILE%\AppData\LocalLow\IronGate\Valheim. Your desktop account's files may have nothing to do with a system service account's home or profile.
Check the service's configured user and effective launch path. For a container, inspect its real persistent mount and the path inside the container. Verify that the selected account can read the intended world and write its own saves. Correct the specific ownership or mount problem; opening the whole directory to everyone is not a recovery procedure.
In a post-1.0 migration discussion, a running server did not recognize the transferred world. The thread does not establish one path that fixes every deployment.
Keep a whole backup generation together#
Valheim 1.0 uses chunked world storage. Its developer release notes confirm the new system; the earlier save-system announcement explains world folders and separate backup folders. Current recovery must preserve the complete world folder and its related files, not only the two filenames found in an old tutorial.
For a legacy backup consisting of Midgard.db and Midgard.fwl, retain both from the same coherent checkpoint. Do not combine metadata from one backup with world data from another. For a folder-based world, restore the whole selected generation. Do not rename individual missing chunks to match an error or assemble a new set from whichever files have the newest timestamps.
Keep the complete save-root backup as your safety copy while making a separate recovery candidate. If the source came from a player's cloud-managed world, use that game's supported save-management controls to obtain a complete local copy; do not assume a cache or partial cloud download is the world.
Check versions before calling the save corrupt#
Record the executable actually running, not only the updater's success message. Compare the server/client builds, stable versus public-test branch and required mod environment. Preserve the original mod files and configuration before experimenting. A newer executable may convert world data; choosing an older binary does not reverse the conversion.
Missing objects can also be a data defect rather than a selection error. Patch 1.0.17 fixed a rare object-loss bug during chunk splitting. That does not prove an existing affected world repairs itself after updating. Retain the incident data and check the relevant developer notes before choosing a recovery point.
Validate a copied recovery world before returning players#
Load the recovery candidate in an isolated instance with compatible software and a separate data root. Confirm the intended terrain, recognizable buildings, chest contents and progression. Make a harmless change, complete a save, restart and verify it persists. Stop before replacing live data if any of those checks fails.
If rollback is necessary, pair the appropriate executable and mods with a matching pre-conversion backup. Explain which later progress will be lost and obtain the group's agreement before switching the live session. Keep originals until the replacement has been accepted.
For several self-hosted games, Nexardo's workflow can help identify instances. Retain the world name, save root, service account and verified backup generation.
