So you've ended up with a Rust wipe everyone actually likes. A decent seed, a healthy player count, blueprints earned the hard way, and now you either want a proper backup before the next forced wipe Thursday or you're moving to LOW.MS from another host. Copying a Rust world between servers is doable. It's a few minutes of careful file work and one gotcha about protocol versions that catches people out.
One thing to say up front: Rust has no "singleplayer save" to upload the way Palworld or 7 Days to Die do. Every base, blueprint and inventory is server-side. So this guide is about server-to-server transfers and pre-wipe backups, not client uploads.
Where Rust keeps your server's files
Rust stores everything for one running server inside a folder named after the identity it was launched with:
server/<server.identity>/
That <server.identity> is whatever got passed into +server.identity on the startup line. On a fresh LOW.MS Rust service the identity is already set for you – to check yours, open Commandline Manager in the panel and look for +server.identity in the active command line.
The bits that matter for a move are these:
cfg/server.cfg– hostname, slots, RCON password, gameplay convarscfg/users.cfg– ownerid and moderatorid entriescfg/bans.cfg– banned Steam IDsproceduralmap.<size>.<seed>.<protocol>.map– the cached terrain for that seedproceduralmap.<size>.<seed>.<protocol>.sav– the world state (your bases, loot, everything built)player.blueprints.<N>.db– unlocked blueprints per playerplayer.deaths.<N>.db– death markersplayer.identities.<N>.db– SteamID to display-name mappingplayer.states.<N>.db– player inventories and positionsplayer.tokens.<N>.db– assorted player tokens
The <N> on both the .sav filename and the .db files is the Rust network protocol version. Facepunch bumps it on every forced wipe and on most patches in between. When the number changes, Rust writes brand-new files – the old protocol's files sit on disk ignored.
A working save looks something like:
proceduralmap.4500.702380609.247.sav
That decodes as <level type>.<worldsize>.<seed>.<protocol>.sav. When the server saves, it doesn't delete the previous file – it renames it with a trailing .1, and older backups shift to .2, .3 and so on. So in a running server's folder you'll usually see the current .sav plus a handful of .sav.1, .sav.2 backups.
The .map file is just a cached terrain render for the seed. If it's missing, Rust regenerates it on startup from the seed and worldsize. It's safe to ship with the rest of the move, and it shaves some boot time off the first start.
Before you do anything
Stop the source server first. Rust holds open file handles and writes save ticks every few minutes by default, so a copy taken mid-write can be torn or partial. On LOW.MS, go to control.low.ms, find the Rust service, and stop it from the main panel view before you grab anything.
Take a fresh backup on both ends too. The Cloud Backup option in the sidebar gives you a one-click snapshot of the whole service. Do it on the destination before you overwrite anything, even if the server looks fresh. Five seconds now saves you an hour of "where did the wipe go" later if the import flakes out.
Two Rust-specific gotchas worth knowing before you start:
- You cannot carry a save through a forced wipe. First Thursday of every month Facepunch ships a mandatory update that bumps the network protocol, and every server has to regenerate its
.sav. If you try to restore an older protocol's save onto an already-updated server, the file sits on disk and Rust ignores it. Time your transfer between forced wipes, not across one. - Blueprint files and the map save are independent. The
player.blueprints.<N>.dbfile and the.sav/.mapfiles live side by side but Rust doesn't care if one is present and the other isn't. Useful when you want fresh terrain but want to keep what players have learned. Just remember the protocol number has to match the server build.
Uploading via File Manager
The panel's File Manager handles this fine for most moves:
- Log into
control.low.msand select your Rust service - Click File Manager in the sidebar
- Drill down into
server/<your identity>/ - Upload your
.map,.sav,player.*.dbandcfg/files, overwriting what's there
File Manager takes folder uploads, which is handy because on a full move you can just drag the whole identity folder across. Rust map saves are typically a couple of hundred megabytes once a world is built up, but a busy late-wipe map with lots of player structures can push into the gigabyte range. Past about 500 MB the browser uploader gets noticeably sluggish, and SFTP is the better tool.
Uploading via SFTP
SFTP on LOW.MS is on port 8822. Any standard client works – I'd reach for WinSCP on Windows or FileZilla cross-platform. Connection details are in Service Settings on the panel.
- Protocol: SFTP
- Host: the address shown in Service Settings
- Port: 8822
- Username / password: same as your panel credentials for this service
Once connected, navigate to server/<your identity>/ on the server side and drag your local files across. SFTP handles large transfers more reliably than the in-browser uploader, gives you a proper progress bar, and resumes cleanly if your connection drops mid-upload. For a full move I just drag the whole identity folder over and let it overwrite.
Matching the identity
This is the step people forget when they're moving between hosts.
If your incoming files were saved under server/oldhost_identity/ and your LOW.MS server boots with +server.identity "rustserver", those files won't load until the folder and the identity match. Rust doesn't care what the folder is called – only that it matches whatever +server.identity says at launch.
Two options:
- Rename the folder to match your new identity (easiest)
- Change the identity in Commandline Manager to match the folder name you uploaded
Either way, the folder on disk and the +server.identity value on the launch line have to be the same string. If they don't, Rust creates a new empty identity folder on next boot and your save sits there untouched.
You'll also want the world parameters to match the filename. Open cfg/server.cfg or check Commandline Manager and confirm server.worldsize and server.seed line up with the numbers inside the .sav filename. If your save is proceduralmap.4500.1234567.247.sav, the launch needs +server.worldsize 4500 and +server.seed 1234567. A mismatch and Rust generates a fresh map and ignores your save.
Same goes for the protocol number in the filename. If your .sav says .246.sav but your Rust server is on protocol 247 because it's been updated, the file won't load. There's no forward-migration. The only reliable fix is making sure both source and destination are on the same Rust build before you copy, which usually means doing the move the same day you take the backup.
Starting up
Start the server from the panel. The first boot with an imported save is slower than a cold start – Rust has to load every entity in the world before players can connect. On a busy late-wipe map this can run several minutes, so don't panic if the console sits on Loading entities for a while.
Watch Web Console for the startup logs. Once you see Server startup complete and the player count goes ready, grab the IP and port from Service Settings and join. Your old admins will still have ownerid status if you brought users.cfg across with the rest.
A few things worth knowing
The Rust .sav format is a custom binary serialiser. There's nothing useful you can do with it in a text editor. The .db files are plain SQLite, so you can technically open them in DB Browser for SQLite to peek at blueprints or bans, but Rust won't notice if you hand-edit them and there are easier ways to do most of what you'd want there – RCON commands, the config files, or a plugin.
If you're running Oxide, uMod or Carbon, those install as a separate layer on top of the vanilla server and Facepunch's monthly patch overwrites them. After every forced wipe you'll need to reinstall the mod framework via Mod Manager in the panel, and usually wait a day or two for plugin authors to push compatible builds. The plugin data under oxide/data/ survives wipes and travels with the rest of the server folder, so your configs and permissions stick around even when the framework itself gets replaced.
If something goes sideways after the import, that's what the backup is for. Open Cloud Restore, pick the snapshot you took before touching anything, and you're back where you started. For more on getting a Rust server up and healthy from scratch, see the Rust troubleshooting guide.