Surviving a long-running Vintage Story server, world rot, save bloat, and how to handle them

You launched a VS server eight months ago. It was crisp. Friend group played weekly. Now: the world feels heavier, tick stutters are common, the save is 40 GB and growing, and loading the world after a restart takes minutes.

This is world rot. It happens to every long-running VS server. Understanding why and what to do about it makes the difference between abandoning the world and playing it for years.

What's actually happening

VS world files (.vcdbs) accumulate state. Every explored region, every block entity, every dropped item, every chunk visited even once persists. Unlike Minecraft, VS doesn't aggressively prune.

The state accumulates in several places:

• Loaded chunks at any time take RAM.
• Persistent block entities (firepits, bloomeries, querns, crocks, racks) all save data per-instance.
• Item entities that haven't been picked up.
• Mob NBT for any mob that has ever existed and survived a save cycle.
• World metadata for visited regions.

Over months, this compounds. A 6-month-old world is genuinely a bigger workload than a fresh one, even with the same player count.

Symptoms in order of appearance

Past month 9, intervention is usually needed.

Past month 9, intervention is usually needed.

Diagnose where the load is

Before optimizing, find where the load comes from. Tools:

Server log on restart. The console logs how long world load takes and how many chunks / entities are processed. Compare to early-life numbers.

In-game commands: /entity list to see entity counts. /chunkstats (if available with your VS version or admin mods) to see chunk-level data.

Spot inspection. Visit each player's main base. Count block entities. The base with 200 firepits is a candidate.

Solutions, ranked

Solution 1: Prune unloaded chunks

Most "world rot" is unused chunks that were loaded once and stayed in the save file. Pruning them removes the bulk of file size without affecting active play.

VS has tooling for this (some admin mods provide chunk-prune commands). The general pattern:

1. Take a backup (always).
2. Identify chunks not visited in N days.
3. Delete them from the save.
4. Restart.

After pruning, the save file is smaller, load is faster, and the relevant gameplay is unchanged.

This is the single most impactful intervention. Do it every 3 to 6 months on a long-running server.

Solution 2: Audit player block entity density

Some bases accumulate block entities in numbers that aren't reasonable. Examples:

• A "decorative" firepit room with 80 lit firepits.
• A bloomery cluster with 30 active bloomeries.
• A storage facility with 500 crates each tracking contents.

Each of these block entities ticks. Visit the base, talk to the player, propose alternatives:

• Decoratives can be unlit (decorative firepit pattern uses placeable models).
• Production can be batched (use fewer, larger).
• Storage can be consolidated.

This conversation works best when framed as "I want to keep the server fast for everyone" rather than "you're causing problems."

Solution 3: Drop entity accumulation

Item entities lying on the ground from forgotten drops, dead mobs that bled inventory, etc.

VS has commands to clear entities in a region:

/entity remove drop

/entity remove accepts other filters too; check /help entity for the current set.

Useful for periodic spring cleaning. Combine with a player announcement: "Clearing all unclaimed dropped items at the end of the day."

Solution 4: Move to a "new frontier"

Some long-running VS servers handle world rot by deliberately moving the active play area. A new dimension opens, or the world border expands to a new region. Players migrate. The old area continues to exist as "the old continent" or "lore." Tick budget moves with the players.

This requires player buy-in but works well as a 1-year mark celebration.

Solution 5: World reset

Sometimes you just need a fresh start. Pre-reset:

1. Export interesting builds as schematics (VS supports this with admin mods).
2. Archive the old world (don't delete; players will want to visit it).
3. Communicate the reset plan with a long lead time (a month minimum).
4. Reset.
5. Optionally allow players to import their schematics in the new world.

Resets are emotional. Frame them honestly: "We've had a great run. The server needs a fresh start. Here's what we're preserving."

The intervention decision tree

Backups during long runs

A specific risk: corruption on a 40 GB save file is more painful to recover from than on a 3 GB one. Long-running servers need:

• Daily full snapshots (despite the size).
• Hourly differentials if your backup tool supports them.
• Off-host retention of at least monthly snapshots, indefinitely.

Storage is cheap. A year of monthly backups at 40 GB each is 480 GB. On cloud storage that's a few dollars a month.

Performance budget evolution

A useful exercise: track your server's "tick time at peak" monthly.

Tick time over the life of a server, with no intervention

The crossover at ~40 ms (M5 to M7) is the intervention window. Past that, players feel it during every active hour.

A scheduled maintenance plan

For any VS server past three months old:

Weekly:

• Check backup health.
• Glance at performance metrics.

Monthly:

• Audit entity counts.
• Check save file size.
• Spot-check player bases.

Quarterly:

• Prune unloaded chunks.
• Review claim sizes.
• Talk with players about any density issues.

Yearly:

• Consider new-frontier expansion or reset.
• Archive the year's worth of backups.

Most VS server admins do none of this and wonder why their server is dying at month 9. Doing even half of it keeps a server vibrant for years.

What we've actually seen

A VS server we host went 22 months on a single world. Saves grew to about 60 GB. Two chunk-prune passes (months 9 and 16) kept load times manageable. Three players left during that time; eight new ones joined. The world is now in "long peaceful" mode and continues to play smoothly.

Another server we host crashed at month 7. The owner had never done a backup audit. Restoring from the only weekly backup lost two days of progress. They started fresh after.

The difference between those two servers wasn't hardware. It was maintenance discipline.

Conclusion

VS rewards admins who treat the world as a long-lived production system, not a fire-and-forget setup. The natural lifecycle includes intervention. Prune chunks, audit density, communicate with players, take real backups. A VS world can run for years if you let it. The intervention is light. The reward is large.