canonical: https://jentic.com/apis/googleapis.com/backupdr

# Google Backup and DR Service API

The Backup and DR Service API manages Google Cloud's enterprise backup product for Compute Engine, VMware, databases, and file storage. It exposes operations to provision management servers, control data sources, initiate and finalise backups, and manage the long-running operations associated with each step. The API is the integration surface for orchestrating backups from external schedulers, ticketing systems, or compliance workflows. It manages backup orchestration, not the actual virtual machines, databases, or file systems being protected.

## For AI agents

Orchestrate Google Cloud Backup and DR data sources, initiate and finalise backups, and manage backup management servers from automation tooling.

## Scope

Does not run application workloads, manage VM lifecycle, or perform application-level recovery - use for orchestrating Backup and DR data sources and management servers only.

## Capabilities

- Initiate a backup on a data source via /v1/{+dataSource}:initiateBackup as a long-running operation
- Finalise an in-progress backup with /v1/{+dataSource}:finalizeBackup once data ingestion completes
- Abandon a partially started backup with /v1/{+dataSource}:abandonBackup to release resources
- Set the internal status on a data source via /v1/{+dataSource}:setInternalStatus during recovery flows
- List management servers and data sources within a project and location
- Manage long-running operations for backup creation, deletion, and management server changes

## Use cases

### Scheduled VM Backup Orchestration

Drive Compute Engine backups from an external scheduler by calling initiateBackup on each protected data source, polling the returned operation, and calling finalizeBackup when data ingestion completes. Suited to compliance regimes that demand auditable, code-driven backup execution rather than UI-only schedules.

Example prompt: POST initiateBackup on each data source in a target project, then poll until done and POST finalizeBackup.

### Failure Recovery for Stalled Backups

Detect stalled backup operations and call abandonBackup to release the underlying resources before retrying. The API exposes both the operation list and the abandon endpoint so an automation can identify and unblock stuck flows without operator intervention.

Example prompt: List operations on the data source, identify any older than the SLA threshold, and POST abandonBackup for those operations.

### Compliance Reporting on Protected Resources

Generate compliance reports by listing every data source under each management server in an organisation and correlating the results with last-successful-backup timestamps. The API's list endpoints return enough metadata to drive a compliance dashboard without hitting the underlying VM or database APIs.

Example prompt: List management servers in the project, then list data sources under each and aggregate last-backup timestamps into a CSV report.

### AI Agent Backup Triage via Jentic

Use an AI agent to triage backup failures by listing operations, summarising failure causes, and either retrying or marking incidents for human follow-up. Through Jentic the agent finds the relevant operations by intent and runs them with credentials supplied at call time, so a single agent can manage backups across many projects without per-project setup.

Example prompt: Use Jentic search for 'list backup operations in Backup and DR', filter for failed operations, and call abandonBackup for the ones older than 24 hours.

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| POST | /v1/{+dataSource}:initiateBackup | Start a backup operation on a data source |
| POST | /v1/{+dataSource}:finalizeBackup | Finalise a backup once data ingestion is complete |
| POST | /v1/{+dataSource}:abandonBackup | Abandon a partially started backup |
| POST | /v1/{+dataSource}:setInternalStatus | Update the internal status on a data source |
| GET | /v1/{+name} | Get a management server, data source, or vault by resource name |
| GET | /v1/{+name}/locations | List Backup and DR locations in a project |
| DELETE | /v1/{+name} | Delete a management server or data source |

## Key resources

- **managementServers** — Backup management server resources within a project and location
- **dataSources** — Resources representing protected workloads with backup lifecycle operations
- **backupVaults** — Storage containers for backup data managed by the service
- **operations** — Long-running operations covering backup, restore, and configuration changes

## Why Jentic

- **Setup:** Wiring the Backup and DR Service API by hand means setting up Google OAuth2, scoping a service account for backup access, and minting short-lived access tokens across its 30 operations yourself. Through Jentic you install once, import the Backup and DR Service API from the API Directory, store the OAuth credential once, and your agent calls it.
- **Permission scoping:** This API puts the data source name in the URL path (/v1/{dataSource}:initiateBackup, /v1/{name}), so a rule can pin your agent to one data source: it can initiate and finalize backups there and nothing else. You choose the operations it may call, so actions like abandoning a backup or deleting a resource are not included unless you add them.
- **Credential handling:** Your Google Cloud OAuth credential is stored once, encrypted, by your own Jentic One instance and injected at execution time. It never enters the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'start a backup of a Compute Engine VM' or 'finalize a backup', and Jentic returns the matching Backup and DR operation with its input schema so the agent calls the right endpoint without reading the full reference.

## Related APIs

- **Compute Engine API** — Manages the VMs that are protected by Backup and DR data sources
- **Cloud SQL Admin API** — Manages Cloud SQL databases that can be protected via Backup and DR
- **Backup for GKE API** — Kubernetes-specific backup product for GKE workloads

## FAQ

### What authentication does the Backup and DR Service API use?

The API uses Google OAuth 2.0 with cloud-platform scope, generally backed by a service account holding the roles/backupdr.* IAM role. Through Jentic the service account key is encrypted in the vault so agents only see scoped, short-lived access tokens.

### How do I initiate a backup through the API?

POST to /v1/{dataSource}:initiateBackup with the data source resource name. The call returns a long-running operation. Poll it until done and then call /v1/{dataSource}:finalizeBackup to mark the backup complete.

### What are the rate limits for the Backup and DR Service API?

Numeric request limits are not declared in the spec; per-project quotas on backupdr.googleapis.com apply. Check the project's quota dashboard before scheduling backups across many data sources at once.

### How do I clean up a backup that got stuck through Jentic?

Search Jentic for 'abandon a backup in Google Backup and DR'. Jentic returns the POST /v1/{dataSource}:abandonBackup operation; execute it with the data source name and Jentic supplies the credential from the vault.

### Does the API also restore data?

Restore flows are managed in the Backup and DR product surface; this OpenAPI spec exposes lifecycle controls for data sources and management servers but does not include a generic restore endpoint. Coordinate restores via the management server it provisions.

### Can I list management servers across regions?

Yes. GET /v1/{name}/locations returns the list of locations available, and the per-location managementServers list endpoint can then be called for each region of interest.

### Can I limit what my agent is allowed to do with the Backup and DR Service API?

Yes. Because your Jentic One instance is self-hosted, your own rules decide which operations and credentials the agent may use. This API carries the data source name in the URL path (for example /v1/{dataSource}:initiateBackup and /v1/{name}), so you can pin the agent to a single data source and allow only the calls you want, such as initiating and finalizing backups. Riskier operations like abandoning a backup or deleting a management server stay off limits unless you explicitly grant them.