Rust map wipe and blueprint wipe: choose exactly what resets

Write down the promised result before touching Rust's files: a fresh map with learned blueprints retained, a blueprint reset with the world retained, or both. “Full wipe” is too vague to serve as a file-selection instruction, especially when plugins maintain their own economy or progression.

This guide covers a manually administered Rust PC server on Ubuntu: service and account rust, installation /srv/rust/game, identity friends. It follows our setup guide. Identify your actual paths and backup destination first. A forced compatibility change in the current game update can limit which old data remains usable.

Separate the reset policy from the update#

Use three explicit statements when announcing maintenance:

• Map wipe: reset the world and its entities; preserve supported blueprint progress.
• Blueprint wipe: reset learned blueprints; preserve the compatible world save.
• Both: reset those two categories; decide plugin progression separately.

Keeping the same seed does not preserve buildings when the world save is reset. Conversely, changing the displayed wipe date or server tags does not reset data. An administrator's advertised schedule and the game's update compatibility are different controls.

Check the update notes before promising blueprint retention. Facepunch can require a reset, and an old database's presence does not establish that the new build will use it. Do not rename protocol suffixes to force incompatible data into a newer build. Facepunch's identity-file reference explicitly advises against bypassing forced save compatibility through renaming.

Inventory the identity you actually run#

Check the effective identity and map parameters privately in your service and configuration, then list the current files:

sudo find /srv/rust/game/server/friends -maxdepth 1 -type f -printf '%f\n' | sort

The .sav family contains the saved world and its entities. The .map supplies terrain; it is not the file containing player buildings. Blueprint progression uses player.blueprints database files, whose full names include version-dependent suffixes. Associated journal files belong with their database. Record actual names; do not copy a protocol number from an older guide.

This distinction answers the question in a historical map-only wipe discussion: removing every player database is unnecessary for resetting the world while keeping blueprints. Preserve cfg, administrator and ban settings, pairing-related files and other independent state unless the maintenance plan explicitly includes them.

For plugins, inspect their own documentation and storage configuration. A map wipe does not reliably reset a plugin's separate database. Equally, deleting that database may erase progression the group wanted to retain. List plugin decisions individually instead of treating every file outside the map as expendable.

Freeze and archive before moving data#

Announce downtime and pause external restart schedules. Allow the normal save to finish, then stop the service and inspect remaining processes:

sudo systemctl stop rust
sudo systemctl show rust -p ActiveState -p SubState -p MainPID
sudo pgrep -u rust -x RustDedicated

An absent pgrep match normally returns status 1. An unexpected remaining process needs investigation before the copy. A stopped service alone does not rule out a second launcher writing the same directory. Freeze any external plugin database through its own supported backup procedure too.

The following example archives all of /srv/rust outside that tree. Check space first; the archive includes installed game files, not just small save files. Keep the service definition privately because it can contain secrets:

(
  set -e
  sudo install -d -m 0700 /srv/backups/rust
  backup="/srv/backups/rust/pre-wipe-$(date -u +%Y%m%dT%H%M%SZ)-$$.tar.gz"
  sudo tar --acls --xattrs -C /srv -czf "$backup" rust
  sudo chmod 0600 "$backup"
  sudo tar -tzf "$backup" >/dev/null
  sudo sha256sum "$backup"
  sudo sh -c 'systemctl cat rust > "$1"' sh "$backup.service"
  sudo chmod 0600 "$backup.service"
)

GNU tar preserves the selected tree; the extra options capture extended metadata where supported. Listing the archive checks readability, not a complete restoration. Copy it off-host, retain the matching runtime/build information, and include configuration or stores located outside /srv/rust separately. Stop here if the backup fails.

Quarantine only the selected file set#

Create a new private quarantine directory outside the live identity. With the server still stopped, use a trusted file manager or explicit, individually checked move operations; keep a record of source and destination for every file. Do not run wildcard deletion commands copied from a forum.

For a map-only wipe, move the intended world's .sav and its save-backup siblings out of the live identity. Keeping an old backup there can make recovery behavior surprising. Leave the blueprint database and its related files intact. If you want the same terrain, the map asset can remain. To change terrain, record the new seed/size or custom-map selection as part of the plan; move the associated old map asset only when that change or regeneration actually requires it.

For a blueprint-only wipe, move the selected blueprint database and any existing matching journal or shared-memory sidecars as a set. Keep the world save, its backups and map asset intact. Do not select player.tokens, player.states or every player.* file as substitutes for the blueprint database. If choosing both resets, combine those exact sets and the separately reviewed plugin changes.

Verify the promise with a player#

Start once and watch which world and database the new process loads. With a matching client, check recognizable terrain and buildings against the announced map policy. Have a player whose previous learned blueprint is known inspect that blueprint separately. A new character or an empty inventory alone does not prove the blueprint result.

Confirm a subsequent save and planned restart preserve the intended state before reopening normal access. If the scope was wrong, stop new activity and use the complete compatible pre-wipe snapshot for controlled restoration. Keep the archive and quarantine until acceptance is complete; merging old and newly created databases by guesswork introduces another recovery problem.