Valheim 1.0 "[Old Format]" and "Missing DB": Recover Your World

Valheim 1.0: world shows "[Old Format]" or "Missing DB"

Valheim 1.0 shipped on 9 September 2026. Within hours the same two reports started appearing: saves tagged [Old Format] in the Manage Saves list, or a world tagged Missing DB that will not start. Every backup made before the update carries the [Old Format] tag, which is the part that makes this feel unrecoverable.

In most cases nothing is lost. [Old Format] is not a problem at all, only a description of the file, while Missing DB is a real one with a fix, and the worst outcome usually comes from acting on the wrong one. Work out which label you are looking at first.

Before you touch anything

Copy the whole save folder somewhere else, right now, before you try any fix on this page. Not a move, a copy. Every recovery below is safe, but the failure mode people report is a well-intentioned fix applied to the wrong problem, on the only copy they had. If your world lives on a hosted server, take a manual backup before you start rather than relying on the last scheduled one.

What each label actually means

"[Old Format]" means the backup is in the pre-1.0 file format

The game files are specific about this label. It appears in the Manage Saves list, on world backups only: Valheim adds [OLD FORMAT] to any backup that is still a .db and .fwl pair, the way every world was stored before 1.0. Your current save never carries it, and neither do characters.

That is why it lands on so many entries at once after the update. Every backup made before 1.0 is a pair, and so is the copy of your world the game keeps when it first saves it in 1.0 (more on that below). The tag says "this file uses the old layout", not "this file is broken". Those backups restore normally, and a restored one is converted again the next time the world is saved.

The 2022 "old file structure" notice is a different thing

Saves still in the folder Valheim used before its Cloud Save patch of 20 June 2022 show a different warning when you select them: the file "is currently kept in the old file structure" and "will be moved to the Cloud on your next save". That one is about where the file lives, not its format, and it clears itself on the next save. The game's own advice is to use Move to local instead if you want the file kept out of Steam Cloud, which it recommends mainly for dedicated servers.

First, the thing that changed at 1.0: a world is now a folder

Before 1.0 a world was two files sitting side by side. Valheim 1.0 writes each world as its own directory, in a chunked format. Verified on live 1.0 servers:

worlds_local/
  MyWorld/                          the world, now a directory
    _main.5.fwl2                    metadata: name, seed, owner
    _main.5.db2                     world data
    _main.5.chunks                  chunk index
    _main.5.ok                      written when a save completes
    1e_20__1_1.chunk  ...           terrain, one file per chunk
  MyWorld_backup_auto-20260909-155858/   backups are directories too
  MyWorld_backup_20260909-150234.db
  MyWorld_backup_20260909-150234.fwl     your pre-1.0 world, kept as a backup

Four consequences, and they are the source of most of the confusion:

• Your old files are not deleted. The first time the world is saved on 1.0, Valheim renames the legacy .db and .fwl to MyWorld_backup_ followed by the date and time, in the same folder, and writes the new directory beside them. Nothing is destroyed by updating, and that renamed pair is your world exactly as it was before 1.0.
• Conversion happens when the world is next saved, not when the server updates. We watched a world last saved in August get a fully populated directory the moment it was played on 1.0.
• An empty world folder is normal. If the directory exists but has nothing in it, that world simply has not been saved since the update. We found 60MB worlds sitting safely in their legacy files next to an empty new folder. Do not read an empty folder as a lost world.
• The four files of a save travel together. Each save writes _main.<n>.fwl2, .db2, .chunks and .ok with the same number. When Valheim reads its saves, it keeps the newest complete set in each world folder and deletes every other _main file in it. A folder with no complete set loses all of them, so copying only the .db2 and .fwl2, the way a .db and .fwl used to be copied, gets them deleted. Copy the whole folder.

If you host with someone who asks you to upload a world, you now upload the whole directory, not a pair of files. That is why a world you created today looks nothing like the ones you uploaded before.

What the uploader accepts

The archive may contain one world folder, a nested world folder, or the whole saves folder. These are the two cases worth checking before you upload.

• The world folder is empty or incomplete. Extra nesting is okay: Supercraft finds a complete world folder at any depth. The folder must contain one matching generation of _main.<n>.fwl2, _main.<n>.db2, _main.<n>.chunks and _main.<n>.ok. If the .ok marker or data files are missing, load the world once in 1.0, let it save, then upload again.
• You zipped the whole saves folder. Because 1.0 keeps the legacy files, that folder holds your current world as a directory and its pre-1.0 self as a .db and .fwl pair, under the old name until the world is first saved on 1.0 and as a _backup_ pair after that. Supercraft selects the complete 1.0 folder, ignores the stale pair, and skips backups. Uploading the world folder on its own is still the clearest option.

An empty or incomplete world folder will be refused, and that refusal is correct. It means the world has not completed a save under 1.0 yet, so the real world may still be in the legacy files beside it. Load the world once in 1.0, let it save, then upload.

Whole areas emptied of buildings

Patch 1.0.17, 6 October 2026: Iron Gate fixed a rare bug in this format that could erase all objects in parts of the world when one large world save chunk file was split into smaller ones. The fix stops it happening again. It does not bring back an area that was already emptied, and players were still reporting empty areas after it shipped.

The way back is a backup from before the area was emptied, and time works against you. A server keeps four automatic backups by default: one about two hours old and three more twelve hours apart (see restoring a backup for the settings). That reaches back roughly a day and a half of the server running, so an area emptied a week ago is in none of them. Look further back: copies you made yourself, or your host's own backups. Restoring takes the whole world back to that point, so anything built since is lost with it.

"Missing DB" means half the world file pair is absent

This section is about the pre-1.0 format, which is still what you have until a world has been saved under 1.0. In that format a world is two files that must travel together:

• WorldName.db is the world itself, every building, terrain edit and dropped item.
• WorldName.fwl is the metadata, essentially the seed and name.

Missing DB means the .fwl says the world has been saved, and the .db that save wrote is not beside it. The world appears in the list as [MISSING DB], because the list is built from .fwl files, and its Start button stays greyed out, because the actual world data is not there. The two files must also have matching names.

In practice the label belongs to the pre-1.0 pair. A 1.0 folder that is missing one of its files is discarded rather than listed, which is the four-files rule above. A server on 1.0 that logs a missing .db is a different situation, covered further down.

Fixing "[Old Format]"

There is nothing to fix and nothing to convert by hand. Valheim converts a world itself the first time it saves it in 1.0, and the tag stays on the old backups because they are old.

• Keep the backup with the conversion date. It is the MyWorld_backup_ pair from the moment your world was first saved in 1.0, and it is your world exactly as it was before the update. Keep it until you are sure the converted world is fine.
• Restoring an [Old Format] backup works. In Manage Saves the game first renames your current save to MyWorld_backup_restore- plus the date, then puts the backup in its place, so nothing is thrown away. The restored world is converted again on its next save.
• New backups lose the tag on their own. Backups made from a 1.0 save are folders, so they carry no tag.

If a world also misbehaves and you run mods, load it once with every mod disabled before you conclude anything is wrong with the save (see the mods section below).

Fixing "Missing DB"

Start from what the label proves: the world data existed, and has been deleted, moved or separated from its .fwl.

A world that was never saved cannot show it

A new world's .fwl records whether the world has been saved yet, and Valheim only reports Missing DB when it says yes. Until the first save, which on a dedicated server is the first autosave (thirty minutes in with the default save interval) or a clean stop, the file says no world data exists. A server that crashed before then simply starts the same world again from its seed. So the label always means a save was written and is now missing, which is why it is worth looking for.

To get that first save in early on a fresh world, join as an admin (your ID on the server's admin list), type /save in the chat and wait for "World saved". Anyone else gets "You are not admin"; the command still saves their own character, but not the world. Stopping the server normally saves the world too, so restart it from your host's panel rather than killing the process.

Finding the missing .db

The .db almost certainly exists somewhere, and you do not have to find it by hand. Our Valheim World Recovery tool reads a world folder, pairs every .db with its .fwl, ranks the copies by save time and integrity, flags orphans, and hands back the newest intact pair as a ready-to-upload world. It runs entirely in your browser and never modifies your originals.

It reads the 1.0 folders too. Point it at your worlds folder and it lists each 1.0 world, picks the highest save generation that finished writing (the one with its .ok file), and shows your pre-1.0 pair as what it is, a frozen rollback point from before the update rather than a newer save. The one thing it cannot see is a completely empty world folder, because there are no files for the browser to hand over. That is the not-yet-saved case described above, and it is normal.

If you would rather do it manually, look in this order:

1. Beside the .fwl. Check for WorldName.db.old, which is Valheim's own previous-save rotation, and for files whose names no longer match.
2. Among the backups beside it. Valheim keeps them in the same folder, named WorldName_backup_auto- plus the date and time. Read timestamps carefully and take a .db and .fwl from the same timestamp. A mismatched pair is a new problem rather than a fix.
3. In the other save location. A world can be half-migrated between the local and cloud folders, leaving one file in each.

Copy the matched pair back into the worlds folder, keeping the original names, and load it.

"[MISSING META]": the reverse case

This label also belongs to the pre-1.0 pair, and it is the opposite of Missing DB: the .db with your world in it is there, and the small .fwl beside it is not. The .fwl only holds the world's name, seed, world modifiers and its ID, so this is the easier of the two to fix. In Manage Saves the same thing shows on a backup as [MISSING META FILE].

Valheim can do it for you. Select the world and press Start, and the game asks: "This world save is missing its meta file. Would you like to restore it from the most recent backup?" Yes copies the .fwl of your newest backup that still has one next to the .db. If it answers "No suitable backup was found!", do the same by hand: take the .fwl from any backup of the same world, put it beside the .db and give it the same name. Use one from this world, not from a new world made with the same seed: the world's ID in the .fwl is what your characters' maps and bed spawns are tied to.

A dedicated server has no menu to offer that, and treats the world as unusable, which leads to the next section. Fix the file before you start it.

A 1.0 server log says "missing .../<world>.db"

This one confuses people who have already moved to 1.0, because the server seems to be looking for the old format. It is not. When a dedicated server starts, it looks for the world named in -world. If it finds no usable world by that name, it creates a new world under the same name, with a random seed, and the missing line is that new, empty world loading. The lines around it tell the story:

Get create world MyWorld
Failed to load world with name "MyWorld", data error MissingDB.   only when the world was found but unusable
 creating
Load world: MyWorld (MyWorld)
  missing /.../worlds_local/MyWorld.db

A normal start of a 1.0 world shows ZNet.LoadWorld: MyWorld (MyWorld), save number followed by the number of your latest save instead. A world still in the pre-1.0 format shows Load world: MyWorld (MyWorld) with no missing line after it.

1. Copy the save folder now, while the server is still running. The new world is saved under your world's name at the next autosave and again when the server stops, and when your world's folder was skipped, it writes into that same folder, where its files can replace some of yours.
2. Find out why the world was not picked up. There are four causes:
   • The name does not match. -world has to match the world's folder name, or the name of its .fwl, inside worlds_local in the save location the server uses (-savedir). Capitals do not matter.
   • A stray file in the world folder. Any file whose name starts with _main. but has no save number where the number belongs, such as _main.5 - Copy.db2 or _main.5.db2.bak, makes the server log Failed to parse files for save and skip the whole folder. Move that file out.
   • No complete save in the folder. The four-files rule above: an incomplete set is deleted, not loaded. Put a complete one back from a backup.
   • The world is there but unusable. The Failed to load world line names the reason: MissingDB and MissingMeta are covered above, and for Corrupt, BadVersion or LoadError, restore a backup.
3. Fix the cause and start the server again, and check for the ZNet.LoadWorld line with your save number rather than creating. If the new world was already saved, its files carry a low number (_main.1, _main.2). Valheim keeps the highest-numbered complete save in a folder, so in a folder that also holds your real save the new one is dropped on the next start. A folder that holds only the new world has to be moved out.

"World load failed ... Check backups!"

These mean Valheim opened the world, could not read it, and stopped rather than risk saving over it:

• World load failed early. Exiting without save. Check backups! The world data carries a version this build does not read: newer than it understands, such as a world last saved by a public-test build, or older than the oldest version it still supports.
• World load failed mid-file. Exiting without save. Check backups! Reading the world data failed partway through, which points to a damaged or incomplete file.

Either way the log then says World db couldn't load correctly, saving has been disabled to prevent .old file from being overwritten. and the game or server closes without saving. Starting it again will not clear it, because the same file fails the same way.

1. Copy the save folder before you change anything.
2. For "early" after a branch switch, load the world with the build that last saved it.
3. Otherwise restore the newest backup that loads. In the game, use Manage Saves: Valheim renames the current save to MyWorld_backup_restore- plus the date before it restores, so nothing is thrown away. On a server, move the broken world folder aside and copy the newest MyWorld_backup_auto- folder in under the world's name. A 1.0 world folder keeps only its latest save, so its backups are the fallback. For a pre-1.0 world, the .db.old and .fwl.old beside it are the previous save, which is the .old file the message means.

Gear on armour and item stands

Items on armour stands and item stands lost their upgrade level, durability and variant when a world was converted to the 1.0 save format before Hotfix 1.0.12 (11 September 2026). Iron Gate confirmed it in Patch 1.0.15 on 18 September: the data was lost in the conversion, and since 1.0.12 any world converted keeps it. Most people only notice when they take an item down, so an affected base can look untouched until you rearrange it.

No later patch puts the levels back on an item that already lost them. Iron Gate's two workarounds both use the backup made when the world was converted, which is the MyWorld_backup_ pair with the conversion date described above:

• Roll back to it. Restore that backup over the world. Everything done in the world since the conversion is lost.
• Fetch the items from it. Copy the backup pair, rename the copies to a new world name such as MyWorldOld.db and MyWorldOld.fwl, and load that world. Take the affected items off the stands onto your character, go back to your main world and swap them for the damaged ones. Characters carry their inventory between worlds, which is what makes this work. On a dedicated server, point -world at the copy for that session, then back.

If you were running mods

Our 1.0 mod compatibility tracker combines Thunderstore build dates with what players report after testing, including the mods that work fine despite having shipped no 1.0 build. Treat anything not listed there as unverified rather than broken. Iron Gate's own position is that with no official mod support they cannot guarantee any mod is functional at 1.0.

Before you remove an inventory or equipment mod, empty its slots. Gear left in mod-added equipment or quick slots can disappear when the game loads without that mod, and players lost armour that way on launch day. That is a separate loss from anything happening to your world file.

Launch day produced some genuinely alarming symptoms from stale mods, including a character duplicating itself repeatedly until the game had to be killed. If your world misbehaves after 1.0 and you had mods, remove the mod loader entirely rather than disabling plugins one by one, then load the world vanilla before concluding anything is wrong with the save.

Does an old world even work at 1.0?

Yes. Existing worlds keep working and receive new content, but Deep North terrain only generates in areas nobody has explored yet. If your crew has already ranged far north, that ground is fixed as it was and the new biome will not appear there. Iron Gate's 1.0 FAQ recommends a fresh world for the best experience, which is a recommendation about content rather than a warning that old saves break.

That trade-off, and how to run both worlds side by side rather than choosing, is covered in new world or continue at 1.0 and Deep North world compatibility.

What actually prevents this

Every recovery above depends on having a copy from before the update. The reports that end badly are the ones where the only backup was the world itself.

If mods are the suspect, the World and Modpack Doctor reads a modpack against a world and reports which plugins are implicated, which is faster than pulling them one at a time.

On a Supercraft Valheim server, daily backups run automatically and you can take a manual one before any update from the panel, so the pre-1.0 state stays available while you experiment with the current one. Restoring is a panel action rather than a file hunt. Uploads take a world in either format: a 1.0 world folder, or a pre-1.0 .db and .fwl pair, which stays intact as a pair. If you are recovering a world right now, restoring a backup and uploading a world cover the mechanics.

Related

• INCOMPATIBLE_VERSION after an update, when the world is fine but the client and server are on different builds.
• Creating backups and restoring a backup.
• Valheim 1.0, what shipped and what it changes for a server.