Illustration for Back Up and Update a Rust Server Without Breaking Plugins

Back Up and Update a Rust Server Without Breaking Plugins

Create a consistent Rust backup, update through SteamCMD, reapply Oxide or Carbon, and validate the world, players, ports and plugins.

A Rust update changes game binaries and may leave a framework or plugin incompatible. The safe sequence is: back up, stop, update Rust, update the framework, start privately, then validate. Copying only the .sav is incomplete: the identity also contains the map, blueprints, player state, images and configuration.

What a Rust backup must contain

The folder selected by +server.identity is the main recovery unit. It includes:

  • the .sav world and .map file;
  • player.* files including blueprints and state;
  • sv.files, used by signs and related data;
  • cfg/, including server.cfg, admins and bans;
  • database -wal journals that belong to a consistent write set;
  • oxide/ or carbon/, including plugins, config, language, data and permissions.

Also preserve the startup script or provider variables. Seed, world size, ports and identity may not live in server.cfg.

Create a consistent restore point

1

Announce and reduce activity

Warn players, record Rust/framework versions and export the plugin list. Avoid updating during a raid or an administrative operation.
2

Force a save

Run server.save through console or RCON and wait for confirmation. This reduces unwritten in-memory state but does not replace stopping the process.
3

Stop cleanly

Shut down from console or panel and verify the process has ended. Copying databases and WAL files during writes may create an inconsistent set.
4

Archive the whole stack

Archive the identity folder, plugin framework and startup settings. Name it with date, Rust build, seed and worldsize, then download it off-host.
5

Inspect the archive

List its contents and verify it really contains the .sav, player files, cfg and plugin data. A successful but empty backup job is not a recovery point.

Update Rust, uMod/Oxide or Carbon

On a self-hosted server, update Steam app 258550:

steamcmd +force_install_dir /path/to/rust +login anonymous +app_update 258550 validate +quit

A provider's update button runs an equivalent action. Read its log and confirm the build actually changed.

SteamCMD returns binaries to vanilla. For uMod/Oxide, apply the build compatible with the new Rust version before starting. Carbon documents branch-aware self-updates; use production Carbon with public Rust and inspect the first boot. Do not pair a staging framework with the public game branch.

Do not restore old binaries onto a converted save

A force wipe can change the save protocol. Restoring only RustDedicated or renaming an old .sav to force it open may create an incompatible set. Restore a coherent stack and respect protocol limits.

Validate before reopening

Post-update checks

  • •The log reaches Server startup complete without a crash loop.
  • •Map, seed, worldsize and world date are expected.
  • •A test player retains position and blueprints when no wipe was planned.
  • •Owner/moderator commands and RCON work.
  • •Game and query ports answer and browser filters are correct.
  • •The framework reports its version and no essential plugin is in error.
  • •Plugin permissions, config and data survive another restart.
  • •A fresh post-update backup is created after validation.

If Rust starts in vanilla, do not immediately add every plugin. Stop, verify the framework, then test plugins in small batches. If one blocks startup, preserve the message, disable it and find a compatible release instead of rolling back the whole server.

Restore after a failed update

  1. Stop the server and archive the failed state so logs are preserved.
  2. Identify whether the game, framework, plugin or world fails by testing an isolated copy.
  3. For a complete restore, return identity, configuration and data from the same restore point together.
  4. Do not downgrade a world already converted to a protocol unsupported by the old server. When clients require the update, fix the framework or plugin instead.
  5. Validate with no players, then create a new archive once healthy.

The uMod/Oxide versus Carbon guide helps isolate the plugin layer. For an intentional reset, follow the Rust wipe guide so blueprints are not removed accidentally.

Update Rust with reliable backups

Compare Rust hosting with off-host backups, a console and controlled updates.

Frequently asked questions

Must Rust be stopped before copying saves?
Yes. Run server.save, wait, then stop. Player files use database journals, so copying during a write can produce an inconsistent backup.
Why did Oxide stop loading after SteamCMD?
SteamCMD validation restores vanilla Rust files. Install a uMod/Oxide version compatible with the new build before the first public start.
Does every Rust update cause a wipe?
No. Routine updates often retain the world. Some forced updates change protocol and require a map wipe; blueprints remain unless the operator removes their file or Facepunch explicitly requires it.

Sources: Creating a server, server.identity files, uMod Rust and Carbon auto-updates.

Our recommendation

Ready to launch your Rust server?

Here are the best Rust hosting deals right now, promo codes included. Still unsure? Our quiz finds the ideal host for you in under 2 minutes.

My box 12

Minestrator

17.99€/month
-10% with code HOSTMYGAME
Max players:50
Mods:
Yes

Specifications

RAM:12GB(DDR4)

Compatible games

Rust

Features

  • ✓DDoS Protection
  • ✓Backups

Wood

Shockbyte

12.84€/month
-25% with code LAUNCH
Max players:40
Mods:
Yes

Specifications

RAM:8GB(DDR4)

Compatible games

Rust

Features

  • ✓DDoS Protection
  • ✓Oxide mod support
  • ✓Instant Setup
  • ✓24/7 Support

Rust

OptiNAS

12.99€/month
-10% with code HOSTMYGAME
Max players:Unknown
Mods:
Yes

Specifications

RAM:16 Go

Compatible games

Rust

Features

  • ✓Environ 30 joueurs
  • ✓Minimum : 6 vCPU et 16 Go de RAM
  • ✓Conseillé : 6 vCPU et 16 Go de RAM
  • ✓Plugins et mods possibles selon le jeu
  • +2 more features