How to Recognize a Save Problem

Your save lives in the server identity folder as proceduralmap.<size>.<seed>.<protocol>.sav, alongside the player databases (player.blueprints.*.db and related files). A save problem usually shows up in the Console at boot as one of:

• Error loading save (...) followed by a NullReferenceException and a frozen startup
• The server hangs forever at Spawning entities
• Couldn't load server/.../proceduralmap.... .sav - file doesn't exist, then the server generates a brand new empty map

Each points to a different cause, so read the exact message before acting.

First: Stop and Protect What You Have

Before any recovery attempt:

1. Stop the server
   from the panel Console.
2. Take a backup
   through the Backups tab, even of the broken state. Recovery attempts that go wrong are reversible only if you do this first.

Recovery Option 1: Restore a Panel Backup

The cleanest fix. Open the Backups tab, pick the most recent backup from before the corruption, and restore it. You lose progress back to that snapshot, but the server boots clean.

If you run scheduled backups (you should, see Backups), this usually costs you a few hours of progress at most.

Recovery Option 2: Use Rust's Own Rotating Save Copies

Rust keeps numbered backup copies of the save next to the live file, named like proceduralmap.4500.12345.262.sav.1 and .sav.2. The higher the number, the older the copy.

1. With the server stopped, open the File Manager and go to the server identity folder.
2. Rename the broken ....sav to ....sav.broken.
3. Copy ....sav.1 and rename the copy to the exact original filename, ending in .sav.
4. Start the server.

If .sav.1 is also corrupt (it can be, if the corruption happened a few save cycles ago), repeat with .sav.2.

Recovery Option 3: The "Missing Save" After an Update Is Not Corruption

If the error is file doesn't exist right after a Rust update, your save is fine. The protocol number in the filename no longer matches the updated server, so Rust looks for a file that was never written.

With the server stopped, rename the old save to use the new protocol number the console says it is looking for, then start. Note that monthly forced wipes intentionally invalidate old maps; this trick applies to mid-month patches, not forced wipe Thursdays. See Wipe Management.

Recovery Option 4: A Plugin Is Crashing the Load

A NullReferenceException naming an entity type (for example MiniCopter.ServerInit) often means a plugin spawned entities the server can no longer initialize.

1. Stop the server.
2. In the File Manager, rename oxide/plugins to oxide/plugins-disabled.
3. Start the server. If the save now loads, a plugin was the trigger.
4. Stop again, restore the folder name, and move plugins back in small batches to find the culprit. Vehicle, NPC, and event plugins are the usual suspects.

Last Resort: Delete the Save

Deleting the .sav file forces a fresh map on next boot. This is a map wipe: all buildings and deployables are gone. Player blueprints survive, because they live in the separate player.blueprints.*.db file, so it is painful but not a total reset.

Preventing Corruption

Almost every corrupted save traces back to one of these:

• The server process was killed mid-save. Always stop through the panel and let it exit gracefully. Never spam the kill action while the console shows saving activity.
• The disk filled up. A save written to a full volume is truncated and unloadable. Keep an eye on your storage usage in the panel and prune old logs and oversized backup retention.
• Crash loops during entity spawn. Keep heavy NPC and event plugin stacks within reason, see Performance Optimization.
• No scheduled backups. Set a backup schedule in the Schedules tab so option 1 is always available. Daily at minimum, more often on busy servers.

What to Read Next

• Backups for the backup and restore workflow in detail
• Wipe Management for planned map resets done properly