Backups

A backup is the price of one extra write#

Every successful save keeps the previous version of that slot beside the new one. It costs one file and it is the difference between a corrupted write being an incident and being a disaster.

The write sequence that makes it trustworthy is: stage → flush → verify → promote → rotate.

1. The new file is written to a temporary name and flushed to the platform.
2. It is verified — read back, when VerifyWrittenPayload is on (the default).
3. Only then is it promoted into place, atomically where the platform allows it.
4. The previous version rotates into the backup position.

Because verification happens before promotion, a save that fails halfway leaves the previous version exactly where it was.

What retention 1 does and does not cover#

It also does not protect against a save that is valid but unwanted: an older version that a player deliberately restores (a rollback) cannot be detected on the client, because that needs a server-side sequence. See Security best practices.

Inspecting backups#

• The Save Browser shows a backup count per slot and can restore one, through the framework's own recovery path.
• RecoverAsync is the code path: it decides whether the primary is usable and, if not, which backup is the newest valid one.

Next#

• Recovery — the operation that uses these files.
• Corruption handling — what counts as damaged, and what does not.
• Configuration reference — retention, janitor ages and path limits.