Rust Server Data Management: Backups, Wipes and Recovery

Rust server data management starts by naming what should change and what must survive. A backup preserves a recovery point; a restore returns to one; a wipe deliberately resets selected progress. Mixing those jobs is how a routine maintenance window becomes an empty world. This guide gives you an operation table, a recovery checklist and a handover record for Rust PC. Budget about 30 minutes to prepare the record; copying files and testing a restore take additional time. You will also see what our isolated server test proved, and which checks still require your own players and plugins.

Choose the right Rust server data management operation#

Choose the operation by the result your group wants, before opening a panel’s file manager. “Fix the server” is too vague to approve: recovering yesterday’s base and generating a fresh map are opposite outcomes.

A restart is a separate process event. It can be part of any row, but restarting alone is not a request to erase progress. Inspect scheduled jobs and panel actions because a button labeled restart may also trigger an update or another configured task.

For example, moving to a new host generally calls for migration with a recoverable source. A missing base after a bad change calls for incident investigation and possibly restoration. Neither problem becomes safer because someone presses a wipe button first.

Write the selected operation at the top of your maintenance note. If two administrators describe different desired outcomes, settle that disagreement before changing files. The table is your first approval check; later sections establish the evidence needed to carry out that choice.

Identify the running world before collecting files#

Identify the active process, its data directory and its build before trusting a folder that looks familiar. A hosting account can contain several identities, abandoned test worlds or exports from earlier migrations.

From an authorized server console, record these read-only queries:

version
server.identity
server.seed
server.worldsize

Resolve the resulting identity against the process’s actual working directory and launch configuration. Save the absolute path in your private operation record. A panel display name is not proof of the directory in use. Our Rust configuration ownership guide explains how to trace settings back to their persistent source.

Use a short inventory to decide what the recovery set needs:

Facepunch’s file reference distinguishes terrain files, world saves and player databases. Its examples describe roles, not a universal list of files to delete. Our test inventory also contained clan data and database journals, so a handpicked list based on an older guide would have been incomplete.

Record unresolved paths as blockers. Do not substitute a familiar folder name for evidence that the running instance uses it. You should be able to show another administrator both the process identity and the exact directory being protected.

Define what must survive the change#

Define preservation separately from deletion or replacement. “Wipe everything” often turns out to mean “give us a new map but keep our learned recipes, permissions and plugin records.” Those are different instructions.

For each operation, complete three columns before execution:

Choose the calendar with our Rust wipe schedule guide, then return to this preservation record. Calendar choice does not establish the files a particular build or plugin needs.

For a modded community, ask whether any plugin stores balances, permissions or progression outside the native identity directory. If it uses a remote database, an identity-folder copy alone cannot preserve that dependency. Get the plugin’s supported backup and restore procedure before approving the change.

Finish by naming the person who can accept intentional progress loss. A technically successful restore can still be the wrong operation if the group never agreed to lose everything created after its recovery point.

Require a consistent recovery set before maintenance#

A filesystem backup needs a consistent stopped state and a recorded scope. Copying whichever files finish first while the server continues writing does not establish one coherent recovery point.

1. Pause competing operations

   Coordinate with the other administrators and suspend scheduled wipe, update and restart jobs for the maintenance window. Record who will restore those jobs afterward. Identify any separate process that writes plugin or external database state.

2. Stop cleanly and confirm the process exited

   Use the supported server or panel shutdown path. Confirm the server process has exited and no scheduled action immediately launches it again. If shutdown fails, keep that uncertainty in the record and resolve it before relying on an ordinary file copy.

3. Capture the complete agreed scope

   Copy the identified data set and record its capture time, build and source path. Include the configuration and external dependencies needed for recovery, using their own supported consistency procedures. Keep the original protected while preparing the test copy.

4. Check the copy and its storage location

   Compare file counts, sizes and cryptographic checksums with the stopped source, or use equivalent archive verification. Store the recovery copy somewhere that survives loss of the server account or disk. Record any exclusions explicitly.

Database journal files deserve particular attention. SQLite’s WAL documentation explains that a remaining write-ahead log can contain committed database state. Do not discard one because it looks temporary. Our cleanly stopped Rust test still contained database files with WAL sidecars.

If a host offers a snapshot instead of a stopped copy, ask what consistency it guarantees and what it excludes. A green backup status is the start of that conversation, not the end of it.

Prove the restored world loads in isolation#

Test a recovery copy on a separate destination before authorizing replacement of the live world. Start with a compatible build and the intended launch inputs. Keep the test away from public players, production jobs and integrations that could write to shared services.

On September 14, 2026, we tested this narrow sequence on Windows using SteamCMD-validated dedicated-server build 25230300, protocol 2633.288.1:

Those seed and size values are test inputs, not recommended settings. Game, query and RCON listeners were bound to loopback. Rust+ was disabled for the test using Facepunch’s documented launch form:

+app.port 1-

The running server reported the companion port as minus one. Facepunch’s companion rules require keeping the companion identity private and avoiding reuse across multiple servers. Preserve the production recovery material securely; do not make a test clone register the production identity.

We verified a copied vanilla world loading, not full player recovery. No client joined, no player-built base or learned blueprint was checked, and no plugin, Linux runtime or hosting panel was tested. On your server, add those acceptance checks: a known structure, a player’s expected progression, relevant permissions and any essential plugin state. Record the observations separately rather than treating server startup as proof of all of them.

Check update compatibility before approving a reset#

Approve a reset against the current release and your actual recovery set. A backup captured before an update may be intact but incompatible with the server version you intend to run.

September’s Breach and Clear update shipped on September 3, 2026; the preceding Power Trip announcement explicitly identified that September wipe. Read the announcement for the update you are installing. A remembered calendar date does not answer which world or player data that release can accept.

Facepunch warns against renaming an old save to bypass a protocol change. A different filename cannot supply a missing format conversion. Our same-build restoration test also provides no evidence that the same files will work after every future update.

Use three questions at the release checkpoint:

• Does the target build support the recovery set’s world format?
• Does the announced update require changes to the map, blueprint policy or installed framework?
• Can you demonstrate the intended result in a supported isolated test before reopening?

If compatibility remains unknown, record it as unresolved and stop before replacement. Do not quietly reinterpret “preserve this world” as permission to generate another one. A forced update can change the options available, but the group still needs an explicit explanation of what will be lost and what can be retained.

Assign retention, access and provider responsibilities#

Set recovery expectations in terms the group can answer: how much progress could it accept losing, and how long could the server remain unavailable? Those answers determine how often you capture recovery points and how quickly someone needs to retrieve and test them.

For example, a group willing to lose one evening’s work still needs a copy from before a damaging change. Keeping only the newest backup may preserve the mistake and remove the useful history. Daily history plus a protected pre-maintenance copy is a possible policy, not a universal retention recommendation; choose durations from your storage limits and incident risks.

When evaluating a host, ask for the actual export scope, retention, deletion deadline, restore destination options and division of responsibility. Use our Rust hosting comparison checklist to turn those answers into purchase requirements. An advertised backup feature does not answer who checks the recovered world.

If your group wants to delegate the machine’s operation, review the current Rust PC hosting offer against this record. At our September 14 check, capacity was closed and the site offered a waitlist. Confirm availability and recovery capabilities before planning a move; this guide does not establish that a particular backup or restore service is included.

Self-hosting remains reasonable when someone can maintain the machine, protect an independent copy and perform the recovery checks. Renting helps when the provider takes on responsibilities your group wants to delegate and makes those responsibilities clear.

Hand over a completed operation register#

Finish with one record that another administrator can use to understand the change, find the recovery point and decide whether reopening is justified. Keep credentials and private companion files out of shared tickets or public logs.

Copy this template into your private maintenance notes:

Operation and reason:
Owner and backup operator:
Approved change / state that must survive:
Source process, absolute identity path and build:
Map/save pair and framework/plugin versions:
Recovery capture time and independent storage location:
Scope, exclusions and checksum/verification result:
Target identity, build and isolation controls:
Observed world, player and plugin acceptance results:
Expected progress loss accepted by:
Rollback decision and protected recovery artifact:
Reopen approval / jobs re-enabled / completion time:

For an incident, preserve the affected state before experimenting, when storage and access allow. Record which recovery point you selected and why later copies were rejected. For a migration, keep the source stopped during the final handover so two diverging worlds do not both receive player activity.

Treat missing acceptance evidence as unfinished work. “The process started” is enough for a process-start check; it is not enough for “everyone’s progression survived.” If the expected world is absent, keep public access closed and investigate the identity, scope and compatibility before approving another operation.

Once the responsible operator signs off, restore the agreed schedules and tell the group what changed, what was retained and whether any progress was intentionally lost. Keep the completed record with the protected recovery history. The next maintenance window should begin with evidence from this one, rather than another guess about which folder matters.