Scheduled Restart and Save-Backup Windows to Stop Memory-Bloat Crashes

Palworld, Enshrouded, and similar session-persistent survival titles share a failure mode: the world keeps simulating between play sessions, memory grows with every explored region, tamed creature, and placed structure, and eventually the process crosses a threshold and the server crashes — usually at 3 a.m. with an unattended save and a lost hour of building. A scheduled restart paired with a save-backup window is the standard, boring fix that eliminates most of these crashes.

Why Persistent Worlds Bloat Memory

These servers are not leaky so much as accumulative. Memory grows from three sources:

Entity tracking — every tamed creature, NPC, and dropped item carries an object that stays resident for world persistence.
Chunk and region data — explored terrain stays cached even after all players leave those areas.
Fragmentation — long-running processes fragment the heap, so the same logical load occupies more physical RAM over days.

A restart releases all three. Without one, a server that starts at 6 GB can reach 16 GB in a week and OOM on a node with 16 GB of RAM, even with a modest player count.

Designing the Restart and Backup Window

The trick is sequencing: save first, back up second, restart third, and give players a warning. A safe window looks like this:

Step	Action	Timing
1	Broadcast in-game warning to players	T-5 minutes
2	Trigger save via console/RCON, confirm it completes	T-1 minute
3	Copy save to rolling backup, verify checksum	Immediately after save
4	Graceful stop, wait for exit signal	After backup
5	Restart service, confirm it binds and loads	Within 2 minutes

Schedule the window at your community’s quietest hour — typically 4-6 a.m. local for a single-region population. A five-minute warning prevents lost builds; a verified backup before the stop means a corruption check after restart is pointless if the save did not actually land on disk.

Automating It With systemd Timers

Wrap the sequence in a shell script and fire it with a systemd timer rather than cron, because systemd gives you dependencies, logging, and restart-on-failure for free. The script should:

Send the in-game warning through the server’s console pipe or an RCON call.
Call the save command and block until the confirmation line appears in the log.
Compress the save directory to a timestamped archive and keep the last seven.
Stop the unit with systemctl stop, wait, then start it and grep the log for the “ready” line.

Name the timer after the game instance so a node running several servers has one independent window per title. Our game server setup guides show the multi-instance systemd layout this script slots into.

Choosing the Restart Interval

Daily is the safe default for entity-heavy survival games. If your node has generous RAM headroom above the 24-hour peak, every 48 or 72 hours can work, but do not stretch it to weekly — fragmentation and entity accumulation are nonlinear, and the crash risk climbs faster than the inconvenience saved. Measure the process RSS just before each restart for two weeks: if RSS is still climbing steeply at 24 hours, keep daily; if it has plateaued, you can space the window out.

Sizing RAM to Complement the Schedule

The restart schedule reduces the memory you need, but it does not remove the requirement for a sensible RAM floor. Size for the expected peak RSS at the end of your window, plus at least 20% headroom, so a busy weekend does not push you into OOM before the next restart. If your chosen interval still ends in steadily rising RSS, the honest answer is more RAM rather than an aggressive restart cadence that risks save corruption. Review our dedicated server memory options when a node is consistently tight at the end of its window.

Verifying the Backup Actually Works

A backup you have never restored is a liability, not insurance. Once a month, copy the latest archive to a scratch directory, load it into a second instance, and confirm it boots with player structures intact. This catch-backup drill takes ten minutes and is the only way to be certain that your scheduled restart and backup window is protecting your community’s world rather than writing empty archives.

Sample Restart Script Logic

The sequence is simple once written down. The script should refuse to restart if the save step failed, so a failed save never leads to a restart that discards unsaved progress:

Emit the in-game warning and sleep 240 seconds.
Send the save command; grep the log for the completion line with a timeout. If it is not seen, abort and alert — do not proceed to stop.
Compress the save directory to save-$(date +%F-%H%M).tar.zst and prune to the last seven archives.
Run systemctl stop game@palworld and wait for the unit to reach inactive.
Run systemctl start game@palworld and grep for the “ready”/”listening” line to confirm a clean boot.
Record exit status and RSS after boot to a local log for trend analysis.

Warning Players Without Ruining the Session

A restart that surprises players is a support ticket; one they expect is a non-event. Broadcast at five minutes and again at one minute, and phrase the message so it names the reason and the length — “scheduled maintenance, back in about two minutes.” If the game supports it, block new connections during the final minute so nobody loads into a world that is about to go down. For communities in multiple timezones, pick a window that is the local night for the majority and post the schedule somewhere permanent so it is not a recurring question.

When a Restart Is Not Enough

If RSS still reaches your OOM threshold well before the window ends, the restart is masking an underlying sizing problem, not solving it. That happens when the world has accumulated more entities than the node’s RAM supports for a full day, when a mod leaks memory faster than expected, or when the node is oversubscribed and shared memory is contended. In those cases, increase RAM, reduce the world’s tracked-entity ceiling if the game exposes it, or split the population across more instances. A restart buys time; it does not replace adequate memory.