How to Backup Your Rust Game Server
Why Rust servers need backups (even with wipes)
"Rust wipes every week, why would I need backups?"
This is the most common thing people say right before they lose something they cannot get back.
Yes, Rust wipes map data on a regular cycle. That is by design. But there is a lot of server data that is not meant to be wiped, and losing it mid-cycle is painful for everyone involved.
Here is what actually goes wrong:
- Mid-wipe server crash. The server crashes during a save. The map file is half-written. Players log in to find their base has vanished while everyone else's is intact. Good luck explaining that one in Discord.
- Oxide plugin corruption. A plugin update goes wrong, or two plugins conflict, and your entire oxide/data directory gets mangled. Player ranks, economy balances, teleport homes, kit cooldowns. All gone.
- Accidental config changes. You were tweaking server.cfg and deleted the wrong line. Or you overwrote your carefully tuned config with a default one. It happens more than anyone admits.
- Host-side failures. Your hosting provider migrates your node, has a disk failure, or "accidentally" deletes your server during a billing dispute. Your data was only on their hardware.
Backups protect against all of these. The map data might be temporary by design, but everything around it is not.
Where Rust server saves live
Rust keeps its important data spread across a few directories. Knowing which ones matter (and which ones you can ignore) is the difference between a 200 MB backup and a 5 GB one.
The critical files
server/rust/save/ is where the world lives. This directory contains:
- The procedurally generated map data (terrain, monuments, road networks)
- Player-placed structures and their contents
player.blueprints.5.db, the blueprint database. This one is special because it persists across map wipes. Losing it means every player on your server has to re-learn every blueprint. That will generate support tickets.
oxide/ (or carbon/ if you use Carbon instead of Oxide) is the plugin ecosystem. Inside you will find:
oxide/config/with JSON configuration files for every pluginoxide/data/with persistent plugin data (player records, economy data, teleport locations, permission groups)oxide/plugins/with the plugin files themselvesoxide/logs/with plugin logs (low priority for backups, but useful for debugging)
cfg/ holds server-level configuration:
server.cfgwith your server name, description, max players, tick rate, and other core settingsusers.cfgwith admin/moderator assignments
What to skip
RustDedicated_Data/contains the game runtime. It is large and can be reinstalled via SteamCMD in minutes.Bundles/contains asset bundles. Also reinstallable.HarmonyMods/if you use Harmony mods, these are also reinstallable from source.
Rust backup file reference
| File/Folder | What it is | Back up? |
|---|---|---|
server/rust/save/ | Map data and blueprints | Yes |
server/rust/save/player.blueprints.5.db | Blueprint database (survives map wipes) | Yes, always |
oxide/config/ | Plugin configurations | Yes |
oxide/data/ | Plugin persistent data | Yes, always |
oxide/plugins/ | Plugin .cs files | Yes |
cfg/server.cfg | Server configuration | Yes |
cfg/users.cfg | Admin/mod list | Yes |
RustDedicated_Data/ | Game runtime | No |
Bundles/ | Asset bundles | No |
The wipe cycle and what it means for backups
Rust's wipe cycle creates a layered backup situation that most backup guides overlook.
Map wipes (weekly or monthly, depending on your server): The map data in server/rust/save/ resets. Player structures, deployables, and loot all disappear. This is expected. You do not need to keep map backups from previous wipe cycles unless you want to archive them for some reason.
Blueprint wipes (monthly or less, Facepunch forced wipes): The player.blueprints.5.db file resets. Players start fresh with no learned blueprints. These happen less frequently than map wipes, and some servers skip them entirely.
What never wipes: Oxide data, plugin configs, server configs, admin lists. This data accumulates over months and represents significant setup effort. A well-configured Rust server with 30+ plugins, custom permission groups, and tuned configs took real time to build. Losing it means rebuilding from scratch.
This means your backup strategy should have two layers:
- During an active wipe: Back up map saves daily. If the server crashes mid-wipe and corrupts the save, you can roll back to yesterday instead of telling 50 players their progress evaporated.
- Always, regardless of wipe cycle: Back up oxide/config, oxide/data, oxide/plugins, and cfg. These are your server's identity. Protect them like it.
Method 1: Manual SFTP downloads
The simplest approach. Connect via SFTP, download the directories listed above, save them to your local machine.
This works exactly once. You will do it today because you are reading this article and feeling motivated. You will not do it again until something breaks, at which point you will discover your backup is from three weeks ago and does not include the 12 plugin config changes you made since then.
If you have actual discipline and can commit to doing this daily, more power to you. Most people do not.
Method 2: Cron script with rsync
If you have SSH access to your server (self-hosted or a VPS where you control the OS), a script works well:
#!/bin/bash
BACKUP_DIR="/home/backups/rust/$(date +%Y-%m-%d_%H-%M)"
SERVER_DIR="/home/rust"
mkdir -p "$BACKUP_DIR"
rsync -a \
"$SERVER_DIR/server/rust/save/" "$BACKUP_DIR/save/"
rsync -a \
"$SERVER_DIR/oxide/" "$BACKUP_DIR/oxide/"
rsync -a \
"$SERVER_DIR/cfg/" "$BACKUP_DIR/cfg/"
# Clean up backups older than 7 days
find /home/backups/rust/ -maxdepth 1 -mtime +7 -exec rm -rf {} \;
Schedule it with cron to run daily (or more frequently during active wipes):
0 4 * * * /home/rust/backup.sh >> /var/log/rust-backup.log 2>&1
This is solid if you have the access. The downsides: it requires SSH (most hosted server clients do not have this), the backups stay on the same machine unless you add rclone or similar, and if the cron job silently fails you will not know until you need it.
Method 3: Pterodactyl's built-in backups
If your Rust server runs on Pterodactyl or Pelican, there is a backup button in the panel. It works, but with the usual limitations: backs up everything (including the multi-gigabyte game runtime you do not need), host-controlled backup limits, no scheduling, and all-or-nothing restores.
We covered this in detail in our guide to Pterodactyl automated backups. The short version: it is fine for a quick snapshot before you make a risky change. It is not a backup strategy.
Method 4: Automated backups with Pink Narwhal
Pink Narwhal has a built-in Rust game profile that already knows which files matter on your Rust server. You do not need to configure paths manually or figure out which directories to include.
Here is how it works:
- Connect your Rust server. Add your Pterodactyl/Pelican API key or SFTP credentials.
- Select the Rust profile. Pink Narwhal detects your Rust installation and applies the right file selection automatically. Map saves, oxide data, configs. The game runtime and asset bundles get skipped.
- Pick a schedule. Daily during wipe cycles, or hourly if you want tighter coverage.
- Done. Backups run automatically and get stored in Cloudflare R2 with zero egress fees.
When something goes wrong:
- Browse any backup from your dashboard and see exactly what is inside.
- Restore individual files. Corrupted one plugin config? Grab just that file from yesterday's backup. No need to roll back everything.
- Restore oxide data without touching the map. Player lost their blueprints after a glitch? Pull just the blueprint database from a backup. The map stays untouched.
Pink Narwhal works with the access level you have. If you can log into Pterodactyl as a regular client, that is enough. No panel admin access, no SSH, no server modifications required.
Before and after wipe day
Here is a practical backup routine for Rust server operators:
During the wipe (daily):
- Automated daily backups of map saves, oxide, and configs
- If running an active competitive server, consider hourly backups for tighter recovery points
Before a map wipe:
- Trigger a manual backup (or let the scheduled one run)
- This is your safety net in case the wipe process goes wrong
After a map wipe:
- Verify your oxide data and configs survived the wipe correctly
- Trigger a post-wipe backup as your new baseline
Before a Facepunch forced wipe:
- Back up blueprints specifically (they will be wiped)
- Some servers archive pre-wipe blueprint databases for player reference
If you are also running Minecraft servers alongside your Rust server, our Minecraft backup guide covers the specifics for that game. And for general principles that apply to any game server, check out our server backup best practices guide.
Your Rust server's map might be temporary. Your community's data is not. Treat it accordingly.