World pre-generation, region pruning, and reclaiming disk
World pre-generation, region pruning, and reclaiming disk
Two distinct operations that solve different problems but get conflated:
- Pre-generation: generating chunks in advance to avoid in-play stutter.
- Region pruning: deleting unused chunks to reduce disk use.
Both are useful. Both are easy to do wrong.
When to pre-generate
See the dedicated pre-generation article (#14) for the full treatment. Short version:
- New worlds: always pre-gen.
- Old worlds in active expansion: pre-gen new frontier.
- Static worlds where exploration is complete: pre-gen pointless.
When to prune regions
Region pruning is useful when:
- Your world file is significantly bigger than the area players actually use.
- You've removed mods that added biome content (the old chunks are useless).
- A player explored 5000 blocks out and back and that exploration data is taking up disk.
- You're migrating servers and want to reduce upload size.
Pruning is NOT useful for:
- Active areas. Pruning these would force regeneration and break builds.
- Areas players might return to. They'll regenerate with new gen, breaking continuity.
- Very recent saves. Pruning takes time; do it sparingly.
Tools
For Minecraft Java:
MCA Selector (by Querz): a GUI tool (with a headless mode) to visualize, select, export, and delete regions by criteria like "last modified before date X" or "outside this rectangle." Free, open source. The standard for offline pruning.
MCStructureCleaner: narrower; removes references to missing structures left behind by mod changes. Useful in modded contexts.
WorldBorder plugin (/wb fill and /wb trim): a long-established server plugin that can both pre-fill chunks inside a defined border and trim everything outside it. Good for live operation paired with a world border.
For VS: less mature. Some admin mods provide chunk-prune commands. Otherwise, the .vcdbs is a SQLite database you can inspect, but mutating it directly is risky.
For other games: tool support varies; some games have community tools, most don't.
The lifecycle: pre-gen, play, prune
A safe pruning workflow
Take a full backup. Twice. Pruning is destructive. You want recovery if something goes wrong.
Identify your "keep" area. What chunks are in active use?
- All chunks within N blocks of spawn.
- All chunks with player-built structures (tools can analyze this).
- All chunks visited in the last X days.
Pick a tool. Read its documentation. Different tools use different chunk-selection logic.
Run a dry-run first. Most tools support previewing what would be deleted without doing it.
Apply. Wait for completion.
Boot the world on a test server first. Confirm it loads, players' bases are intact, no obvious problems.
Once verified, switch live.
A pruning example (Minecraft)
In MCA Selector's Chunk Filter dialog, a common selection is something like:
LastUpdate >= "2026-03-17" OR (xPos in -125..125 AND zPos in -125..125)
Units are chunks, so a 125-chunk box from the origin is roughly 2000 blocks each way. You then invert and delete, leaving only "loaded recently" or "near spawn" chunks.
Exact filter syntax varies by version of the tool, and you can also draw a region selection on the map and operate on it visually. The concept is universal: "keep what's used, delete the rest."
What pruning gets you
Realistic numbers from servers we've pruned:
| Before | After | Reduction |
|---|---|---|
| 30 GB world (5000-block radius explored) | 6 GB (1500-block radius preserved) | 80% |
| 12 GB world (3000-block radius) | 4 GB (1000-block radius) | 67% |
| 60 GB modded world | 15 GB | 75% |
Big savings. Worth it before backups, world migrations, or just disk-pressure relief.
Common pruning mistakes
Pruning without a backup.
The destructive operation. Always backup. Three times if you're nervous.
Pruning by "blocks placed" alone.
Some active areas have no player-placed blocks (e.g., a mine where players removed blocks). Pruning these would delete legit areas.
Pruning the nether or end.
Don't forget these. They're separate world folders. Prune them with their own selection rules.
Pruning by date alone.
A player might have stopped playing for a month and return to find their base gone. Better: combine date with distance from spawn.
Not testing before going live.
A failed prune can be world-ending. Always test on a copy first.
Region pruning during pre-generation
The two operations interact. A common workflow:
- Set world border to the desired play area.
- Pre-generate everything inside the border.
- Prune everything outside the border.
Result: a fully-generated, tightly-bounded world with no stutter and no wasted disk.
This is a great state for a new server. Less common for a long-running one because the prune would delete existing player exploration.
When to do this maintenance
For a new server: at launch.
For an existing server: at any major version update, or quarterly, or when the save grows uncomfortably large.
For a server you're migrating: before the migration, to reduce upload size and transfer time.
A note on incremental backups
If your backup strategy uses incremental snapshots (restic, borg), pruning the world is an interesting case. Before pruning, you've been backing up a 30 GB world. After pruning, you back up a 6 GB world. The incremental tool may take a long time to figure out "everything in those deleted regions is gone now." Some tools handle this gracefully; some need a fresh full backup after major changes.
If your backup growth seems out of control after a prune, do a fresh full backup and prune the older incrementals.
Reclaiming disk on the server
After pruning, your save folder is smaller. But sometimes the underlying disk still shows the same usage. Reasons:
- Some filesystems don't immediately release deleted space (sparse files, COW filesystems).
- The host's allocation system may still show the original size.
For most hosting setups, the disk usage updates within minutes to hours. For some, you may need to:
- Run
du -shto confirm actual size. - For ZFS/Btrfs: older snapshots still reference the deleted regions, so the freed space stays "held." Destroy snapshots that pre-date the prune to actually reclaim it.
- For VPS-tier hosting: contact your provider if their reporting is wrong.
Conclusion
Pre-generation and pruning are complementary tools for managing world data. Pre-generate to smooth performance. Prune to reduce storage. Both are easy to do wrong (catastrophically destructive). Both are extremely useful when done right.
Plan for them. They are a normal part of long-term server health, not exotic operations.
Hosting your game server with AndroHost means we handle most of what's in this post for you automatically: tier sizing, SRV records, off-site backups, DDoS protection.
Keep reading
TPS dropped overnight and nothing changed, where to look first
You log in. The server is up. TPS is 12 where it was 20 yesterday. "Nothing changed." Players are starting to complain.
Using your AndroHost database with plugins like LuckPerms
Every paid AndroHost server includes a real MariaDB database for plugins that need one. Here is how to set it up and connect.
Why "ping to server" can lie, and how to measure properly
The number next to a server in your game's server list (the "ping" or latency display) is convenient. It's also frequently misleading. This article explains what it actually measures, when it's wrong, and how to get a real number.