Rust Server Save Files: What Map and Player Data Mean

Rust server save files do different jobs: a .map describes terrain and monuments, a .sav stores the world and its entities, and identity files hold other server state. Start with the active server.identity, then label each observed file by a source-backed role or mark it unknown. This is a read-only inventory, not a wipe or restore recipe. If a panel would make server administration easier, we recommend Game Hosting’s Rust plans: the Rust-specific panel includes settings and full file access, plus three backup slots with manual or scheduled backups and restore/download controls. Those features do not prove that any particular file set will restore correctly.

Find the active identity before reading filenames#

The same Rust installation can run multiple servers, so the install folder alone does not identify the files for your world. Facepunch says the server.identity value creates a separate folder for that server. Resolve the running process’s working directory and effective identity first; a panel label, old archive name or familiar directory is only a clue.

These file notes describe Rust PC dedicated servers. Rust Console Edition is a separate game; this guide does not establish its file layout or compatibility with PC server data.

Record the identity exactly as the operator sees it, along with the server build, operating system, capture date and whether the instance is vanilla, uMod/Oxide or Carbon. Facepunch’s server creation reference explains that the identity maps to a server-specific directory. Our Rust identity guide shows how to match an identity to the active process. If you cannot see the process or launch settings on a hosted server, ask the provider which identity and data root its backup or file view uses.

Do not assume the game client directory is the server identity directory. Client settings, cached map downloads and screenshots belong to a different installation and do not establish what the dedicated server is using.

Compare Rust .map and .sav files by role#

The .map and .sav files are related, but they do not mean the same thing. Facepunch describes .map as terrain and monuments, while .sav holds map entities such as player buildings and deployables. Its reference says the files should have corresponding names; procedural examples include the map type, size and seed, while custom map filenames can differ.

File example	Documented role	Record during inventory
proceduralmap.SIZE.SEED.map	Terrain and monuments for a procedural map	Exact filename and map type; custom maps may use another name
Matching .sav	World entities, player buildings, deployables and more	Exact paired name and any numbered variants present
.sav backup examples	Facepunch says the server creates save backups when it saves	Which names actually exist in this identity and build

These are role examples from Facepunch’s server file reference, not file patterns to remove. The protocol suffix can change around forced wipes; Facepunch warns that renaming an older save does not make it compatible. If your filenames do not match the example, write down what is present and ask the administrator to identify the active map/save pair before planning any operation.

Separate documented Rust player database files#

Facepunch lists several files with different notes, so “player data” is not one interchangeable category. Its file reference documents player.blueprints for blueprint progress, player.deaths for death information, player.states for state such as death markers and hostile timers, and player.tokens for Rust+ pairing tokens. It also describes sv.files as player signs and contact-system pictures.

Documented name	Facepunch’s stated role	Safe inventory label
player.blueprints	Player blueprints	Blueprint database; no deletion recommendation
player.deaths	Death information shown on login	Player death data
player.states	Death markers, hostile timer and other state	Player state; scope may include more
player.tokens	Rust+ pairing token; removing it requires players to pair again	Private Rust+ token data
sv.files	Signs and pictures from the contact system	Player-created image/sign data

The reference leaves player.identities unknown. Preserve that uncertainty instead of assigning it a purpose based on its name. A database filename also does not tell you whether a selective reset is safe: leave blueprint-only, player-only and map-only changes to their dedicated, current-build procedures. D01’s operation and recovery checklist helps you choose that procedure after the inventory is complete.

Keep SQLite -wal files associated with their database#

Some Rust database files can have a -wal sidecar because Rust uses SQLite write-ahead logging. SQLite explains that committed changes may still reside in the WAL and that separating it from its database can lose committed transactions or damage the database. The WAL is part of the database’s persistent state, not disposable clutter.

When you make a read-only file inventory, record a database and its sidecars as one related group. Do not remove, rename or independently copy a live -wal file. SQLite’s WAL documentation describes how these files work and why a consistent copy needs an appropriate process. For a recovery copy, follow the provider’s supported backup procedure or use a cleanly stopped source and a verified process; this guide does not claim to test your host’s backup implementation.

The same caution applies when an identity contains additional database suffixes such as -shm or numbered database variants. Record exactly what exists, its size and timestamp, then verify the current software’s documentation before assigning a role. Do not infer file importance from whether its name looks temporary.

Inventory configuration, Rust+ and framework data separately#

The world save is only one part of an operating server. Facepunch documents cfg/ for settings, admins and banned players, server.cfg for configuration, loadouts/ for JSON files created through saveloadout, and serveremoji/ for custom server emojis. It documents companion.id as the server identity used by Rust+; handle it as private data and keep it within the proper identity and backup boundaries.

Installed frameworks and plugins add their own files. Their paths and persistence depend on the installed version and what each plugin stores, so Facepunch’s vanilla file table cannot define a universal Carbon or Oxide inventory. Record the framework and plugin versions, then follow the documentation for each component. Our maintainable Rust plugin guide covers why plugin state should be tracked separately from native server data.

Game Hosting’s Rust panel provides settings and full file access for server administration. Its backup tools offer three slots with manual or scheduled backups and restore/download controls. Those are product features, not proof that a panel backup contains every external database, plugin dependency or private file your setup needs; check the actual backup scope before relying on it.

Distinguish documented files from observed and unknown files#

Facepunch’s file table is the baseline, not an exhaustive promise for every build or installation. In one dated, isolated vanilla Windows test on build 25230300 (September 2026), the saved inventory included a matching procedural .map/.sav, a .sav.1, an occlusion companion file, player.blueprints.17.db, player.states.288.db, clans.288.db and database WAL sidecars. The source, protected copy and restored copy had matching names, sizes and SHA-256 hashes before the same-build restore loaded.

That is historical evidence from one test identity. It is not an October build inventory, a requirement that every server contains those files, proof that every file is necessary, or a test of player progression, plugins, Linux, a hosting panel or another Rust version. In the same Facepunch table, Log.EAC and player.identities remain explicitly unknown. Label files found only in an observed deployment as “observed here”; label unverified names “unknown” until their owner or current documentation confirms the role.

This distinction protects you from turning a sample directory into a destructive wildcard. A listing helps define questions for a backup or migration, but it cannot by itself prove the backup is complete or recoverable.

Make a read-only Rust server file inventory#

Create one record for the active identity. Capture exact names rather than broad globs, and include the provenance of each role. If the identity is hosted remotely, ask the provider for an export or file listing and record any folders you cannot inspect.

1. Resolve the identity

   Record the live server identity, the directory it resolves to, the game build, operating system and framework versions. If these details do not agree across the panel and server process, pause and ask which instance is active.

2. List observed files

   Record each exact filename, parent folder, size and capture timestamp. Keep matching map/save names and database sidecars visibly grouped, but do not rename or remove anything.

3. Label the evidence

   Use Facepunch documented, observed in this dated test, framework/provider-specific or unknown. Add a source link or test date for each role; never fill an unknown row from its filename alone.

4. Route the next operation

   Write what should change and what must survive, then use the appropriate backup, migration or wipe procedure. A file inventory is not approval to delete, overwrite or restore data.

Keep the record private if it includes a Rust+ identifier, account data or provider path. Once the scope is clear, choose the matching procedure in the Rust server data management guide; use that guide’s acceptance checks instead of treating a directory listing as a successful recovery test.

Quick answers

What is the difference between a Rust .map and .sav file?

Facepunch documents .map as terrain and monuments, while .sav holds world entities such as buildings and deployables. They are related files with different roles.

Which Rust server files are documented versus build-specific?

Facepunch documents several common identity files, but also marks some entries unknown. Record the exact names in your active identity and do not treat examples as a complete list.

Why can a Rust database have a -wal file?

SQLite write-ahead logging can keep committed database state in a sidecar. Keep it associated with its database when documenting or copying a consistent set.