Project Zomboid ZipBackup ENOSPC and the map_meta Corruption That Follows

Project Zomboid ZipBackup ENOSPC and the map_meta Corruption That Follows

Project Zomboid hosts a backup subsystem called ZipBackup that snapshots the active world into a zip file inside the save folder. When the host partition runs out of space partway through that write, the zip is left truncated and the live save itself can be left in a partially-flushed state. Six to twelve hours later the same server can refuse to load a region with a flood of "invalid room metaID" errors, and most admins do not realise these two events share a single root cause.

The Symptom in the Player's Words

Admins paste the same Java stack into support a half-dozen times across half an hour and get told to "restart the server". That answer does not work, because by the time the restart loop has finished, the most recent backup is already truncated and a later save cycle has written a partially-valid map_meta.bin on top of the same disk that ran out of space.

Verbatim Log Signatures

The first signature appears in ~/Zomboid/Logs/<date>_DebugLog-server.txt (build 42 / unstable path) or ~/prz/bin/Zomboid/Logs/<date>_DebugLog-server.txt (build 41 / stable path).

ERROR: General      f:0 st:52,398,888,217>
  ZipBackup.makeBackupFile> Exception thrown
        java.util.concurrent.ExecutionException:
          java.io.IOException: No space left on device
                at FutureTask.report(null:-1).
        Caused by: java.io.IOException: No space left on device
                java.base/sun.nio.ch.UnixFileDispatcherImpl.write0(Native Method)

Hours later, on the next restart or zone-load, the same log file shows:

LOG  : General  f:0 ...> IsoMetaGrid.Create: begin scanning directories.
LOG  : General  f:0 ...> IsoMetaGrid.Create: finished loading in 5.696 seconds.
ERROR: General  f:0 at IsoMetaGrid.load    >
  invalid room metaID #231 in cell 25,33 while reading map_meta.bin.
ERROR: General  f:0 at IsoMetaGrid.load    >
  invalid room metaID #327914 in cell 25,33 while reading map_meta.bin.
ERROR: General  f:0 at IsoMetaGrid.load    >
  invalid room metaID #327911 in cell 25,33 while reading map_meta.bin.
ERROR: General  f:0 at IsoMetaGrid.load    >
  invalid room metaID #655594 in cell 25,33 while reading map_meta.bin.

Other variants of the same root cause include:

java.io.IOException: No space left on device
        at java.base/java.io.FileOutputStream.writeBytes(Native Method)
        at zombie.core.backup.ZipBackup.makeBackupFile(ZipBackup.java:...)

NullPointerException
        at zombie.iso.IsoMetaGrid.save(IsoMetaGrid.java:...)

Why This Happens

The backup subsystem walks the save folder, zips it, and writes the result back next to the live save. On any decent-sized survival world with a few weeks of in-game time, the backup zip can be 200–800 MB. If two consecutive backups happen during the same boot window with no rotation in between, the partition can hit 100% within one save cycle. The Java write path then throws IOException: No space left on device from UnixFileDispatcherImpl.write0, the executor wraps it as ExecutionException, and the visible stack shows both layers.

The save subsystem keeps writing world chunks even while the backup thread is dying. The next map_meta flush after the disk filled up is the one that lands a half-written file. From that moment on, every load of an affected cell throws "invalid room metaID".

Phase 1: Free Disk Space

1. Stop the server from the panel. Do not skip this. A running server will start a new backup cycle while you are clearing space.
2. Inside the File Manager, navigate to the Backups partition and delete any backup older than the most recent known-good run. The default retention is five backups; if you have ten, the oldest five are safe to remove.
3. Check the Logs partition. Rotated DebugLog-server files older than a week add up. Delete archived logs that you no longer need.
4. If you have shell access through the support team, run du -sh ~/Zomboid/Saves/Multiplayer/<world>/backups/ to see exactly how much disk the backup folder is using.
5. Do not delete map.bin, map_meta.bin, map_t.bin, or anything under the chunkdata/ subfolder. Those are the live world.

Phase 2: Verify Save Integrity Before Restart

With the server stopped and disk free, the next question is whether the live map_meta.bin is salvageable or whether the failed write already truncated it.

1. In File Manager, open the save folder for the affected world: ~/Zomboid/Saves/Multiplayer/<world>/ on build 42, or ~/prz/bin/Zomboid/Saves/Multiplayer/<world>/ on build 41.
2. Note the file size of map_meta.bin. On a played-in world it is normally between 1 MB and 8 MB. A truncated file is often well under 100 KB.
3. Compare against the most recent backup. Open the newest pre-failure backup zip and check the map_meta.bin entry inside. If the live file is much smaller than the backup version, the live file is corrupt.
4. If the live file is intact, skip Phase 3. Restart and watch the next save cycle for new errors.

Phase 3: Restore From Backup

The Backups tab in the panel restores atomically: it replaces the live save folder with the contents of the chosen backup zip in one operation. Do not restore a single file by hand — PZ pairs map_meta.bin with the world database and they must move together.

1. Pick the most recent backup that predates the first ZipBackup ENOSPC line in DebugLog-server.txt.
2. Use the panel's Backups → Restore action on that snapshot.
3. Start the server. Watch the new DebugLog-server.txt for the first ten minutes.
4. If "invalid room metaID" lines reappear, the restored backup is also affected. Go back one snapshot and try again.

If three consecutive backups all show the same corruption on load, the failure window was longer than your retention. Restore the oldest available snapshot and accept the in-game time loss — the alternative is a partially-broken world that will surface new errors weeks later.

What's Worth Checking Next

Two diagnostic commands close the loop after recovery.

df -h ~/Zomboid/

Expected output on a healthy server is the host partition at less than 80% used. Anything above 90% will replay this failure within a few days.

ls -la ~/Zomboid/Saves/Multiplayer/<world>/map_meta.bin

Expected output is a file size between 1 MB and 8 MB on an established world. A file under 100 KB is the smoking gun for truncation. Compare against the size inside the most recent restored backup.

Prevention

• Lower the in-game backup retention if your world is over 500 MB. Sandbox Options → Advanced → backup count can drop from the default to three.
• Use the panel's scheduled-backup feature instead of the built-in ZipBackup if your host offers it — managed backups write to a separate partition that does not affect the live save when full.
• Set up a disk-usage alert at 80% so you see the trend before the write fails.

When to Escalate

Contact support with the full DebugLog-server.txt attached if all three of the following are true:

• Disk is currently below 70% used.
• The "invalid room metaID" errors are present on a backup that was taken while disk had plenty of space.
• The same cell coordinates are listed across multiple restart attempts.

That combination points to mod-driven map corruption rather than the disk-full chain — usually a map mod that updated and renumbered its room metadata while your save still references the old IDs. Recovery there requires rolling the map mod back to the version your save was created on.

For full backup and rollback workflows on a managed host, see Project Zomboid server hosting on Supercraft. Managed backup partitions sit outside the world's own disk quota, so a ZipBackup failure can never poison the live save.

Last updated: 2026-05-26.

Looking for managed Project Zomboid server hosting? Supercraft runs PZ dedicated servers with daily backups on a separate partition, instant setup, and 5 region options. Plans from $5.99/mo.