Backup run and verification API

Returns a backup run's capture, transfer, and operation details.

Requires backups:read. The result includes policy ID and revision, resolved source IDs, stage, capture time, transfer counters, destination, recovery-point ID, error, and operation reference.

Stages include preparing, capturing, resuming, copying, verifying, and cleaning_up. Resume failure is reported even when the captured data exists; operators must address the affected guest's application state.

A run that has finished capture and is copying data returns a result such as:

{
  "data": {
    "id": "bkr_daily01",
    "policy_id": "bkp_ledger",
    "policy_revision": 7,
    "stage": "copying",
    "capture_at": "2025-11-21T02:00:05Z",
    "recovery_point_id": null,
    "operation_id": "op_backup01",
    "source_ids": ["vol_database", "vol_journal"]
  }
}

Lists backup runs using the selected filters.

List with policy_id, state, destination_id, and standard pagination. Missing observations are not treated as completed zero-byte transfers.

Retries eligible transfer work against the run's captured source.

Requires backups:write. A retryable copy failure can reuse the run's captured source and transfer work. A new capture requires a new run and can represent different application data.

The response identifies reused transfer work and the attempt against the same captured point. A hook failure cannot be repaired by retrying only destination upload.

Starts verification of a completed recovery point.

Send level, either objects or restore, with default objects. Restore verification also requires an approved verification_profile_id defining isolated target resources and application checks. Returns 202 with verification ID and operation.

Unknown profiles, disallowed test regions, and insufficient test quota reject admission. A verification failure leaves the original recovery point unchanged.

Returns verification checks and temporary-resource cleanup state.

Requires backups:read and returns profile revision, checks, temporary IDs, duration, and cleanup state. A successful object check does not imply a successful application restore.

Cleanup failure can retain temporary volumes and continue consuming quota. Inspect their IDs before repeating the test. Cancellation follows the operation's current cancelable state and does not delete required source backup objects.

See backup verification and Operation API for result handling.