Skip to main content

Backups tab

Velero backups for a single application — ad-hoc backups, recurring schedules, and restore. Everything is scoped to the release you're looking at.

There is no top-level "Backups" sidebar entry and no edge-level backups surface. Backups hang off an application: Applications → click a release → Backups tab. Every backup and schedule you see there belongs to that release (its namespace

  • its resources); other releases' backups don't appear.

If Velero isn't installed on the edge, the tab shows an empty list — install Velero first (the standard edge preset includes it).

The backups list​

ColumnMeaning
NameBackup name on the cluster (auto-generated: <release>-backup-<timestamp>)
StatusNew / InProgress / Completed / Failed / PartiallyFailed
StartedWhen Velero started the backup
ItemsResource count Velero captured
ActionsRestore (enabled only on Completed rows) / delete

Statuses use semantic colours — Completed green, InProgress yellow (with a spinner), Failed red, PartiallyFailed orange. The list refreshes every 30 seconds while the tab is open.

While a backup or restore is running, the Take Backup and Backup Schedules buttons are disabled, and so is Restore on every row — one Velero operation per release at a time. The backend enforces the same rule (OPERATION_IN_PROGRESS).

Take Backup dialog​

Take Backup (top-right of the tab) opens a small dialog:

  • Retention (TTL) — how long to keep the backup. Default 720h (30 days). Format: a Go-style duration such as 720h, 24h, 30m
  • Backup Location — only rendered when the org has at least one backup location defined (Organizations → Backup Locations). Options: the default option (the org's default location by name when one is marked, otherwise In-cluster storage (default)) plus every defined location. External locations survive the loss of the cluster.

That's the whole form — the backup's name and scope are derived automatically from the release (its namespace + its resources). Submit queues an async operation; the row appears in the list and progresses on its own. Progress also shows in the Operations Center.

Backup Schedules drawer​

Backup Schedules (next to Take Backup; carries a count badge when schedules exist) opens a side drawer listing the release's schedules:

ColumnMeaning
NameSchedule name (auto-generated: <release>-schedule-<timestamp>)
Cron ExpressionStandard 5-field cron
Last BackupMost recent scheduled run
ActionsDelete

Create Schedule opens an inline form inside the drawer:

  • Cron Expression — e.g. 0 2 * * * for 2am daily. The form refuses anything that isn't a 5-field cron
  • Retention (TTL) — applied to every run
  • Backup Location — same dropdown as the ad-hoc dialog, when external locations exist

Velero owns the cron; every scheduled run appears as a row in the backups list. Deleting a schedule doesn't delete the backups it already produced — those live until their own TTL expires.

Restore​

Restore on a Completed backup opens a confirmation dialog — restore always targets the release's own namespace, there are no extra options to fill. Confirm queues an async operation; the app returns to the state captured in the backup.

Deleting a backup is also a confirm dialog; Velero then removes the backup from both the cluster and the storage.

Where backups land​

Depends on the Backup Location you picked (or the default when you didn't):

  • In-cluster storage — Velero writes to the BackupStorageLocation the cluster was provisioned with. DT Edge Platform doesn't manage that storage — it reads Backup / Restore CRs and shows their state.
  • An external backup location — an S3 target defined under Organizations → Backup Locations (by your org, or globally by the platform admin). Backups sent there survive even if the cluster is lost. Locations marked Default capture backups created without an explicit choice. See How-to: manage backup locations.

Each location has a Test action (pick an edge; validated by that edge's backup agent, up to ~90 seconds) with an Available / Unavailable verdict. Deleting a location keeps existing backups restorable; new backups can no longer target it.

To verify a BackupStorageLocation from a terminal:

kubectl -n velero get backupstoragelocation

It must show Available for new backups to succeed.

Common errors​

  • Invalid TTL format — use a duration like 720h, 24h or 30m
  • Invalid cron expression — must be 5 fields (e.g. 0 2 * * *)
  • OPERATION_IN_PROGRESS — another operation is already running on this release; wait for it to finish
  • BACKUP_LOCATION_UNAVAILABLE — the selected external location is unreachable; check endpoint, credentials and CA certificate (or run the location's Test action)
  • BACKUP_LOCATION_NOT_VALIDATED — the location couldn't be validated in time; check that Velero is healthy on the edge
  • PartiallyFailed — most resources got captured but at least one item errored; check the Velero logs on the edge

See also​