Minecraft corrupted chunks and recovery

A corrupted chunk is almost always confined to one region file, and the fix is almost always to replace that one file - or the damaged chunks inside it - rather than the whole world. Find the coordinates in the server log, work out which r.X.Z.mca file holds them, stop the server, and either restore that file from a backup or delete the bad chunks so they regenerate. MCA Selector is the tool for the second option. Everything else in this post is about doing that precisely, recognising the errors that look like corruption but are not, and making it unlikely to happen again.

How a Minecraft world is stored#

A Java Edition world is a folder of small files, not one big one. That is why corruption is usually local.

Each region file covers 32 by 32 chunks, which is 512 by 512 blocks. Inside, the file starts with an 8 KiB header - a table saying where each of the 1,024 chunks is stored and a table of timestamps - followed by the chunks themselves, each compressed and stored in 4 KiB sectors.

On Paper and Spigot, the nether and the end are separate world folders: world_nether/DIM-1/region/ and world_the_end/DIM1/region/. On vanilla, they are inside the main world folder at world/DIM-1/ and world/DIM1/. Check which layout you have before looking for a file.

From block coordinates to a region file

The arithmetic is short:

chunk X  = floor(block X / 16)chunk Z  = floor(block Z / 16)region X = floor(chunk X / 32)region Z = floor(chunk Z / 32)

So the block at X -1200, Z 3400 is in chunk -75, 212, which is in region -3, 6: the file r.-3.6.mca. Note the floor: negative coordinates round down, so block -1 is in chunk -1 and region -1, not 0. The F3 screen in game shows the chunk and the region file name directly for wherever you are standing, which is the quickest way to check your sums.

What the log errors actually mean#

Corruption shows up in the server log, often as a stack trace long enough to hide the useful line. These are the common messages and what they point at.

`Chunk file at [x, z] is in the wrong location; relocating. (Expected [a, b], got [c, d])` - a chunk's stored coordinates do not match its position in the region file. Usually the result of someone copying or renaming region files, or an old external tool. The server relocates the chunk and carries on. Not urgent, but find out who moved files.

`Couldn't load chunk [x, z]` followed by an exception - the chunk data could not be read. The exception underneath says why: a decompression error (ZipException, "incorrect header check", "unexpected end of ZLIB input stream") means the stored bytes are damaged; an NBT read error means the data decompressed but is not valid. The server will usually regenerate the chunk, which means terrain or builds there are replaced with fresh generation - check the location in game.

Region file errors mentioning a truncated file or an invalid sector - the region file's header points past the end of the file, typically because the process stopped while writing. Paper attempts to recover a damaged header by scanning the file, and logs that it is doing so; whether the chunks survive depends on how much was written.

Errors naming an entity or block entity - a single bad mob, item frame, chest or sign in an otherwise fine chunk. Often a plugin or mod wrote data the server cannot parse. The crash report's "Entity being ticked" or "Block entity being ticked" section gives the coordinates. Crash reports explained shows how to read that section.

The world is completely new or `level.dat` errors at startup - level.dat is missing or unreadable. That is the one file whose loss affects the whole world, covered further down.

What causes corruption#

Region files are rewritten constantly, which makes the moment of writing the dangerous one. Nearly every case comes down to one of these:

1. The process stopped mid-write. A kill instead of a clean stop, an out-of-memory termination, a host crash. Whatever was being written at that instant may be half there.
2. The disk filled up. A write that cannot complete leaves a truncated file. Backups and logs filling the disk are the usual culprits; disk space covers what eats it.
3. Files edited while the server ran. Uploading a region file, running MCA Selector or an editor against a live world, or restoring a backup into a running server. The server's next save overwrites or interleaves with your change.
4. Version mismatches. Opening a world in an older Minecraft version than it was saved in, or using an external tool that does not understand the current format. Data can be dropped or misread.
5. Plugins and mods writing bad data. A plugin storing malformed data in a block entity or an entity, which the server then fails to load.
6. Genuine storage faults. Rare on modern hardware with checksumming filesystems, but not impossible on cheap machines.

Most of these are preventable, which is the last section of this post.

Finding the damage#

Start from the log. Search it for the coordinates in the error and convert them to a region file as above. If the error gives chunk coordinates (most do), only the second step applies.

$ grep -n "Couldn't load chunk\|wrong location\|region" logs/latest.log | tail -20

On a panel, the console's search or the downloaded logs/latest.log do the same job; older logs are gzipped in the same folder as YYYY-MM-DD-N.log.gz.

Then go and look, carefully. Teleport near the coordinates - not into them - in spectator mode, and see what the chunk looks like: missing builds, freshly generated terrain cutting through a base, a straight-edged hole into the void. A chunk that regenerated in the middle of a build has a sharp 16-block boundary that is hard to mistake.

If several chunks in different regions are affected, look for a common cause before repairing anything. Damage across many regions at the same time points at a disk-full event or a crash, and there may be more than you have found.

Repairing with MCA Selector#

MCA Selector is a free, open-source desktop application for viewing and editing region files. It shows the world as a map, lets you select chunks by hand or by query, and can delete, export or import them. It is the standard tool for chunk-level surgery.

Work on a copy, never on the live server:

1. Stop the server and download the world folder over SFTP, or at least the affected dimension's region, entities and poi folders. SFTP and the file manager has the connection details.
2. Open the world folder in MCA Selector. Corrupted chunks often show as blank or are reported when the tool tries to read them.
3. Select the damaged chunks.
4. Delete them, or import replacements from a backup (the two options are explained below).
5. Save, upload the changed files back to the stopped server, start it, and check the area in game.

The choice in step 4 decides what the area looks like afterwards:

• Delete - the chunks regenerate from the seed on next load. Correct for wilderness, wrong for builds.
• Import from a backup - MCA Selector can import chunks from another copy of the world, so you can take just those chunks from last night's backup and leave everything else at today's state.

MCA Selector's query filter is also the right tool for a different job that looks similar: trimming a world. Selecting chunks by InhabitedTime (how long players have spent in them) finds chunks that were generated but never really visited, and deleting those shrinks a bloated world without touching bases. World border and pre-generation covers why worlds bloat in the first place.

Keep MCA Selector updated. The region format changes between Minecraft versions, and an old copy of any external tool is a cause of corruption rather than a fix for it.

Restoring a single region file from backup#

When the damaged area is a build and you have a backup, restoring the region file is faster than chunk surgery and loses only what changed in that 512-by-512 square since the backup.

1. Stop the server.
2. From the backup, take region/r.X.Z.mca for the affected region. Also take entities/r.X.Z.mca and poi/r.X.Z.mca with the same name, so mobs, item frames, villagers' workstations and beds match the blocks.
3. Copy them over the current files on the server.
4. Start the server and check the area.

What you lose: any building in that square since the backup. What you keep: everything else in the world, and every player's inventory, because inventories are in playerdata, not in the region. If a player stored items in chests inside the restored region after the backup was taken, those are gone; warn them.

On RE:NODE, backups can be downloaded from the panel, so you can unpack one locally, pull out the three files and upload just those through the file manager - rather than restoring the whole backup and rolling back every other player's progress. A full restore is a button when you do need it. Either way, backups that actually restore is the case for testing this before the day you need it.

level.dat and playerdata corruption#

`level.dat` holds the seed, spawn point, game rules and world settings. If it is damaged, the server may create a new world or refuse to start. Minecraft keeps the previous version as level.dat_old: stop the server, rename the damaged file aside, copy level.dat_old to level.dat, and start again. If both are damaged, take level.dat from any backup - it changes little day to day, and an old one only resets world time and a few counters.

Player files live in playerdata/<uuid>.dat, with a .dat_old copy beside each. A player whose inventory vanished or who spawns at world spawn with nothing after a crash may have a damaged file; the _old copy is usually one save behind. Restore it with the server stopped, or with the player offline at minimum, because the server writes the file on logout.

playerdata/  4c2a9b1e-....dat  4c2a9b1e-....dat_old

Preventing corruption#

None of this is complicated, and most servers that lose chunks skipped one of these:

• Stop cleanly. stop in the console saves every world and exits. Killing the process does not. On RE:NODE, the Stop and Restart buttons send a clean stop; Kill does not, and is for a server that has stopped responding.
• Stay inside the memory limit. A server killed for running out of memory has not been stopped cleanly. If your server is repeatedly reaching its limit, that is a corruption risk as well as a stability problem - how much RAM a Minecraft server needs and why your game server keeps restarting explain the signs.
• Keep free disk space. Never let a server's disk fill. Old logs, old backups kept in the server folder and abandoned worlds are the usual space eaters.
• Never edit a live world. Stop the server before uploading, restoring or editing anything under the world folders.
• Take consistent backups. A backup taken while chunks are being written can capture a half-written file. Use save-off, save-all flush, back up, then save-on - or stop the server for the backup - so the copy is consistent. The world backup guide goes through it.
• Upgrade in one direction. Never open a world in an older version than it was last saved in. Before an upgrade, back up; after an upgrade, there is no going back without that backup. Minecraft version upgrades covers the safe order.

save-offsave-all flush# take the backup heresave-on

FAQ#

Can a corrupted chunk spread to the rest of the world?

No. Each chunk is stored independently and a bad chunk does not damage its neighbours. What spreads is the cause: if the disk filled or the server was killed, other files written at the same time may also be damaged, so check the log for more than one error.

Will deleting a corrupted chunk delete my build?

Yes, if the build was in it. A deleted chunk regenerates from the seed as fresh terrain. Use deletion for wilderness and restore from backup for anything players built.

Does Minecraft have a built-in repair command?

Not for damaged data. The server's --forceUpgrade option rewrites every chunk in the current format, which can help with old-format chunks after an upgrade, but it does not repair damaged bytes. Region repair is done with external tools or backups.

My world reset to a new map after a crash. Is everything gone?

Probably not. Check whether level-name in server.properties still matches the world folder, and whether level.dat exists. If level.dat is damaged, restore it from level.dat_old. The region files with all your builds are usually untouched.

Is it safe to run MCA Selector on a live server?

No. Always stop the server first, and work on a copy. The server keeps chunks in memory and will overwrite your changes on its next save, or interleave writes with yours.