Game server autosave intervals: how often to save a world

An autosave interval is the most progress your players can lose in one go. A game that writes its world every thirty minutes loses, on average, fifteen minutes of everyone's play when the server stops without a clean save, and up to the full thirty. Shortening the interval caps that loss, at the price of a brief stall every time the world is written - noticeable on a big world, invisible on a small one. For most servers ten minutes is the sensible middle: set Valheim's -saveinterval 600, Rust's server.saveinterval 600 (already the default), Palworld's AutoSaveSpan to a few minutes, and leave Minecraft's five-minute default alone. Then make sure every planned stop is clean, because a clean stop saves regardless of the interval.

Why games do not save continuously#

The world a player walks around in is held in memory. Writing it to disk means serialising thousands or millions of objects - terrain changes, buildings, creatures, containers - into a file, and on most game servers that work happens on, or blocks, the main simulation thread. While it runs, the simulation pauses or slows. Players feel that as a hitch: a half-second freeze, rubber-banding, a door that opens late.

So every game picks a compromise. Save rarely and the hitch is rare, but a crash costs a lot. Save often and a crash costs little, but the hitch comes round more often. The interval is that trade-off as a number, and the right number depends on how big your world is, how fast your storage is, and how often your server stops uncleanly.

The settings for each game#

Defaults move between game versions, so treat the table as the place to look rather than a guarantee, and check the shipped default file of your version before changing anything.

Valheim

Valheim's thirty-minute default is the most commonly regretted setting on any server. The world is one .db file written in a single pass, and a crash or out-of-memory stop loses everything since the last save. Lowering it to 600 caps the loss at ten minutes. On a large, heavily built world the save takes long enough that players notice a stutter; the log reports each one as World saved ( 450.123ms ) or similar, so you can see exactly what it costs. Below about five minutes, the stutter starts to be the bigger complaint. The rest of Valheim's launch settings are in the Valheim dedicated server guide.

Minecraft

Minecraft saves differently from most games. It writes changed chunks to region files, and Paper spreads the work across ticks rather than saving everything at once:

chunks:  auto-save-interval: default  max-auto-save-chunks-per-tick: 24

auto-save-interval: default follows ticks-per.autosave in bukkit.yml, which is 6000 ticks - five minutes at 20 TPS. max-auto-save-chunks-per-tick limits how much is written in any one tick, which is why a Paper server rarely shows a save hitch at all. Chunks also save when they unload. There is little reason to change any of this; if saves are showing up in a spark profile, the storage or the world size is the problem, not the interval. Minecraft world backup and restore covers save-off, save-all and consistent copies.

Rust

Rust saves the whole map every server.saveinterval seconds, default 600, and prints a line with the entity count and timings each time. On a late-wipe map with hundreds of thousands of entities a save can take a second or more, which players feel as a freeze. Raising the interval to reduce freezes is common on big servers; it trades lag for exposure. Many owners keep 600 and accept the freeze, because a crash on a modded Rust server late in a wipe is not rare.

Palworld

AutoSaveSpan sits inside the long OptionSettings=(...) line in PalWorldSettings.ini, in seconds. The default saves very frequently. On a busy server with many bases, each save is heavier, and if players report periodic freezes, try raising it to a few minutes rather than the reverse. Palworld server settings explains editing that line without breaking it.

ARK

AutoSavePeriodMinutes=15 under [ServerSettings] is the default, and ARK's saves are long on a large map with many tames - several seconds of freeze is normal on an old world. Fifteen minutes is a reasonable compromise; going below ten on a big world makes the freezes frequent enough to annoy.

Factorio

Factorio pauses the game while it saves, for every player, and shows a saving bar. autosave_interval (minutes, default 10) and autosave_slots (default 5) control how often and how many rotating autosaves are kept. On Linux, non_blocking_saving forks the process to save in the background without pausing; it is marked experimental, and memory use briefly doubles while it runs. Late-game megabases with long saves are where it earns its keep. More in the Factorio headless server guide.

Games that save as they go

Some games write continuously, by region or by chunk as it unloads, and the "interval" is less important. Project Zomboid writes map chunks as they are unloaded and players as they log out, and SaveWorldEveryMinutes defaults to 0, meaning no separate full-world save on a timer. 7 Days to Die similarly writes regions as they unload and does not expose a simple interval in serverconfig.xml; its saveworld console command forces a full save. Don't Starve Together saves at the start of each in-game day. For these, a crash loses less than the table suggests, but forcing a save before planned stops and backups still matters.

What a save actually costs#

Three things make a save expensive, and only one is the interval.

1. World size. The amount written grows with explored area, buildings and entities. A month-old world can take ten times longer to save than a new one. This is why a server that never hitched starts hitching late in its life.
2. Main-thread work. Serialising objects usually happens on the simulation thread. More CPU headroom helps, but the work itself does not parallelise in most games. Reading game server CPU usage explains why one busy thread looks like low overall usage.
3. Storage. Writing hundreds of megabytes to slow disks adds seconds. NVMe makes the disk part close to free, which is why the remaining hitch on fast storage is almost all serialisation. What NVMe actually changes goes into where it helps and where it does not.

Measure before changing. Most games log each save with a duration or at least a timestamp at the start and end. Watch three or four saves at peak time, and you know the real cost. A 200 ms save every five minutes is nothing; a 3-second save every five minutes is a design problem, and the fix is the world or the plan, not a longer interval.

How much a crash loses#

If a server stops uncleanly at a random moment, the expected loss is half the interval, and the worst case is the full interval. That is per player - a group of ten losing fifteen minutes each is two and a half hours of collective play.

The other number that matters is how often unclean stops happen. A stable server that only ever restarts on a schedule rarely loses anything, whatever the interval. A server running close to its memory limit, a heavily modded server, or one on a game with frequent crash bugs stops uncleanly often, and for those a short interval is worth a lot of hitching. If you do not know how often your server crashes, find out first - why your game server keeps restarting shows how to tell a crash from a memory stop from a schedule.

Clean stops make the interval matter less#

Every game in the table saves when it is stopped properly. A clean stop - the game's own stop command, or a signal the game handles - writes the world before exit. A kill does not.

• Panel Stop and Restart normally send the game's stop command or a signal, and wait. That saves.
• Kill ends the process without warning. That loses everything since the last save.
• An out-of-memory stop behaves like a kill from the game's point of view.
• A host or node failure behaves like a kill.

On RE:NODE, a server that reaches its memory limit is stopped by the kernel and restarted clean rather than left to swap - better for everything else on the machine, and an unsaved stop for the game. If the memory graph shows your server reaching its ceiling, shorten the save interval until you have fixed the cause or moved up a plan; game server memory leaks covers finding that cause. The difference between a clean stop and a kill is also why some Windows-only games run under Wine need extra care: whether they save on a stop signal is game-specific, as Wine and Proton for Windows-only servers explains.

Autosaves are not backups#

Many games keep rotating autosave files - Factorio's slots, Satisfactory's numbered autosaves, Valheim's .old and timed backups. They help with exactly one failure: the latest save being corrupt. They live in the same folder, on the same disk, on the same server, so a deleted server, a bad mod that damages every save it touches, or a mistake in the file manager takes them all.

A backup is a copy somewhere else, taken on a schedule, that you have restored at least once. And a backup only contains what the game had written to disk at that moment, so the order matters: save first, then back up.

On RE:NODE, the Schedules tab runs ordered tasks with delays - a console command, a backup, a power action - on a cron expression, so this sequence can run on its own:

Schedule: every 6 hours (0 */6 * * *)  1. Console command: save        (the game's own save command)  2. Wait 30 seconds  3. Create backup

Swap save for your game's command: save-all for Minecraft, saveworld for 7 Days to Die, server.save for Rust. Backup slots are on every game plan, stored off the machine, and restore with a button. Backups that actually restore explains the last part of that sentence, which is the part people skip. Cron expressions explained covers the schedule syntax.

Manual saves at the moments that matter

An interval protects against the random crash. Some moments are not random, and a manual save in front of them costs a second and removes the risk entirely. Save before:

• Installing or updating a mod or plugin. If it crashes the server on load, the world on disk is current, and rolling back the mod loses nothing.
• Game updates. Take a save and a backup; the update may convert the save in a way the old version cannot read.
• Boss fights, raids and events. These are the minutes players remember losing, and the moments servers are most likely to stall under load.
• Big admin changes. Clearing entities, deleting regions, changing world modifiers, editing a config the game reads at start.
• Handing the console to someone new. A save gives you a clean point to return to if a command goes wrong.

Most games log the save, so wait for the confirmation line in the console before carrying on. Commands that mention "save" but only queue a save, rather than performing it, exist in a few games; the log line is what tells you it is done.

Choosing your interval#

A short procedure that works for any game:

1. Find the setting and its current value from the table above or your game's default config.
2. Measure the save cost at peak, from the log.
3. Count unclean stops over the last month from the console history or crash notices.
4. Pick the interval where the hitch is unnoticeable to players or the loss is acceptable to them - ask them which they mind more.
5. Add a save-then-backup schedule so that backups are never older than the last save.
6. Revisit when the world grows. A setting chosen in week one may be wrong in month three.

FAQ#

What autosave interval should I use for Valheim?

-saveinterval 600, ten minutes, suits most groups. The thirty-minute default loses too much after a crash. Go lower only if your world is small enough that saves are not noticeable, and check the save time in the log.

Why does my server freeze for a second every few minutes?

That is almost always the autosave. Confirm by matching the freeze to save lines in the log. A bigger world or slower storage makes it longer. Lengthening the interval makes it less frequent but increases what a crash loses.

Does a shorter autosave interval use more disk space?

Not usually for the world itself, which is overwritten. Games that keep rotating autosaves use more space when they save more often only if they also keep more slots. Disk writes increase, which matters little on NVMe.

Do I lose progress when I restart the server from the panel?

Not if the restart is clean. A normal Stop or Restart lets the game save before exiting. Kills, crashes and out-of-memory stops are the cases that lose everything since the last autosave.

Should I save before taking a backup?

Yes. A backup copies what is on disk. If the game last saved twenty minutes ago, the backup is twenty minutes old. Send the save command, wait for it to finish, then take the backup.