Skip to main content

Run a Velero backup

Take a point-in-time backup of an application (its namespace, resources, and volume data) on an edge cluster — and restore from it.

Prerequisites​

  • Velero installed on the target edge — the standard edge preset includes it
  • Somewhere for the data to go: the cluster's own BackupStorageLocation, and/or an external backup location defined for your org
  • Permission to update edge instances in your role

Take an ad-hoc backup​

Sidebar → Applications → click the release → Backups tab → Take Backup.

The dialog has two fields:

  • Retention (TTL) — how long Velero keeps the backup before auto-deleting. Default 720h (30 days); any Go-style duration works (24h, 30m)
  • Backup Location — only shown when your org has at least one backup location defined. The default option is your org's default location if one is marked, otherwise In-cluster storage (default). External locations survive the loss of the cluster — pick one for backups you'd want after a cluster disaster.

Everything else is automatic: the backup is scoped to the release (its namespace + its resources, volume data included when the cluster has CSI snapshot support), and the name is generated as <release>-backup-<timestamp>.

Submit. The new row appears with status New → InProgress → Completed. Manifest-only apps complete in seconds; volume-carrying apps (databases, VMs) take as long as the data transfer needs. While it runs, the tab's action buttons are disabled — one Velero operation per release at a time.

Schedule recurring backups​

Same Backups tab → Backup Schedules → Create Schedule.

  • Cron Expression — standard 5-field cron (e.g. 0 2 * * * for 2am daily)
  • Retention (TTL) — every run inherits this; older runs auto-delete when it expires
  • Backup Location — same dropdown as the ad-hoc dialog, when external locations exist

Velero owns the cron on the edge; each scheduled run shows up as a row in the backups list. To stop a schedule, delete it from the drawer — backups it already produced stay until their own TTL.

Restore from a backup​

Backups list → Restore on a Completed backup → confirm.

Restore always targets the release's own namespace and brings the app back to the state captured in the backup — resources and volume data alike. It runs as an async operation; watch it in the list or the Operations Center.

Where backups land​

Two possibilities, depending on what you picked in the Backup Location dropdown (or its default when you left it alone):

  • In-cluster storage — Velero writes to the BackupStorageLocation the cluster was provisioned with. DT Edge Platform doesn't manage the bucket itself — it just reads and creates Backup / Restore CRs.
  • An external backup location — an S3 target your org (or the platform admin) defined under Organizations → Backup Locations. These survive even if the cluster itself is lost. See How-to: manage backup locations.

Before pointing important schedules at an external location, use its Test action (Organizations → Backup Locations → row → Test) to confirm the target edge's backup agent can reach it — the verdict comes back as Available / Unavailable and can take up to 90 seconds.

Common errors​

  • Invalid TTL / cron format — TTL must be a duration like 720h; cron must be 5 fields
  • OPERATION_IN_PROGRESS — another operation (install, upgrade, another backup…) is running on this release; wait for it to finish
  • BackupStorageLocation not Available — Velero can't reach the storage backend. Check the BSL's status on the cluster: kubectl -n velero get backupstoragelocation
  • BACKUP_LOCATION_UNAVAILABLE — the external backup location you selected is unreachable from this edge; check endpoint, credentials and CA certificate, or run its Test action
  • BACKUP_LOCATION_NOT_FOUND — the location was deleted after you opened the dialog; pick another one. Backups already stored in a deleted location remain restorable.
  • PartiallyFailed — most resources got captured but at least one item errored; check Velero's logs on the edge

See also​