A sudden world reset where player structures vanish and a clean terrain appears after a restart is among the most alarming incidents for a Rust server owner. In the vast majority of cases, previous save data is not gone: the server simply loaded from a different profile directory, received altered generation arguments, or encountered a corrupted save file.
This diagnostic guide targets Linux Rust administrators. As of October 27, 2026, procedural save files require exact correspondence across three variables: map world size, seed number, and Facepunch save protocol version.
How Rust locates active save files#
All world geometry, deployed structures, and inventory states reside inside a structured path:
server/<server.identity>/proceduralmap.<size>.<seed>.<protocol>.sav
For instance, a server configured with +server.identity "main" +server.worldsize 3500 +server.seed 48291 produces:
server/main/proceduralmap.3500.48291.261.sav
When the dedicated server boots and fails to find an exact filename match for all components, it does not throw a critical error; instead, it automatically begins generating an entirely new procedural world.
Factor 1: Missing or changed server.identity#
If +server.identity is omitted or misspelled in your startup script, systemd unit, or docker-compose file, Rust silently falls back to its internal default: my_server_identity.
Consequently, the process creates a new folder server/my_server_identity/ and generates an empty map there. Your real player data remains completely intact in the original directory (such as server/main/).
Check the contents of the server/ root:
ls -la /srv/rust/server/
If multiple directories exist, restore the correct +server.identity value in your launch command and restart the service.
Factor 2: Seed or worldsize changes in launch commands#
Altering even a single digit in +server.seed or +server.worldsize changes the expected filename.
Inspect existing .sav files in your active profile folder:
ls -la /srv/rust/server/my_server_identity/*.sav*
Compare the numeric tokens against your current startup line:
| Startup argument | Token in existing .sav filename | Result |
|---|---|---|
+server.worldsize 3500 | 3500 | Match (loads existing world) |
+server.seed 48291 | 48291 | Match (loads existing world) |
+server.seed 48292 | 48291 | Mismatch (generates fresh world) |
If the startup parameters diverged from the numbers recorded in your latest save file, revert seed and world size to their original values.
Factor 3: Corrupted save files or kernel OOM termination#
When a server is abruptly terminated (kill -9, power loss, or Linux kernel OOM Killer) while actively writing out a periodic save, the primary .sav file can be truncated or zeroed out.
Rust automatically maintains sequential recovery copies (.sav.1, .sav.2, etc.). If the active file is damaged, restore the most recent sequential backup:
cd /srv/rust/server/my_server_identity
ls -lh proceduralmap.*.sav*
cp -p proceduralmap.3500.48291.261.sav.1 proceduralmap.3500.48291.261.sav
Factor 4: Mandatory Forced Wipe protocol updates#
On the first Thursday of every month, Facepunch issues a mandatory update that increments the save protocol version (such as transitioning from 260 to 261).
The updated RustDedicated engine explicitly refuses to load save files built on older protocol versions, even when seed and world size are identical. The server console logs: Save protocol mismatch: expected 261, got 260. This is intentional game behavior designed to prevent corrupted physics and map features across incompatible engine builds.
If you manage your dedicated hosting environment through Nexardo, pin world generation parameters inside centralized environment configurations: strict launch parameter controls eliminate unintentional world divergence across service reboots.
