Backup destinations and object storage
Configure independent object copies, provider access, encryption, and retained dependencies.
Backup destinations define where independent recovery copies are stored and how backup workers authenticate to that storage. They are separate from live storage pools and from the policy selecting source volumes.
Configure an object destination
Open Storage → Backup destinations → Add destination and choose the supported S3-compatible mode or managed archive. For object storage, set the HTTPS endpoint, bucket, key prefix, provider region, addressing style, and credential reference. The bucket must already exist.
For a destination being created for the first time, create its secret with an empty consumer list. Register the destination with that secret reference, then authorize the destination ID as a consumer. Run the capability test only after authorization succeeds; a stored secret reference alone does not grant the backup worker permission to resolve it.
A prefix isolates managed backup objects. It is not an operating system directory; changing it does not move older objects. Use a dedicated prefix whose objects are not edited by unrelated lifecycle automation.
Virtual-host addressing places the bucket in the hostname. Path addressing uses the endpoint path. Select the mode supported by the provider and its certificate. A custom endpoint can require an explicitly configured CA bundle.
Validate capabilities
The connection test writes, reads, and removes a temporary object in the intended prefix. It checks the required manifest and multipart-transfer capabilities. Passing an endpoint-only TLS check is insufficient.
The test cannot prove all future deletion behavior. A destination retention lock can permit writes while rejecting deletion until its required date. Infra reports that capability separately so backup retention does not assume immediate cleanup.
Credentials need only the object operations required for the configured prefix. Do not give guest bootstrap code direct access to the destination credential. Backup workers receive the authorized consumer reference through secret revision activation.
Transfer interruptions
A run records its captured source, uploaded parts, and final manifest. An interrupted transfer can reuse parts when the provider and retained attempt support it. A usable recovery point is published only after required data and verification complete.
Abandoned multipart data can occupy provider capacity even when no completed recovery point exists. Cleanup uses the transfer's recorded ownership and must not abort unrelated uploads in a shared bucket.
Rotate or change configuration
To rotate credentials without moving stored backups, apply the new reference with Update credentials, then run the destination's capability test. Confirm the observed credential revision and test result. Let transfers using the old credential finish before revoking it at the provider.
Changing the endpoint or managed prefix requires a new destination. Create and test that destination before assigning it to future backup runs. Keep the old destination available while retained recovery points reference its objects; changing configuration does not copy those objects to the new location.
Retire a destination
Disable new policy selection, resolve active transfers, and review retained recovery points, legal holds, and pending cleanup. Removal is blocked while required references remain. Deleting the configuration cannot release a provider-enforced retention lock.
Use Backup destination API, retention and holds, and restore verification before archive decommissioning.