Minecraft Bedrock World Management: Uploading Worlds, LevelDB and Safe Backups

The world is the only thing on a Bedrock server that cannot be re-downloaded, and Bedrock stores it in a way that punishes the obvious approach. There are no region files. There is no DIM-1 folder. The entire world — every dimension, every chest, every player — is one embedded database, and copying that database out from under a running server is the standard way to end up with a backup that will not open.

This guide covers where Bedrock Dedicated Server keeps its worlds, what the files inside a world folder actually are, how to move a world off a phone or a PC and onto the server, seeds, and the three-command sequence that is the only safe way to copy a live Bedrock world. For first boot and connecting see Setting up your Bedrock Minecraft server; for the settings named below see Bedrock server.properties: The Complete Key Reference. The Java Edition equivalent of this page is Minecraft World Management, and almost none of it applies here.

Back the server up before every operation on this page

Everything below either replaces world data or copies it while it is being written. Snapshot from the Backups tab first — see How to create a backup. Bedrock worlds are small, so there is no excuse not to.

Verified against Bedrock Dedicated Server 1.26.44.3

File names, console messages and error strings below were read on 19 August 2026 out of the official BDS 1.26.44.3 archive — its bedrock_server_how_to.html manual, its server.properties, the en_US.lang catalogue in resource_packs/vanilla/texts/ and the server binary's own string table — plus a real exported Bedrock world published by Microsoft. 1.26.44.3 was the build Mojang's download API was serving on that date.

Where the Server Keeps Its Worlds

BDS creates a worlds/ folder on first start. Every world is a subfolder of it, named by level-name in server.properties:

level-name=Bedrock level
level-seed=

level-name does two jobs at once. It is the folder the world lives in, and it is the switch that selects which world the server runs. Only one world is active at a time. There is no Multiverse equivalent, no console command to load a second world, and no way to run two worlds from one BDS process — switching worlds means editing level-name and restarting.

The shipped default is Bedrock level, spaces and all. The allowed values, per the comment in Mojang's own file, are any string without a semicolon or a character illegal in a filename: /\n\r\t\f`?*\<>|":

level-name is matched exactly, capitalisation included

BDS runs on Linux here, and Linux filenames are case-sensitive. MyWorld, myworld and My World are three different folders. If level-name does not match an existing folder character for character, the server does not error — it quietly generates a brand-new empty world at that path and starts it. A server that "lost the world" after an upload has almost always done this.

Inside a Bedrock World Folder

A Bedrock world is a small, fixed set of files. This is a real one, published by Microsoft as a sample world, unpacked:

Note what is not there. No region/, no DIM-1, no DIM1, no playerdata/, no datapacks/, no session.lock. Bedrock keeps all of that inside db/.

level.dat and levelname.txt

level.dat is NBT, but not Java's NBT. It is little-endian, and it carries an eight-byte header before the tag data: a storage-version integer followed by the payload length. The sample world above reports storage version 9 and a 2,507-byte payload in a 2,515-byte file. Inside it are LevelName, RandomSeed, SpawnX/Y/Z, GameType, Difficulty, commandsEnabled, NetherScale, the abilities block that defines what a default player may do, and every game rule. A Java NBT editor will not open it.

levelname.txt is the same name in plain text, and it is the one file you can read without tooling. That makes it the fastest way to identify a world folder whose name means nothing to you — which, as the next section shows, is the normal case on a client device.

Three names are in play and they are all independent:

level.dat_old is a real safety net, and the server will use it

BDS checks it automatically. Its own messages include "level.dat missing, found level.dat_old" and "level.dat corrupted/unreadable, level.dat_old used instead". If both are gone or unreadable you get "level.dat corrupted/unreadable, level.dat_old ALSO corrupted. Unable to load." Never delete level.dat_old to save space.

The db/ Folder Is a Database, Not a Pile of Chunks

Bedrock stores the world in a Mojang fork of Google's LevelDB, with zlib compression added. A db/ folder holds:

• .ldb files — sorted, immutable data tables. Once written they are never modified, only replaced by compaction.
• .log files — the write-ahead log holding recent changes not yet folded into a table.
• MANIFEST-<number> — the index that says which .ldb files make up the current database.
• CURRENT — a one-line text file naming the manifest in force. In the sample world it reads exactly MANIFEST-000795.
• LOG and LOG.old — LevelDB's own diagnostic output. Not the world data.

Every dimension lives in the same database. Chunk keys are the chunk's X and Z as little-endian integers, optionally followed by a dimension integer — 1 for the Nether, 2 for the End, omitted for the Overworld — then a one-byte record tag. There is nothing to delete to reset a dimension the way you would delete DIM-1 on Java.

This is why you cannot copy a running Bedrock world

The set of files is not stable. A background compaction can write a new .ldb, write a new manifest, update CURRENT and delete the old tables while your copy is halfway through the folder. What you get is a CURRENT pointing at a manifest that references tables you did not copy, or copied at the wrong length. LevelDB will not open it, and there is no partial recovery — you either have a consistent set or you have nothing. Microsoft's own documentation puts it more bluntly: the .ldb and .log files are "binary and not friendly for editing by hand, so don't touch these!"

Seeds

level-seed behaves the same as Java's: it is read only when the world is first generated. Changing it on an existing world does nothing, because the chunks already in the database stay exactly as they are and only new terrain uses the new value, leaving a visible seam.

Leave it empty for a random seed. Reading the seed back out is harder than on Java: /seed is a Java Edition command and does not exist on Bedrock, and there is no SeedCommand in the dedicated server binary at all. The value is stored in level.dat as RandomSeed, so the practical route is to open a copy of the world in a Bedrock client, where the world settings screen shows the seed with a Copy seed button.

What Bedrock does not have is any of Java's other world-generation keys. There is no level-type, no generate-structures and no generator-settings in a Bedrock server.properties — flat worlds, world type and generator options are chosen in the client's world-creation screen and baked into level.dat. On a dedicated server, that means the only way to get a flat or otherwise non-default world is to create it on a client and upload it.

Uploading an Existing Bedrock World

Finding the world on a client

Bedrock worlds live under a folder called com.mojang, and the world folders inside it have machine-generated names like eplC8tYRD04= that tell you nothing.

On Windows every signed-in account gets its own com.mojang, so check you are in the right user's folder. On Android the path above is the external one, which only holds worlds if the game's File Storage Location option is set to External; the internal directory is not readable without root.

To work out which folder is which world, open the levelname.txt inside it. That file contains the world's display name in plain text.

There is no equivalent path on Xbox, PlayStation or Switch. Those platforms expose no file system, so a world that only exists on a console has to be exported through the game — or the account's cloud storage — before any of this applies.

The cleaner route from any platform is to export the world from inside Minecraft, which produces a .mcworld file. That is a renamed ZIP: the sample world Microsoft publishes unzips to exactly db/, level.dat, level.dat_old, levelname.txt and world_icon.jpeg with no wrapper folder.

Putting it on the server

1. Take a backup of the server as it stands from the Backups tab, so you can get back if this goes wrong.

2. Stop the server and wait for the process to exit. Do not skip this.

3. Unzip the .mcworld locally. You need the folder that contains level.dat, not the archive.

4. Rename the folder to something you will recognise, avoiding special characters. Microsoft's own advice is to make it "something more sensible" than the exported name.

5. Upload the folder into worlds/ using the File Manager, or over SFTP for anything above a few hundred megabytes — SFTP is faster and resumes interrupted transfers. Upload the folder itself, not its contents.

6. Point the server at it by setting level-name to the folder's exact name:

   level-name=My Great World
   

7. Start the server and watch the Console for it loading rather than generating, then join and confirm you land somewhere you recognise.

A world saved by a newer client will not load

Bedrock refuses to open a world from the future, reporting "A newer version of the game has saved this world. It cannot be loaded." There is no downgrade. If your phone updated to the next drop before you exported, you need a server on that version — see the version note in Setting up your Bedrock Minecraft server. The reverse direction is fine: an older world is upgraded on load, and that upgrade is one-way.

What carries over and what does not: the terrain, builds, chests, game rules, difficulty, spawn point and seed are all inside level.dat and db/, so they come with the world. Operator status does not — permissions.json is a server file keyed by XUID, not part of the world, so you op yourself again after the move. See Bedrock Allowlist and Permissions.

Backups: save hold, save query, save resume

BDS can hand you a consistent copy of a world it is still running, and this is the only supported way to do it. Mojang's manual describes the three commands as making "atomic backups while the server is running", and is candid that it is "not particularly friendly for taking manual backups, but works better when automated".

Run from the panel Console, without a leading slash:

> save hold
Saving...
> save query
A previous save has not been completed.
> save query
Data saved. Files are now ready to be copied.
> save resume
Changes to the world are resumed.

The critical detail is in the middle. Mojang's manual is explicit: "The server will not pause while this is happening, so some files can be modified while the backup is taking place. As long as you only copy the files in the given file list and truncate the copied files to the specified lengths, then the backup should be valid."

That is what the numbers beside each filename are for. The file list comes back as path:length pairs. The server keeps running, so a .log file will usually have grown by the time you get to it — copy the whole thing and you have a log carrying records the manifest does not account for. Truncate it to the stated length and you have exactly the state the server promised you. The lengths are not advisory.

So the working sequence is:

1. save hold
2. save query, repeatedly, until it stops answering "A previous save has not been completed."
3. Copy each listed file, truncating it to its stated length
4. save resume

Do not leave a server sitting between hold and resume. During that window the server is not removing superseded files, so disk use only grows.

The panel's Backups tab is still the right primary tool

The three-command dance exists for scripted, hot backups. For day-to-day safety, the Backups tab snapshots the whole server volume and is the thing to use — see How to create a backup. Bedrock worlds are small, so keep several. If you want an off-platform copy as well, stop the server and pull the world folder down over SFTP; with the server stopped, a plain copy is safe.

The same three operations are exposed to add-on scripts through @minecraft/server-admin, as saveHold, saveQuery and saveResume, which is how automated backup add-ons work.

Java and Bedrock Worlds Are Not Interchangeable

A Java world is a folder of .mca region files with big-endian NBT and a level.dat that is gzipped Java NBT. A Bedrock world is a LevelDB database with little-endian NBT and a level.dat that has an eight-byte binary header in front of it. They are not two dialects of one format; they are two different storage engines that happen to store a similar game.

Neither server will open the other's world. Uploading a Java world into worlds/ gives you a folder with no db/, and BDS treats it as a world it cannot read.

The one route across is conversion, and the tool is Chunker — an open-source converter that Microsoft documents on Learn while noting it is "provided by external, third-party contributors and is not a Mojang/Microsoft offering". The current release is 1.19.1, published 3 August 2026. It runs locally as a desktop app or a CLI, and it is honest about the limits.

Chunker converts:

• Level settings, world data (blocks, biomes and tile entities), multiple dimensions, containers and items, and in-game maps.

Chunker does not convert:

• Entities, and player inventories.

That second list is the one to read twice. Every mob, every item frame, every armour stand, every minecart and every player's inventory is lost in an edition conversion. Redstone contraptions and command blocks frequently need rework too, because the two editions do not tick identically. Convert a build showcase; do not convert a live survival server and expect people's chests to be intact — the chests survive, the mobs and the inventories do not.

If what you actually want is Java and Bedrock players in the same world, converting is the wrong answer entirely. Run one Java server with a Bedrock bridge in front of it — see Setting up CrossPlay for Minecraft.

Resetting and Multiple Worlds

A fresh start. Set level-name to a name that does not exist yet and restart. The server generates a new world in a new folder and the old one is still on disk, untouched, if you change your mind. This is safer than deleting anything.

Switching between worlds. Stop the server, change level-name to the other folder, start. Both worlds remain on disk; only one is live. Budget the disk for it.

Resetting only the Nether or the End. There is no supported way to do this on Bedrock. Both dimensions live in the same LevelDB database as the Overworld, keyed by a dimension integer, so there is no folder to delete. Java's DIM-1 trick has no Bedrock equivalent, and any tool claiming to do it is editing the database directly, with everything that implies. Back up first, twice.

Several worlds at once. Not possible in one BDS process. Running a survival world and a creative world simultaneously means two servers.

Common Issues

• The server generated a new empty world instead of loading mine. level-name does not match the uploaded folder exactly. Check it character by character, capitalisation included, in the File Manager.
• The world folder is there but the server ignores it. The upload landed in the server root rather than inside worlds/, or the archive was unzipped with an extra wrapper folder so level.dat is one level too deep.
• "A newer version of the game has saved this world." The world was last opened by a client newer than the server. Update the server; there is no downgrade path.
• Restored backup will not load. It was copied from a running server without the save hold sequence, or copied without truncating to the listed lengths. LevelDB is all-or-nothing.
• worldError.corrupted — the world "is corrupted and can't be started". Restore the last known-good backup. Check whether level.dat_old survived before you do anything else.
• A Java world was uploaded. It will not load and cannot be made to. Convert it with Chunker, accepting the loss of entities and inventories, or run Java with a Bedrock bridge instead.
• The world is much larger than expected. Bedrock has no max-world-size and no /worldborder. Exploration is unbounded, and view-distance decides how fast players uncover new terrain.
• Ops were lost after moving the world. Expected. permissions.json lives beside the server executable, not in the world.

Sources

• The bedrock_server_how_to.html manual, server.properties, the resource_packs/vanilla/texts/en_US.lang message catalogue and the bedrock_server binary from the official Bedrock Dedicated Server archive, version 1.26.44.3
• Microsoft Learn — Getting Started with Bedrock Dedicated Server
• Microsoft Learn — Create a World Template from an Exported World
• Microsoft Learn — Chunker Overview
• Microsoft's published Sample Parkour World, unpacked and inspected
• minecraft.wiki — Bedrock Edition level format and com.mojang

What to Read Next

• Setting up your Bedrock Minecraft server for first boot, connecting and versions
• Bedrock server.properties: The Complete Key Reference for level-name, level-seed, view-distance and everything else in the file
• Bedrock Add-Ons for the pack files that live in the world folder
• Bedrock Allowlist and Permissions for restoring operator status after a move
• Minecraft World Management for the Java Edition equivalent of this page
• How to create a backup and How to upload files via SFTP for the mechanics used throughout

Made with 💜 by GameServerKings