Every block placed, every chunk generated and every backup taken is a write to the same NVMe drive. That drive is shared, fast, and finite — and what looks like harmless storage housekeeping can quietly compete with the world itself for the same I/O bandwidth.
Why an idle backup still has a cost
A compressed backup sitting on disk costs nothing while nothing touches it — but it is rarely truly idle. Antivirus-style scans, the panel's own size calculations, and any process walking the directory tree all have to read through it, and a large number of large files makes every one of those routine operations slower than it needs to be.
The more direct cost shows up during backup creation itself: compressing gigabytes of world data is a sustained read-and-write operation competing with the live server's own chunk saves and log writes for the same drive's queue. On a server that is already I/O-bound, a backup job running at the same time as heavy world activity is two demanding jobs sharing one resource neither was sized to share alone.
What actually uses I/O on a game server
| Activity | Pattern |
|---|---|
| Chunk autosave | Frequent, small, scattered writes — this is the baseline cost that is always running |
| World generation | Bursty writes as new terrain is created, heaviest when players explore |
| Backup creation | Sustained sequential read of the whole world, plus write of the compressed archive |
| Log files | Small continuous writes — normally negligible, large if something is flooding the log |
| Uncompressed archives left on disk | No ongoing write cost, but adds to what every directory scan has to walk through |
A backup's job is done the moment it exists somewhere safe — keeping it on the same disk the live world writes to afterwards provides no additional protection and only adds ongoing cost. Downloading it and removing the local copy is not just about the storage quota; it is about not making the live server compete with its own safety copy for the same drive.
Flash storage has a finite number of write cycles per cell, and unnecessary data sitting through repeated scans and backup passes adds writes that produce no benefit. This is a slow, background cost rather than something that shows up in a single day's performance — which is exactly why it is easy to ignore until the drive is old.
Disk usage reflects only active game files and downloaded-then-deleted backups leave no lasting footprint, and a backup job running does not visibly affect TPS on a server that was previously stable.