Linux VPS
Budget game-server storage for growth and backup retention
Build a storage worksheet that accounts for world growth, retained archives and temporary maintenance space without guessing compression.
Budget game-server storage for the files you have, the files players will create and the spare space maintenance needs. World size alone leaves out local archives, logs, maps and temporary copies. Keep the game-server budget separate from any backup-storage allowance so you know which limit each operation uses.
Measure a baseline in consistent units
Record the observation date and group files into live worlds, server software, plugins or mods, generated web maps, logs and local backup archives. Use the panel's supported file or usage controls. On your own Linux VPS, use a read-only size inspection rather than creating a large write benchmark on the live disk.
Be clear about units. A GiB contains 1,073,741,824 bytes; a decimal GB contains 1,000,000,000. Also distinguish logical file size from allocated disk space. GNU's disk-usage reference explains why apparent size and actual disk usage can differ. Compare readings that measure the same thing before describing a discrepancy as lost space.
Keep a simple dated worksheet. Record the live total and the categories that explain it, rather than only the largest folder. If your account's meter includes files outside the game directory or retained snapshots, ask support which scope it measures. Avoid deleting unfamiliar files just to make two counters match.
Estimate growth from representative intervals
Take a second observation after ordinary play and another after an exploration-heavy period. Note what happened between readings: new terrain, a map render, a large mod download or a migration upload. A single unusually busy day should remain labelled as that scenario instead of becoming an unqualified daily growth forecast.
Use the difference to build a planning range over your chosen review period. Keep world growth separate from logs and temporary uploads where you can. If you intend to pre-generate terrain, estimate that project as a separate planned addition and review the resulting disk use before increasing its boundary.
Our bounded terrain-generation guide covers that workflow. For existing pressure, use the full-disk investigation guide before starting another large job.
Calculate backup retention from the actual format
For full backup archives, budget the sum of the copies you will retain, allowing for future growth. Do not multiply the current world's size by the number of backups and call that exact: an archive may include more than the world, and compression varies with its contents. GNU's gzip manual explains that compression effectiveness depends on the input.
Measure a completed representative archive and note what it includes. A synthetic fixture can demonstrate the measurement method, but its compression ratio is not a Minecraft-world forecast. Already compressed assets, database exports and repetitive text can produce different results.
A measured synthetic compression example
On 9 November 2026, CloudExa created an isolated fixture of 16,777,216 bytes: 8 MiB of zeros followed by 8 MiB of random data. Node.js 22.22.0 compressed it with gzip level 6 to 8,399,417 bytes. Decompression returned 16,777,216 bytes, and the restored SHA-256 checksum matched the original.
The test ran under a 256 MiB memory limit and 25% CPU quota. It measured a deliberately mixed synthetic file, not a Minecraft save, server backup or storage-speed benchmark. Its compression result is not an expected world ratio, and its checksum check does not prove that a game checkpoint can load. The temporary files and test process were removed after collection.
Use the same distinction in your worksheet: a measured archive size can replace a guessed input only when it represents the files you intend to retain. Recalculate as the live world grows.
If your backup service uses deduplication or incremental storage, ask how it accounts for retained data and deletion. Use that service's documented storage model instead of the full-archive formula. Backup slots, maximum archive size and total stored bytes are separate limits; confirm all relevant limits before buying retention.
Illustrative capacity worksheet
Consider an illustrative server with 20 GiB of live files. Its organiser plans another 8 GiB of growth before the next review and wants to keep two local full archives, estimated at 15 GiB each from their own representative archive. They also reserve 20 GiB for a maintenance operation that could create an additional working copy.
The worksheet subtotal is 20 + 8 + 30 + 20 = 78 GiB before a further free-space margin. Those numbers are invented planning inputs for arithmetic, not measured CloudExa usage or a plan recommendation. The organiser must check whether the maintenance workflow actually writes that temporary copy locally and update the inputs when the real files differ.
For an independent backup destination, calculate its retained archives separately. Copying the same 30 GiB off-server does not automatically free the local 30 GiB; check which local copies the workflow keeps. Avoid counting a remote archive against the game quota unless that archive also exists locally.
Reserve space for the operation you need next
Ask support how uploads, extraction and restoration use temporary space on your service. A download-and-extract workflow can hold an archive and expanded files at once. Some restoration paths need a different reserve. Do not infer one method from another, and do not run a restoration merely to discover the accounting.
Set a review trigger before free space reaches that reserve. Keep dated measurements and update the worksheet after a major world expansion or retention change. Check backup completion and retention and keep a recovery copy before housekeeping. Choosing capacity around the next real operation makes a more useful purchase decision than waiting for a save or restore to fail.
