For the complete documentation index, see llms.txt.
Skip to main content
Version: 8.10

Takes a backup of runtime data

POST 
/backupRuntime

With continuous backups enabled the backupId parameter must be omitted, as it's generated by the cluster based on the current time and any offset configured. Otherwise, the backupId parameter is required to specify the id of the backup to be taken.

Without physicalTenant a backup is triggered for every physical tenant of the cluster. The caller-supplied backupId is used for every tenant; when ids are generated, each tenant gets its own and backupIds maps every tenant to the id it was given.

The physicalTenant query parameter is only read when the request carries a Content-Type: application/json header (the body itself may be empty). A request without that header always covers every physical tenant.

If some tenants' backups are triggered and others fail, the status code is the failure's but the body is still a TakeBackupRuntimeResponse: backupIds lists the backups that were triggered so they can be monitored or deleted, and failureReason says what went wrong. It also repeats the failure in message, so a client that reads error bodies as Error still surfaces it.

Request​

Responses​

A backup has been successfully scheduled