Back up and restore a Rust server save

A Rust backup needs the world save, the player database files, your config and your plugin data, and the Backups page in your panel takes all of it in one go.

6 min read · Updated Oct 21, 2026 · By GuavaHost Team

Rust spreads a server's state across several files, which is why "I backed up the map" sometimes turns out to mean "I lost everyone's blueprints". It is worth knowing what lives where before you need it.

Which files hold what

Everything sits under the server/ folder, then your server identity (usually rust), so paths look like server/rust/.

• The world. The .sav files hold the map and everything built on it: bases, deployables, boxes and their contents, tool cupboards, dropped loot. Rust keeps a few numbered generations of these, so the folder normally has more than one.
• Player data. A set of .db files sitting next to the saves. player.blueprints holds learned blueprints, player.identities the player records, player.deaths respawn points, player.states per-player state and player.tokens auth tokens. The exact filenames carry a version number that Facepunch bumps occasionally, so read the folder rather than trusting a filename you memorised.
• Config. server/rust/cfg/ holds server.cfg with your convars, plus users.cfg (your ownerid and moderatorid entries) and bans.cfg. Losing this means re-adding every admin and every ban.
• Plugins and their data. oxide/ or carbon/, depending on your framework. The plugins folder has the .cs files, config (or configs) has their settings and the data folder has what they have accumulated: economy balances, kit cooldowns, clans, zones. The data folder is the part nobody thinks about and the part that genuinely cannot be rebuilt.

The simplest rule: back up the whole server rather than picking files. A full backup is one click and removes the chance of missing the folder that mattered.

A wipe is not a restore

These get mixed up, and the difference matters when something has gone wrong.

A wipe deliberately throws state away so players start fresh. It is a feature of the game's cycle. Rust wipes: map wipe vs blueprint wipe covers what each kind clears, and How to schedule automatic Rust wipes automates it.

A restore puts state back to how it was at a point in time, because something broke: a plugin ate an economy, an update went badly, or someone deleted the wrong folder. It overwrites the current state, so anything that happened since is gone.

They point in opposite directions. What they have in common is that you want a backup immediately before either.

One asymmetry to know: Facepunch's monthly force wipe is not restorable. The update changes the game files enough that the previous month's .sav cannot be loaded by the new build, so a backup from before a force wipe is useful for your config, admins and plugin data but will not give you the old map back.

Take a backup

1. Sign in at customer.guavahost.com, open My servers and click Manage on your Rust server.
2. Open Backups in the server menu and click Create backup.
3. Give it a Name you will recognise later. before raidable bases is useful; backup 3 is not.
4. Click Create backup. The server keeps running, and the backup shows Ready in the list when it has finished.

Two options on that page are worth knowing. Lock on a backup means it is never removed to make room and cannot be deleted until you unlock it, which is what you want for the one taken just before a big change. Download saves a copy onto your own computer, which is the right move before anything drastic.

Backups: creating, restoring and scheduling has the full detail, including how backup slots work and how to schedule them. If the server is one you genuinely cannot afford to lose, Daily Off-site Backups also copy it to separate cloud storage each day, so a problem with the machine itself cannot take your backups with it.

When to take a backup

Rust gives you clear moments:

• before adding, removing or updating a plugin, especially anything that touches the economy or player data
• before a framework update, and before the monthly Rust update
• before changing server.worldsize or server.seed, since both regenerate the map
• before any manual file deletion in the server/ folder
• before handing admin to someone new
• nightly, on a schedule, so you never have to remember any of the above

Set the nightly one up on the Scheduled tasks page and leave Skip if the server is offline unticked so it runs even when the server is off. Setting up an automatic daily restart explains how schedules are built, and a backup step works the same way.

Restore a backup

1. Stop the server with Stop at the top of the server page. Rust writes its save files as it runs, so restoring under a live server risks it overwriting what you just put back.
2. Open Backups, find the backup you want and click Restore.
3. Choose what happens to files added since the backup was taken:
   • Keep them puts back only what is in the backup and leaves newer files alone. This is the right choice most of the time.
   • Also delete files added since this backup gives you the server exactly as it was. Use this when you are undoing a plugin install and want its leftover files gone too.
4. Confirm, and wait. The server shows Restoring backup while it works and restarts when it is done.
5. Watch the Console as it boots. Rust loading an older save takes a moment, and a plugin complaining in the log is your early warning that the restore did not include something it expected.

Before you restore, consider taking a backup of the current broken state. It costs you a slot and it means you can get back to where you are now if the restore turns out to be the wrong call.

Restoring only part of it

Sometimes you want one piece back rather than the whole server: a plugin config you overwrote, or users.cfg after you cleared your admins by accident.

Download the backup to your computer, open the archive locally, pull out the file you want, then upload just that file to the right folder with Upload files on the Files tab. Stop the server first if it is a file Rust or your framework writes to while running.

Moving a Rust server somewhere else

The same files are what you carry when you move. Migrate a Rust server covers the move itself, What to back up before migrating covers what to collect first, and A backup plan for your game server is the general version.

Common questions

Which files do I need to back up on a Rust server?

The .sav world saves, the player.* database files beside them, the cfg folder with your convars, admins and bans, and your oxide or carbon folder including its data directory. Backing up the whole server in one go is easier and safer than picking files, which is what the Backups page does.

Can I restore a Rust map after a force wipe?

No. Facepunch's monthly update changes the game files enough that the old world save cannot be loaded by the new build, so the map is gone whatever you have saved. The backup is still worth having for your config, admin list, bans and plugin data.

Will restoring a backup bring back player blueprints?

Yes, if the backup included the player database files, since blueprints live in player.blueprints rather than in the map save. This is exactly why a backup of only the .sav files is not enough.

Should I stop the server before restoring a backup?

Yes. Rust writes its save files while it runs, so a live server can overwrite the files you have just restored. Stop it, restore, then start it and watch the Console as the older save loads.

Still stuck? Jump into our Discord at discord.gg/GuavaHost and the team will help you out.

• rust
• backups
• restore
• save files
• wipe

Host a Rust server From $15.99/mo, with instant setup and DDoS protection.

Still need help? Our team is online 24/7 to answer questions.

Contact support