# Restore an ARK Ascended checkpoint with consistent player and tribe data

An ARK: Survival Ascended restore should return a coherent point in time. Replacing only the map can leave characters, tribes or transfer data from another moment. Plan the checkpoint before touching the live files, and keep a separate copy of the current state even when you believe it is broken.

## Define the recovery point

Record the affected map, approximate incident time, server build and mod list. Decide what progress will be lost and tell players before restoring. A backup timestamp describes when an archive was created; it does not prove every file inside was captured consistently. Prefer a checkpoint made after a normal save and clean stop.

Identify the actual active save directory through the file manager or support. ASA installations can have map-specific save locations, and Windows server builds under a Linux compatibility layer do not follow a universal Linux-native path. Include the map state and its associated player and tribe files. Keep configuration, startup information and the mod list with the checkpoint so recovery is reproducible.

## Stop writes before copying

1. Announce maintenance and prevent players from joining during the recovery window.
2. Request a supported normal save and stop the server gracefully. Wait until the process has exited rather than assuming a disconnected console means it stopped.
3. Download or create a named pre-recovery archive. Verify that the archive opens and contains plausible file sizes and the intended map.
4. Preserve the selected backup separately. Work from an extracted copy, keeping the original archive unchanged.

If the server belongs to a cluster, also freeze transfers and coordinate the affected members. Transfer data cannot safely be treated as unrelated temporary files. A one-map rollback while characters keep moving through the cluster can introduce losses or duplicated state.

## Validate before replacing the live checkpoint

Where possible, restore to an isolated test installation with the matching game and mod combination. Keep it inaccessible to ordinary players and disconnected from live cluster transfers. Loading an older save with newer game code can upgrade it; preserve the untouched archive before testing. Do not assume an upgraded save will load again under older binaries.

Check the map, several established characters, tribe membership, base ownership and important creatures. For a modded world, verify representative mod content. Perform a normal save, stop and second start to check that the recovered state persists. Creating a new survivor when an existing one is expected is a signal to stop and investigate, not proof the restore finished.

## Reopen and retain a fallback

Apply the validated checkpoint during maintenance and repeat the important checks. Resume cluster transfers only after support confirms consistency. Keep both the pre-recovery archive and restored checkpoint until players confirm normal operation. Record the chosen timestamp and expected lost progress so later reports can be evaluated accurately.

If restoration fails, leave both archives intact and send support the first startup error, map, build and file inventory. Do not delete player profiles, overwrite tribe files individually or run a world wipe to make the error disappear.

## Related guides

- [Plan a safe ASA cluster](https://help.cloudexa-hosting.com/books/survival-games/page/plan-an-ark-ascended-cluster-without-risking-character-transfers)
- [Move an ASA save safely](https://help.cloudexa-hosting.com/books/game-hosting/page/move-an-ark-survival-ascended-save-safely)

## Further reading

- [ARK dedicated-server file layout](https://ark.wiki.gg/wiki/Dedicated_server_setup)
- [ARK administrative commands](https://ark.wiki.gg/wiki/Console_commands)

Looking for another game? [Browse game server setup and troubleshooting guides](https://help.cloudexa-hosting.com/books/game-hosting/page/find-setup-and-troubleshooting-guides-for-your-game-server).