World size is the quietest capacity constraint on a game server. It does not show up in CPU graphs, it does not lag players during normal play, and it only announces itself when a save takes forty seconds, a backup fails for lack of space, or a restore from three days ago needs a file the disk no longer has. This is a storage planning model for persistent game worlds \u2014 Minecraft, Valheim, Palworld, ARK, Project Zomboid, Rust \u2014 covering how saves actually grow, how much disk a wipe cycle consumes, and how to size volumes with real numbers.<\/p>\n\n\n\n
Save growth is not linear with player count; it is driven by explored and modified terrain. A Minecraft region file is allocated in 4 KiB sectors within a 32\u00d732 chunk region; generating or writing a single chunk forces the region file to grow in steps, and the file never shrinks when chunks are deleted. A 10 GB world with 2,000 region files may contain only 6 GB of live chunk data. Deleting a large base does not give disk back \u2014 it leaves holes in region files until the server rewrites them.<\/p>\n\n\n\n
Entity-heavy worlds grow faster than terrain-heavy ones. Palworld servers commonly reach 8\u201315 GB per 100 hours of play with 16 players because of pal and drop entities stored in the save. ARK saves typically run 2\u201310 GB for a mid-size cluster map. Rust’s Most admins size for one copy of the world and are surprised when the disk fills. In practice a well-run server stores at least five things: the live world, a temp file written during atomic saves, a rolling hot backup, a daily snapshot set, and off-site copies staged before transfer. If your live world is 12 GB, the live volume needs 12 \u00d7 1.2 (temp) + 12 (hot backup) + daily snapshots. At three days of daily snapshots that is roughly 12 + 2.4 + 12 + 36 = 62 GB before you add the OS, server binaries, mod packs, and logs.<\/p>\n\n\n\n Compression changes the maths significantly. Minecraft region files compress 60\u201375% with zstd level 3, so a 12 GB world becomes about 3.5\u20134.5 GB per compressed snapshot. Valheim saves compress around 45\u201355%. Rust saves are already compressed internally and compress poorly. Choose compression per game rather than applying a blanket rule, and always verify a compressed snapshot by test-restoring it once a month.<\/p>\n\n\n\n Wipe-based games make storage planning easier if you delete aggressively. A weekly Rust wipe at 200 players writes roughly 600\u2013800 MB of save data per wipe plus 1\u20132 GB of logs, but you should keep the last 2\u20133 wipe saves for rollback and player appeals. That is about 3 GB live plus 5 GB of retained wipes. Monthly-wipe servers with 500 players can accumulate 40\u201360 GB of retained saves in a year if nobody prunes, which is exactly how a 100 GB volume fills up unnoticed.<\/p>\n\n\n\n Set explicit retention policies and enforce them with a cron job, not good intentions. A sane default: hourly backups for 24 hours, daily for 7 days, weekly for 4 weeks. For a 12 GB Minecraft world with compressed snapshots at a 4 GB average, that is 4 + 28 + 16 = 48 GB of snapshot storage, plus the live copy and hot backup. Total \u2248 75 GB. Round up to a 120\u2013160 GB NVMe volume and you have room to grow for a year.<\/p>\n\n\n\n Copy-on-write filesystems are the practical answer to snapshot cost. With ZFS or Btrfs, snapshots share unmodified blocks, so seven daily snapshots of a 12 GB world where only 400 MB changed per day cost roughly 12 + 7 \u00d7 0.4 \u2248 15 GB rather than 96 GB. That is a 6\u00d7 saving and it makes aggressive retention affordable. The trade-off is that ZFS wants 10\u201320% free space to avoid fragmentation and 1\u20132 GB of RAM per TB for ARC \u2014 both of which must come out of your RAM budget, not your world’s.<\/p>\n\n\n\n If you stay on ext4, snapshots require LVM and full-speed CoW, costing roughly the same in write amplification as a plain copy. Whichever filesystem you pick, reserve 5\u201310% of the volume as root-reserved space ( Save writes consume SSD endurance faster than people expect on games with short save intervals. A 12 GB world saved every 15 minutes writes 48 GB per hour with full-file writes, or far less with atomic incremental writes \u2014 28.8 TB per month at 20 hours of uptime per day. On a 480 GB enterprise SSD rated 1 DWPD (about 175 TBW), that workload burns through 16% of the drive’s life in one month. Incremental saves and snapshots cut it by 80\u201395%, which is why the write pattern matters as much as the drive rating.<\/p>\n\n\n\n The safe planning target for a game server is a drive with at least 1 DWPD and 50% of its endurance remaining after the expected server lifespan. If you are storing a large persistent world, prefer enterprise NVMe with power-loss protection over consumer drives \u2014 the latter have no PLP and a sudden host power loss during a save can leave a truncated region file, which is the most common cause of the “world corrupted after reboot” posts you see in every game community.<\/p>\n\n\n\n Combine live size, copies, retention, and headroom into one number, then pick the smallest standard volume above it. The table below gives working targets for common deployments, assuming snapshots and 20% free-space headroom.<\/p>\n\n\n\n Two rules cover most mistakes. Never let the live volume exceed 70% utilisation \u2014 above that, ext4 fragmentation and ZFS write amplification both accelerate, and save times rise measurably. And always keep off-site copies on a different provider, because a billing dispute or failed migration takes both copies with it otherwise. The storage and NVMe configurations used for these workloads are outlined on the NVMe bare-metal server plans<\/a> page.<\/p>\n\n\n\nproceduralmap<\/code> save is 300\u2013800 MB at 200 players late in a wipe week but the server also writes a large .map.png<\/code> and log files. Valheim’s .db<\/code> stays under 500 MB even for huge builds because it stores ZDOs rather than voxel data.<\/p>\n\n\n\nGame<\/th> Typical save size<\/th> Growth driver<\/th> Wipe cadence<\/th> Disk per 100 hrs @ 20 players<\/th><\/tr><\/thead> Minecraft (Paper)<\/td> 2\u201330 GB<\/td> Explored chunks, region files<\/td> Never (persistent)<\/td> 3\u201310 GB<\/td><\/tr> Valheim<\/td> 30\u2013400 MB<\/td> Instances \/ ZDOs<\/td> Never<\/td> 50\u2013200 MB<\/td><\/tr> Palworld<\/td> 3\u201315 GB<\/td> Pal & item entities<\/td> Rare<\/td> 2\u20136 GB<\/td><\/tr> ARK: Survival Ascended<\/td> 2\u201310 GB<\/td> Dino, structure, tribe data<\/td> Monthly\u2013quarterly<\/td> 1\u20134 GB<\/td><\/tr> Rust<\/td> 300\u2013800 MB<\/td> Entities, bases, deployables<\/td> Weekly\/monthly<\/td> 400\u2013900 MB<\/td><\/tr> Project Zomboid<\/td> 200 MB\u20133 GB<\/td> Map chunks, zombie population<\/td> On restart<\/td> 150\u2013800 MB<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n The Five Copies You Actually Store<\/h2>\n\n\n\n
Wipe Cycles and Retention Windows<\/h2>\n\n\n\n
Filesystem and Block-Level Details<\/h2>\n\n\n\n
mkfs.ext4 -m 5<\/code>) so a runaway save cannot fill the disk to 100% and lock out SSH.<\/p>\n\n\n\nDisk Endurance: The Hidden Cost of Saves<\/h2>\n\n\n\n
Sizing Table by Deployment<\/h2>\n\n\n\n
Deployment<\/th> Live world<\/th> Copies + retention<\/th> Recommended volume<\/th> Backup target<\/th><\/tr><\/thead> 10-player Minecraft<\/td> 4 GB<\/td> 12 GB<\/td> 40 GB NVMe<\/td> 50 GB off-site<\/td><\/tr> 50-player Minecraft<\/td> 15 GB<\/td> 35 GB<\/td> 100 GB NVMe<\/td> 150 GB off-site<\/td><\/tr> 20-player Valheim<\/td> 0.4 GB<\/td> 2 GB<\/td> 40 GB NVMe<\/td> 10 GB off-site<\/td><\/tr> 16-player Palworld<\/td> 12 GB<\/td> 30 GB<\/td> 80 GB NVMe<\/td> 100 GB off-site<\/td><\/tr> 200-player Rust weekly wipe<\/td> 0.8 GB \u00d7 3 wipes<\/td> 6 GB<\/td> 60 GB NVMe<\/td> 30 GB off-site<\/td><\/tr> ARK cluster (4 maps)<\/td> 20 GB<\/td> 50 GB<\/td> 160 GB NVMe<\/td> 250 GB off-site<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Monitoring World Size Before It Bites<\/h2>\n\n\n\n