Save-game corruption, prevention and recovery

Save corruption is the rare-but-terrible failure mode of game servers. It can wipe weeks or months of progress in seconds. The good news: it's almost entirely preventable with reasonable practices. And when prevention fails, recovery is often possible if you have backups.

What corruption is

A save file is a structured data file (sometimes a single file, sometimes a directory of files). Corruption means that structure is damaged: bytes that should be one thing are something else, or are missing.

Sources of corruption:

Source	Prevention
Crash during save	Graceful shutdowns, never kill the process mid-save
Disk failure	Modern SSDs, monitor drive health
Power loss	UPS for self-hosting
Out-of-disk errors	Keep 20%+ free, monitor
Network filesystem issues	Save locally, back up to network
Game / mod bug	Mod discipline, test before applying
Malicious action	Restrict file access, audit who has shell

Each has different prevention. None is impossible. Most are rare.

Prevention

Use a stable disk

Use SSDs, not aging HDDs. Modern SSDs are highly reliable. Old, heavily-used drives are corruption risk.

If you're self-hosting on years-old hardware, replace the drive holding your saves.

Don't kill the process abruptly

Stop the server gracefully: /stop, /save-all then /save-off before kill, or equivalent. Killing the process while it's writing the world is a leading cause of corruption.

For systemd: systemctl stop triggers a graceful shutdown signal. Wait for it to actually stop.

For panels: use the "Stop" button, not "Kill."

Ensure adequate disk space

If the disk is 90 percent full, a save that requires temporary space (the game writes a new copy, then renames) can fail mid-write.

Keep at least 20 percent of the disk free. Monitor and alert if it drops below 10 percent.

Use local storage, not network filesystems

Game saves on NFS, SMB, or cloud-mounted filesystems are corruption-prone. The latency and possible interruption of network filesystems doesn't match what save algorithms expect.

Save to local disk. Back up to network / cloud.

Don't share the save directory between processes

If two server processes (e.g., a backup script and the game server) write to the same files simultaneously, you'll get corruption. Backup scripts should snapshot or wait for the game's save to complete.

Stable power

If you're self-hosting, a UPS for the server is genuinely worth it. A $100 UPS gives you graceful-shutdown time during power flickers.

Filesystem with journaling

Modern filesystems (ext4, NTFS, APFS, ZFS, btrfs) have journaling that protects against many failure modes. Avoid older filesystems (FAT32) for live saves.

For very paranoid setups: ZFS or btrfs with snapshots. Atomic snapshots are essentially "free backups."

Detection

You usually don't know a save is corrupted until you try to load it. By then, the corruption may have been silently writing for days.

Earlier detection signals:

• Backup integrity checks (restic check, borg check). Run weekly.
• Save load times that suddenly spike (the game is fighting bad data).
• Crashes during save with "I/O error" or "checksum mismatch."
• World load failures with "incomplete data" or "premature EOF."

If you see any of these, snapshot immediately and investigate.

Recovery: the workflow

Recovery: when there's no clean backup

Sometimes the corruption was silent for so long that all your backups have it. Options:

Partial recovery. Some tools can extract usable chunks from corrupted Minecraft worlds. MCASelector and similar can iterate through regions and keep what's intact.

Manual repair. For known-format corruption (e.g., a specific chunk is corrupt), tools exist to delete that chunk so the world loads, accepting the loss of that area.

Accept the loss. Sometimes the right answer is "start over." Heartbreaking but cleaner than half-broken saves.

Specific corruption patterns

Minecraft: "incomplete data" in a chunk

Pattern: a specific chunk fails to load.

Fix:

• Tools can delete the chunk, forcing regeneration.
• Players' builds in that chunk are lost.
• World remains usable for everything else.

Minecraft: world fails to load entirely

Pattern: server crashes immediately on world load.

Diagnosis: read the crash log. Often the corrupted chunk is named. Apply the chunk-delete fix above.

If the corruption is in level.dat (world metadata), restore that file specifically from backup.

Valheim: .db corruption

Pattern: server fails to start with errors reading the world.

Fix:

• Try .db.old (rename current to .db.bak, rename .db.old to .db).
• If that fails, restore from backup.

Vintage Story: SQLite corruption in .vcdbs

Pattern: server fails to start, save file appears intact size-wise but won't open.

Fix:

• SQLite recovery tools can sometimes extract data from corrupted files.
• For most admins: restore from backup is faster.

Eco: world directory corruption

Pattern: server fails to load, errors reference specific entity data.

Fix: depends on what's corrupt. Sometimes specific entity files can be deleted manually. Mostly: restore from backup.

A note on testing the unhappy path

Backups you've never restored are theoretical. Do this exercise on a quiet weekend:

1. Pretend the world is corrupted.
2. Stop the server.
3. Restore the latest backup to a new location.
4. Boot it.
5. Time it. How long did the restore take? Any unexpected friction?
6. Confirm the restored world works.

This rehearsal makes the real corruption event manageable instead of panic-inducing.

Conclusion

Save corruption is rare with modern hardware and reasonable practices. When it strikes, backups are the difference between minor setback and disaster.

Prevent with stable hardware, graceful shutdowns, adequate disk. Detect with regular backup integrity checks. Recover with practiced restore procedures.

A 30-minute fire drill once a quarter is worth more than any amount of guessing about whether your backups would work. Do the drill.