# Take a Rust save checkpoint before a planned panel restart

Use this checklist before planned Rust maintenance when you want a clear recovery point. A game save and a panel backup solve different problems: one records the current world, while the other preserves a copy that can survive later damage. Neither a green panel button nor a restart timer proves that a usable recovery copy exists.

## Prepare a quiet maintenance window

Announce the time and timezone, ask players to finish active trades and record the server identity. Check that no backup restore or update is already running. Save the current configuration and note the latest successful backup's timestamp, status and size. Ensure the backup destination has enough allowance before starting another archive.

For modded servers, read each important plugin's persistence instructions. A plugin may hold separate state, use a database or write on a different lifecycle event. Do not assume a base-game save automatically commits every external economy or inventory system. If its documentation is unclear, stop and ask the plugin maintainer before promising a lossless live snapshot.

## Create the checkpoint

1. Watch the console during the final maintenance warning. Avoid starting another long-running administrative operation.
2. Use the normal game-panel stop action configured for Rust. If you administer through an authenticated Rust client instead, [Facepunch documents](https://wiki.facepunch.com/rust/useful_commands) `sv quit` as saving and closing the server. Do not type a client-only quit command and assume the remote process stopped.
3. Wait for the process to exit. If the panel stays stopping, preserve the console output and ask support rather than repeatedly forcing it down.
4. With the server stopped, inspect the expected identity folder and record the save filenames and modification times. Do not rename saves to match a different world or protocol.
5. Create a panel backup of the stopped service. Wait for its completed status and record the backup identifier. Download an authorised copy if your plan and policy require one.

## Verify before continuing

Check that the checkpoint contains the active identity and required plugin state, not just a similarly named folder. [Facepunch's file reference](https://wiki.facepunch.com/rust/Getting-Started_w-Server) distinguishes map saves, map terrain files and other player data. Keep the set together. Inspect the archive listing where available without unpacking it over the running service.

Now perform the planned maintenance and start normally. Join with a known player account and check an agreed landmark or stored item. Compare the result with your recorded checkpoint time. These checks are verification steps for you to perform, not a claim that CloudExa has tested this particular server.

## If startup or verification fails

Keep the failed-start logs and stop further writes before considering recovery. Do not immediately restore an old backup over new player progress. Compare the installed Rust build, plugin versions and save compatibility first, then agree the recovery point with affected staff.

A forced Rust wipe can change save compatibility; this checklist does not bypass it. Keep previous archives until the maintenance is accepted and retention policy permits removal. If a graceful stop consistently exceeds its allowance, have support investigate that timeout separately instead of making forced kills part of the routine.

## Related help

- [Find Rust server.cfg and the correct identity save folder](https://help.cloudexa-hosting.com/books/rust/page/find-rust-servercfg-and-the-correct-identity-save-folder)
- [Schedule game server backups and check retention](https://help.cloudexa-hosting.com/books/game-hosting/page/schedule-game-server-backups-and-check-retention)