# Move Rust plugin data to a test server without losing state

Copying a Rust plugin's source file does not necessarily copy its saved state. Use this workflow to prepare a test instance before an update or migration. It is intended for administrators with panel file access and permission to copy their own server data. The production server remains the authoritative copy throughout the test.

## Inventory the plugin's state

Record the plugin name, installed release, dependencies and loader version. Read that release's documentation for configuration, data, language files and any external database. [uMod documents](https://umod.org/documentation/plugins/configuration) the default configuration location as `oxide/config`, but hosts can relocate it. Do not assume all persistent data lives beside the configuration.

List the specific files or folders the plugin author names. Check whether there is a documented export or shutdown procedure. For example, [Raid Tracker's upgrade notes](https://umod.org/plugins/raid-tracker/) distinguish several directories and warn that its v1 and v2 formats are incompatible. That is a reason to follow the exact plugin's instructions, not a universal migration recipe for every plugin.

## Make a consistent copy

1. Prepare a separate test service, identity and allocated ports. Disable public announcements and production-facing integrations there.
2. Schedule a short production maintenance window if the plugin cannot provide a documented consistent online export. Stop normally and wait for plugin shutdown activity to complete.
3. Create a full panel backup and record its identifier. Then copy the documented plugin files and related state together, preserving the directory layout and filenames.
4. For an external database, use a consistent export prepared by an authorised database administrator. Put it in a separate test database with a different restricted user. Never point the test plugin at production.
5. Restart production unchanged once its checkpoint is complete. Keep the captured copy read-only as your baseline and work from another copy in the test instance.

## Prove the baseline before upgrading

Install the same plugin release on the test server first. Check startup logs for missing dependencies and data-format errors. Choose a small set of known records relevant to that plugin, such as one permission group or one stored record, and compare them with your checkpoint notes. Avoid testing paid rewards or outgoing webhooks against live accounts.

Only after the unchanged copy behaves correctly should you apply the proposed plugin update to a second test checkpoint. Compare the author's schema-migration instructions carefully. A plugin that starts without a compile error may still have ignored or regenerated its data. Inspect file changes and functional behaviour, not just the green running indicator.

## Keep rollback coherent

If the new release fails, stop the test and restore its matching old plugin, configuration and data set together. Do not run an older binary against data already converted by a newer release unless the author explicitly supports it. Preserve the failed test logs for the maintainer.

Do not copy test progress back over production after players have continued playing. A later production rollout needs a fresh checkpoint and the same verified migration steps. Keep both release notes and backup references with the change record so staff can distinguish a tested procedure from a one-off file transfer.

## Related help

- [Repair a Rust plugin JSON configuration without losing data](https://help.cloudexa-hosting.com/books/rust/page/repair-a-rust-plugin-json-configuration-without-losing-data)
- [Manage Oxide plugin permissions without granting everyone admin](https://help.cloudexa-hosting.com/books/rust/page/manage-oxide-plugin-permissions-without-granting-everyone-admin)
- [Schedule game server backups and check retention](https://help.cloudexa-hosting.com/books/game-hosting/page/schedule-game-server-backups-and-check-retention)