Backup and Restore Windows on Game Servers: RPO, Save Freezes and Storage Maths

Every operator knows they should take backups. Far fewer have worked out that a backup has a window — a real duration during which the server behaves differently — and that window has to fit inside your daily play schedule without causing a visible stall. Getting this wrong is why a 900 GB ARK cluster takes a nightly 40-minute freeze that players experience as lag spikes every single evening.

RPO is a design decision, not a default

Recovery Point Objective — how much progress you can afford to lose — should drive backup frequency, and it is different per game:

• Rust: RPO of 15-30 minutes is acceptable for most communities. Wipe-day progress loss of an hour would be catastrophic, but losing 20 minutes of farming is recoverable. Autosave every 300s, snapshot every 30 minutes.
• ARK / Palworld: RPO 10-15 minutes. Taming and breeding are long, irreversible operations, so players tolerate almost no loss. Palworld’s built-in bIsUseBackupSaveData gives you a short-horizon local backup for free.
• Project Zomboid / Valheim: RPO 60 minutes is usually fine. Both save the whole world cleanly and have low-frequency, high-value change patterns.
• Minecraft (modpacks): RPO 30-60 minutes, but note that region files change constantly and a partial backup of a live world is worthless.

Quantifying the freeze

There are three ways to take a backup and they have wildly different window costs:

• Stop-and-copy (cold): stop the server, tar/copy, restart. Window = stop time + copy time. For a 120 GB world on NVMe at 2 GB/s sustained this is roughly 60 seconds of copy plus 20-40 seconds of save/startup. Cheap and safe, but a hard stop.
• Filesystem snapshot (LVM/ZFS/btrfs): window = save duration only, typically 1-8 seconds. The snapshot is near-instant and you copy from the snapshot in the background. This is the correct answer for any server with more than a handful of players.
• Live copy without snapshot: window = the copy duration, and the backup may be inconsistent. Never do this for a database-backed or region-file game.

Here is the difference in concrete terms for a 140 GB Valheim world with a 6-second save time on NVMe:

# BAD: cold copy every night
stop; cp -a world/ /backup/world-$(date +%F); start
# freeze window: ~75 s (6 s save + 60 s copy + 9 s start)

# GOOD: LVM snapshot, copy from snapshot
lvcreate -L 20G -s -n world-snap /dev/vg0/world
# save/blockdev window: ~6 s
cp -a /mnt/snap/world/ /backup/world-$(date +%F)   # runs while server is up
lvremove -f /dev/vg0/world-snap

The cold copy costs 75 seconds of total downtime per night. The snapshot costs 6 seconds. Across a year that is 7.6 hours of downtime versus 36 minutes — and it is entirely a filesystem choice made at build time. This is the practical argument for provisioning your game node with LVM or ZFS from day one rather than a flat ext4 partition.

Storage maths: how much backup space do you actually need

Retention strategy determines capacity more than world size does. A workable, cheap default for a game node:

• 7 daily snapshots (covers “something broke yesterday”)
• 4 weekly snapshots (covers “a bad patch landed last week”)
• 3 monthly snapshots (covers “we need the pre-wipe state”)

That is 14 retained copies. If your worlds total 140 GB that is 1.96 TB of backup storage — before deduplication. With ZFS or btrfs block-level dedup and compression, daily increments on a game world typically compress to 8-20% of the previous copy because most region/chunk blocks are unchanged. Realistic measured usage for a 140 GB world with 14 retained copies on zstd: 220-340 GB.

Do not put backups on the same physical device as the live world. A dead NVMe takes both. A pair of 4 TB SATA SSDs in RAID1 is cheap, has more than enough throughput for background copies (550 MB/s sequential), and survives a single disk failure. Rotate one drive off-site monthly.

Timing the window to your player base

Identify your quiet hour from player-count telemetry, not from a guess. For a European-majority Rust server the trough is usually 04:00-06:00 UTC; for a North American community it is 09:00-11:00 UTC. Schedule the heavy background copy in that trough, but place the save/snapshot window regardless of time, because it is only seconds. If your storage cannot sustain a background copy without stealing IOPS from live play, throttle it: on Linux use ionice -c2 -n7 plus cp --bwlimit via rsync, capping the copy to roughly 80 MB/s so it never queues ahead of the game’s own reads.

Finally, test the restore. A backup you have never restored from is a hypothesis, and the restore window is usually much longer than the backup window — restoring 140 GB plus verifying region-file checksums takes 3-6 minutes even on NVMe. Our dedicated server comparison table lists expandable storage bays per chassis, which matters because backup capacity grows faster than world size does over a wipe cycle. If you run multiple game instances, compare bare-metal specs side by side and pay attention to drive-bay count and RAID controller support — offloading snapshots to a dedicated pair of drives keeps the live NVMe uncontended.