Game Server World Size and Disk Planning: Sizing Storage for Save Growth

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 — Minecraft, Valheim, Palworld, ARK, Project Zomboid, Rust — covering how saves actually grow, how much disk a wipe cycle consumes, and how to size volumes with real numbers.

How Saves Actually Grow

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×32 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 — it leaves holes in region files until the server rewrites them.

Entity-heavy worlds grow faster than terrain-heavy ones. Palworld servers commonly reach 8–15 GB per 100 hours of play with 16 players because of pal and drop entities stored in the save. ARK saves typically run 2–10 GB for a mid-size cluster map. Rust’s proceduralmap save is 300–800 MB at 200 players late in a wipe week but the server also writes a large .map.png and log files. Valheim’s .db stays under 500 MB even for huge builds because it stores ZDOs rather than voxel data.

Game	Typical save size	Growth driver	Wipe cadence	Disk per 100 hrs @ 20 players
Minecraft (Paper)	2–30 GB	Explored chunks, region files	Never (persistent)	3–10 GB
Valheim	30–400 MB	Instances / ZDOs	Never	50–200 MB
Palworld	3–15 GB	Pal & item entities	Rare	2–6 GB
ARK: Survival Ascended	2–10 GB	Dino, structure, tribe data	Monthly–quarterly	1–4 GB
Rust	300–800 MB	Entities, bases, deployables	Weekly/monthly	400–900 MB
Project Zomboid	200 MB–3 GB	Map chunks, zombie population	On restart	150–800 MB

The Five Copies You Actually Store

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 × 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.

Compression changes the maths significantly. Minecraft region files compress 60–75% with zstd level 3, so a 12 GB world becomes about 3.5–4.5 GB per compressed snapshot. Valheim saves compress around 45–55%. 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.

Wipe Cycles and Retention Windows

Wipe-based games make storage planning easier if you delete aggressively. A weekly Rust wipe at 200 players writes roughly 600–800 MB of save data per wipe plus 1–2 GB of logs, but you should keep the last 2–3 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–60 GB of retained saves in a year if nobody prunes, which is exactly how a 100 GB volume fills up unnoticed.

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 ≈ 75 GB. Round up to a 120–160 GB NVMe volume and you have room to grow for a year.

Filesystem and Block-Level Details

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 × 0.4 ≈ 15 GB rather than 96 GB. That is a 6× saving and it makes aggressive retention affordable. The trade-off is that ZFS wants 10–20% free space to avoid fragmentation and 1–2 GB of RAM per TB for ARC — both of which must come out of your RAM budget, not your world’s.

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–10% of the volume as root-reserved space (mkfs.ext4 -m 5) so a runaway save cannot fill the disk to 100% and lock out SSH.

Disk Endurance: The Hidden Cost of Saves

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 — 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–95%, which is why the write pattern matters as much as the drive rating.

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 — 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.

Sizing Table by Deployment

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.

Deployment	Live world	Copies + retention	Recommended volume	Backup target
10-player Minecraft	4 GB	12 GB	40 GB NVMe	50 GB off-site
50-player Minecraft	15 GB	35 GB	100 GB NVMe	150 GB off-site
20-player Valheim	0.4 GB	2 GB	40 GB NVMe	10 GB off-site
16-player Palworld	12 GB	30 GB	80 GB NVMe	100 GB off-site
200-player Rust weekly wipe	0.8 GB × 3 wipes	6 GB	60 GB NVMe	30 GB off-site
ARK cluster (4 maps)	20 GB	50 GB	160 GB NVMe	250 GB off-site

Two rules cover most mistakes. Never let the live volume exceed 70% utilisation — 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 page.

Monitoring World Size Before It Bites

Track three numbers daily: live world size, total snapshot usage, and free space in percent. A cron job writing du -sb and df to a one-line log gives you a growth curve within a week, and you can extrapolate it to your next hardware renewal. Alert at 75% utilisation and again at 85%, and treat the 85% alert as an incident, not a warning. When growth outpaces the volume, prune unvisited chunks and compress snapshots first; only then consider a dedicated server with larger NVMe capacity.