A backup, a virtual-machine snapshot, and a learning checkpoint preserve different kinds of state. Choose the recovery mechanism for the thing you need to recover, then test it on a separate destination.
| Mechanism | Intended scope | Current documentation boundary |
|---|---|---|
| Core backup API | Engine data through the core backup implementation | Registered create, list, restore, and delete operations |
| VM snapshot | Runtime and disk state according to the infrastructure provider | The audited UI Snapshot button does not execute a snapshot |
| Continual checkpoint | Learning or component state | Current HTTP handlers are acknowledgment-only; restore is not implemented there |
Create and verify a core backup
The maintenance API defines the exact requests. The create request takes backup_dir and optional backup options. That directory is on the server, not a path on the laptop making the request. A hosted service must provide an allowed storage destination; do not invent one.
A successful create should be followed by a list/read of the backup metadata. Record the source instance, version, timestamp, destination, and any identifiers returned. Keep the backup outside the same failure boundary as the data it protects when the deployment supports that arrangement.
Test recovery separately
Restore to an explicitly designated test destination using the documented schema. Verify representative records and required indexes through fresh reads. Confirm the restored instance's authority and service configuration as well as its data.
Never use a production restore as the first test of a backup. Do not interpret ok: true from the unfinished continual recovery handler as a successful restoration.
Retention and deletion
Determine retention according to your application and actual storage policy. Deleting a record, deleting a backup, and terminating an instance are separate actions. A removal workflow must account for the copies it is expected to cover.