Rust Carbon to Oxide Migration: Roll Back Safely
Rust carbon to oxide migration: plan a safe rollback, protect newer plugin data, and verify what can be restored before changing a live Rust PC server.
You will need
- Administrator access to the Rust PC server and its files
- A complete recovery point from before the Oxide-to-Carbon change
- A private destination for an isolated restore rehearsal
- The current versions and support notes for required plugins and extensions
If you need to move a Rust server from Carbon back to Oxide, do not copy Carbon folders into Oxide and assume the data will work. Carbon’s current migration guide documents the forward move from Oxide to Carbon; it does not give a reverse data-conversion procedure. The safest return to a known Oxide setup is a complete, verified recovery point from before the change. If you need to keep progress written under Carbon, test a documented import route for the exact plugins and versions first. This guide helps you choose between those two outcomes without overwriting the only copy of your newer data.
Rust Carbon to Oxide Migration: Choose Rollback or Data Import#
Write the intended result in one sentence before stopping the server. “Go back to Oxide” can mean restoring the earlier Oxide environment, or moving current Carbon-era plugin and permission state into Oxide. Those are different jobs.
| Goal | Safer route | What may be lost or remain unknown |
|---|---|---|
| Return to the exact earlier Oxide setup | Restore the complete pre-Carbon recovery set on a private destination | World and plugin changes after that snapshot |
| Keep newer world progress but change framework | Confirm each plugin’s Oxide import support, then test the exact data on an isolated copy | Unsupported plugin records, extensions, permissions or settings |
| Keep Carbon while deciding | Preserve the current Carbon identity and postpone framework changes | No change is required until a tested route exists |
The Carbon Oxide Porting guide describes prerequisites and one-time automatic or manual copying from Oxide into Carbon. Its automatic path copies selected Oxide configuration, data, language, user/group and extension files into Carbon locations. That forward procedure is not proof that Carbon files can be copied in reverse. Facepunch’s Carbon overview describes intended Oxide plugin support, but it does not certify each plugin or reverse data compatibility.
If you would rather have the server panel, routine backups and framework files managed outside a home PC, we recommend Game Hosting’s Rust PC service. It includes an integrated panel and three free backup slots with scheduling, restore, download and locking. Those features give you a recovery workflow; they do not convert Carbon data into Oxide, so still verify your chosen plugins and restore set before changing a live server.
Protect the current Carbon state before touching files#
Preserve the current Carbon identity before testing any older recovery point. A rollback can replace files, and an attempt to migrate plugin records can alter their structure. Keep the existing copy intact so you can return to it if the Oxide test fails.
Record the active server identity, Rust build, Carbon version, plugin and extension versions, and the absolute directories used by the running process. Include plugin configuration and data, permissions, language files, external databases, custom assets and scheduled tasks in the inventory. A panel’s display name alone does not identify the files the process is using.
Stop the server through its supported shutdown path and confirm that the process has exited before making a consistent file copy. Pause any job that might restart it or reinstall Carbon. Record the capture time and compare file counts, sizes and checksums for the files you copy. Follow each plugin’s own instructions for separately hosted data or databases.
If the server uses Rust+, treat its companion identity as private recovery data. Do not run a test server and production server simultaneously with the same companion identity. Facepunch’s Rust+ server documentation explains the identity and pairing requirements.
Choose an Oxide recovery point that matches your goal#
Select the backup that represents the Oxide state you actually want, not simply the newest archive. For a full rollback, choose the last known-good point before Carbon was installed. If the restore predates a wipe, Rust update, or other file-format change, check the current build requirements and compatibility before starting it.
Use the Rust server data-management guide to classify the operation and prepare a consistent restore. Compare the recovery manifest with the current inventory: Rust world files, player and blueprint databases, server configuration, Oxide framework files, plugin versions, permissions, extension DLLs and any external services. Missing components should stay marked unknown until you locate them.
| Recovery check | Record before the rehearsal |
|---|---|
| Snapshot time and reason | Why this point is the intended rollback |
| Rust build and protocol | Source version and compatible test version |
| Framework and plugins | Oxide version, plugin versions and extensions |
| Data scope | World, player, configuration, plugin and external database files |
| Integrity | File count, sizes and checksum result |
| Accepted loss | Progress created after the chosen snapshot |
If an essential plugin database or extension is absent, stop and ask its maintainer for the supported export path. A folder with the right name is not evidence that it contains a compatible or complete data set.
Restore the earlier Oxide set on an isolated server#
Rehearse the selected recovery on a separate destination before changing the live installation. Use a separate identity and isolated ports, keep public access closed, and make sure the process cannot write to the live Carbon files or shared plugin services.
Prepare the private destination
Install the Rust build and Oxide version required by the chosen recovery point. Give the test server its own identity, file location and ports. Disable public listings and any scheduled update or loader job that could add Carbon again.
Restore the complete Oxide recovery set
Keep the destination stopped while placing the selected recovery files. Use the documented recovery scope rather than copying only the world save. Keep the original archive protected and record the restored file manifest.
Start once and inspect the result
Start the isolated instance and inspect its console and logs for the Rust build, Oxide load, plugin errors and missing extensions. A successful server boot proves only that the process started; it does not prove that every plugin or player record survived.
Keep the test private until checks pass
Connect only with an authorized test account if your acceptance plan requires a player check. Do not let a test clone register the production Rust+ identity or write to a production database.
Carbon’s guide says Oxide and Carbon cannot coexist in one server install. Stop Carbon and pause any loader automation before testing Oxide. Keep the frameworks in separate installations during the rehearsal; do not overwrite the only copy while changing files. Avoid deleting an unknown directory to “clean up” until your inventory identifies its contents and a recovery copy exists. If you need the initial framework procedure instead of a Carbon migration, use the guide to installing and verifying Oxide on a Rust server.
Test plugin state instead of assuming it transferred#
Build an acceptance list from the features your community actually uses. Check each plugin independently because common files and command names do not establish identical storage formats.
| Area | Test on the private Oxide destination |
|---|---|
| Framework | Oxide version loads and matches the target Rust build |
| Plugins | Each required plugin loads at the recorded version without unresolved dependencies |
| Commands | Required chat, console and RCON commands behave as documented for that plugin |
| Permissions | Expected users and groups retain only the recorded grants and restrictions |
| Persistent data | Representative balances, kits, teleports, claims or other plugin records match the chosen recovery point |
| Players and world | A known player and expected structure or world state are present |
| External services | Any plugin database or API connection is private, reachable and using the test credentials |
For every row, record the expected value, observed value, evidence file and pass/fail/unknown result. If a plugin author does not document importing Carbon-era records into Oxide, keep that data marked unknown. Do not invent a folder mapping or change a live database to see what happens.
Record any framework-specific commands or aliases the server uses, then check their equivalents in the target Oxide version. A command alias does not convert permission or plugin data. Ask plugin maintainers for direction-specific instructions and test them against the exact versions in your manifest.
Cut over only after the group accepts the result#
Choose one route after the isolated rehearsal:
- If the old Oxide recovery point meets the group’s requirements, agree that progress after its timestamp will be lost before cutover.
- If a required Carbon-era record has no documented and tested Oxide import path, keep the Carbon copy and delay the return.
- If the tested restore misses a required plugin, player record or permission, leave production unchanged and investigate the missing dependency.
- If the group accepts a known gap, record who approved it and what will not return.
Before cutover, stop both test and production processes, verify the target identity and file manifest again, and restore only the tested Oxide set to the intended live destination. Do not run old and new worlds as competing public servers. Retain the protected Carbon snapshot and the rollback manifest until the group signs off after reconnecting.
For managed Rust PC hosting, confirm the target service’s current framework and file-access options before moving. The server must still pass the plugin-specific recovery checks above; renting hosting does not make an unsupported reverse conversion safe. Rust Console Edition is a separate platform and is not compatible with this PC hosting route.
Keep a handover record for the next administrator#
Save the decision and evidence with the protected recovery material. Do not include RCON secrets, pairing tokens or private credentials in a public ticket.
Chosen outcome: rollback / tested plugin import / remain on Carbon Production identity and Rust build: Carbon snapshot location and capture time: Chosen Oxide recovery point and accepted progress loss: Oxide and plugin versions: Isolated destination identity and ports: Integrity check and restore result: Plugin, permission, player and world checks: External database checks: Failed or unknown items: Approval owner and cutover time: Rollback point retained until:
The decision is complete only when another administrator can see which state the group chose, what the isolated test proved, and what remains unknown. A clean startup is one check in that record—not proof that Carbon-era progress returned.
Quick answers
Can I move Carbon data directly back to Oxide?
Do not assume so. Carbon documents the Oxide-to-Carbon direction, not a universal reverse conversion; confirm and test each plugin or extension data format with its author.
What is the safest way to return to Oxide?
Restore a complete, known-good Oxide recovery point to an isolated destination, then validate the build, framework, player state and required plugins before replacing the live instance.
Will I keep progress made after installing Carbon?
A pre-Carbon restore returns to that earlier point, so later world and plugin changes may be lost. Preserve the Carbon copy and test an author-supported import before deciding.
Can Oxide and Carbon run together during the switch?
Carbon says they cannot coexist in one server installation. Keep each test isolated and shut down the old process before changing framework files.