Manage backup locations
Define external S3 targets for application backups. Backups sent to an external location survive even if the cluster itself is lost.
Where
Sidebar → Organizations → your org → Backup Locations
tab. The tab is visible when your role has any of
backup-locations:create / update / delete.
Rows carry two badges:
- Default — backups created without an explicit location go here instead of in-cluster storage
- Global — defined by the platform admin for every org. You can Test a global location against your own edges, but not edit or delete it.
Add a location
Add Location opens a drawer:
- Name — displayed in the Backup Location dropdown
(e.g.
Central MinIO) - S3 Endpoint — leave empty for native AWS S3; otherwise the
URL, e.g.
https://s3.example.com(MinIO, RGW) - Bucket — required
- Region — e.g.
us-east-1 - Access Key / Secret Key — the secret key is write-only; when editing, leave it empty to keep the current one
- CA Certificate (PEM) — required when the endpoint uses a certificate signed by a private CA. Like the secret key, the stored value isn't echoed back — empty means "keep"
- Skip TLS verification — not recommended; prefer providing the CA certificate above
- Use as default backup target — backups without an explicit location will go here instead of in-cluster storage
Test a location
Row actions → Test → pick an edge instance → Test.
The location is validated by the selected edge's backup agent (Velero), so what you're really testing is "can that cluster reach this bucket with these credentials". Validation can take up to 90 seconds; the verdict comes back as a badge:
- Available (green) — the edge can write to the location
- Unavailable (red) — plus a message; check endpoint, credentials and CA certificate
Testing works on global locations too — useful to confirm a platform-provided target is reachable from your edges before pointing schedules at it.
Edit or delete
Row actions → Edit / Delete (own locations only; global rows are read-only).
Deleting a location is safe for history: existing backups remain restorable; new backups just can no longer target it.
Using locations in backups
Once at least one location exists, the backup and schedule dialogs (Applications → release detail → Backups tab) grow a Backup Location dropdown. See How-to: run a Velero backup.
Common errors
BACKUP_LOCATION_UNAVAILABLE— the location is unreachable; check endpoint, credentials and CA certificateBACKUP_LOCATION_NOT_VALIDATED— the test didn't produce a verdict in time; check that Velero is healthy on the edgeBACKUP_LOCATION_NOT_FOUND— the location was deleted (or belongs to another org); pick a different one
See also
- How-to: run a Velero backup
- Reference: Backups page
- Reference: permissions —
the
backup-locationsresource