Abiotic Factor sandbox save and config backup recovery workflow

Back up a state, not one isolated file

SandboxSettings.ini describes sandbox rules, but the world folder holds the state those rules affect. Copying only the configuration protects the text you typed; it does not protect the save before a risky test. A useful recovery point keeps the world and its matching configuration together.

The official Sandbox Settings page identifies the dedicated-server path as the server installation folder followed by AbioticFactor/Saved/SaveGames/Server/Worlds, then the selected world folder and SandboxSettings.ini. Local saves can be opened through the game's save-folder option. Use the game's current interface or official path documentation instead of assuming that another installation uses the same drive letter.

Stop the server or leave the world before copying. A backup made while files are changing can combine moments that never existed together. The goal is a stable snapshot, not merely a folder with today's date.

Create a backup manifest

Store each recovery point in its own folder. Give it a sortable timestamp, the world name, and a short reason. Beside the copied world, keep a plain-text manifest that answers the questions needed during recovery.

Do not put passwords, hosting tokens, or unrelated server secrets in a document that may be shared with players. The manifest is for save identity and change history, not account recovery.

Follow the stop-copy-change-start sequence

1. Announce the maintenance window and wait until players have left.
2. Stop the server or exit the local world cleanly.
3. Identify the active world folder and confirm its name in the host or game.
4. Copy the complete world folder to a location outside the active Worlds directory.
5. Open the copied folder and verify that it contains the expected files and a matching SandboxSettings.ini when one is used.
6. Record the current values and planned edit in the manifest.
7. Edit the active configuration, never the backup copy.
8. Start the server, load the named world, and perform a small verification.

The Sandbox Config Builder can generate a reviewed settings block, but paste only the keys you intend to change. Replacing a complete active file with an eight-key subset would discard other settings.

Verify the backup before relying on it

A copy operation completing without an error is not enough. Check that the backup is outside the active folder, its world identifier matches the intended save, and its size is plausible compared with the source. Open the manifest and make sure the timestamp and game version were recorded.

For an especially important world, test restoration to a separate temporary name or isolated server instance. Do not overwrite the live world merely to prove the backup. The verification should establish that the copied state can be selected and recognized without risking the active copy.

Use non-destructive recognition points: the world name, a known base location, the current objective, and one expected sandbox behavior. Avoid creating new progress in the verification copy if it might later be mistaken for the live save.

Diagnose the failure before restoring

Not every unexpected result requires a world rollback. Separate configuration loading problems from save-state problems.

The official page notes that a reload may be required for local changes and a restart may be required for server changes. Perform that documented step before deciding that a valid key failed. Also confirm the file starts with [SandboxSettings].

Restore without destroying evidence

Never rename the failed live folder over the only backup. Stop the server, copy the failed state to a quarantine location, and then restore a fresh copy of the known-good recovery point into the location expected by the host. Keeping the failed state allows comparison if the problem was a path or selection mistake rather than corruption.

Use the manifest to restore the configuration paired with that world. Mixing a newer world with an older ruleset may be intentional, but it is not the same as restoring the recorded state. If you choose to mix them, label the result as a new experiment and retain both originals.

After restoration:

1. Start with no players connected.
2. Confirm the server selected the intended world.
3. Check one known location or objective from the manifest.
4. Verify one sandbox rule with an observable effect.
5. Stop again if the identity or behavior does not match; do not continue play and overwrite more history.

Retain multiple recovery points

One backup can silently preserve the same problem as the live state. Keep a small rotation: a pre-change recovery point, the last accepted configuration, and an older milestone copy. Store at least one outside the machine or service that hosts the active world so a disk or account failure does not remove both.

Retention should follow meaningful events rather than random file growth. Good moments include before a game update, before a sandbox-system change, after a major progression milestone, and after a restoration is verified. Record why a copy exists before deleting an older one.

Avoid common recovery traps

• Do not edit the only backup to “fix it before restoring.” Restore a copy.
• Do not keep backups inside the active Worlds directory where the host may detect or modify them.
• Do not assume the newest timestamp is the correct world without checking the manifest.
• Do not continue a live session after detecting the wrong world or missing progress.
• Do not change configuration and mods during the same recovery test.
• Do not share a server archive before checking it for unrelated credentials.

Completion condition

The workflow is complete when the server is running the intended world, the current sandbox values match the accepted manifest, players can recognize the expected state, and both the restored copy and quarantined failed state are preserved until the next verified recovery point exists.

For planned rule changes, continue with the balanced sandbox preset guide. For larger groups, use the multiplayer scaling guide to separate encounter, progression, and logistics tests. Recovery should remain a separate operation: first restore a known state, then design the next change.