Skip to main content
Velero provides backup and restore capabilities for Kubernetes cluster resources and persistent volumes.

​
What Radar Shows

Backup Detail View:
  • Phase with color-coded badge, start/completion timestamps, duration
  • Progress bar during in-progress backups (items backed up percentage)
  • Scope filters: included/excluded namespaces and resources, label selectors
  • Storage location and volume snapshot locations
  • Options: TTL, snapshot volumes, default filesystem backup
  • Error/warning detection (AlertBanner for failed or partial backups with validation errors)
Restore Detail View:
  • Phase badge, source backup reference, duration
  • Progress bar during in-progress restores
  • Scope filters: included/excluded namespaces and resources
  • Restore options: PV restoration, existing resource policy
  • Error detection (AlertBanner for failed or partial restores)
Schedule Detail View:
  • Cron schedule (monospace), last backup timestamp
  • Pause state detection (AlertBanner when paused)
  • Validation failure detection (AlertBanner)
  • Backup template: storage location, TTL, namespace/resource filters, snapshot settings
BackupStorageLocation Detail View:
  • Phase (Available/Unavailable), last validation and sync times
  • Provider configuration: bucket, prefix, region, access mode
  • Provider-specific config key-value pairs
VolumeSnapshotLocation Detail View:
  • Provider name and configuration parameters
Resource Browser: Smart columns show phase badges, storage location, namespace counts, duration, expiry (with color-coded warnings), and error/warning counts. VolumeSnapshotLocation shows provider and config - deliberately no status column, since the VSL controller never populates status.phase.

​
Backup failures on the Problems surface

Velero reports every outcome through status.phase and has no status.conditions on any of its CRDs, so Radar reads phases directly rather than through the generic CRD-condition fallback. These become Issues (/api/issues, the Problems surface, MCP issues): They roll up under three categories, split by what you’d go and look at: backup_failed for runs that already have an outcome, backup_target_unavailable for the location/repository kinds, and backup_stalled for VeleroRunStalled. A run with no verdict is not a failed run - it has no error to read, only a controller to check - and calling it one puts “Backup failed” above a message saying it is still in progress. Supersession. Velero retains failed Backup objects until their TTL expires, so a raw phase-to-issue mapping would keep one bad night red for days. Backups group by the velero.io/schedule-name label; only the newest run that already has an outcome raises an issue (the two *PartiallyFailed phases count - the partial failure is a fact even though Velero is still finalizing), a later Completed clears the series, and an in-progress run neither clears nor raises. Ad-hoc (unlabelled) backups are their own series, so nothing supersedes them. Restores get no supersession - they are one-off operator actions, not a recurring series. A paused Schedule is not an issue. Pausing is operator intent; the Schedule list and detail view show the state without adding queue noise. Namespace attribution. Issues attribute to the Velero object’s own namespace (velero, or kommander on NKP). They are therefore admin-visible, but not visible to a user whose namespace view-filter excludes the Velero namespace - including one scoped only to the namespace whose data was lost. Surfacing a failure against the protected namespaces needs the protection-coverage model and is not part of this. What is not detected yet. Every detection above is driven by something Velero wrote - a phase, or in the stalled case a startTimestamp measured against the run’s own budget. Radar does not yet detect the absence of a run: a schedule that quietly stopped firing (controller down, wrong cron, schedule deleted) leaves its last run Completed, so no issue is raised even though backups have silently stopped. That needs the schedule cadence modelled against Velero’s real controller semantics (a due run is skipped while a prior backup is in flight), which is tracked separately. Treat “no Velero issues” as “nothing Velero recorded looks wrong”, not as “backups are healthy.”

​
Supported CRDs

Limitations:
  • A backup’s phase is not its restorability. A Completed backup can sit on an Unavailable storage location or be past its TTL. The BackupStorageLocation page shows stored and restorable counts. Unavailable means it cannot restore now; expired means Velero intends to delete it, so Radar excludes it even if garbage collection has not run yet.
  • Stalled-run detection depends on the phase. WaitingForPluginOperations is measured against Velero’s spec.itemOperationTimeout. For InProgress and Finalizing, that duration is only a yardstick because Velero defines no deadline. Radar reports the distinction and elapsed time without guessing at a cause. If the field is absent, Radar uses Velero’s built-in four-hour default; a controller-level override is not visible in the resource.
  • Fetching run messages needs a live controller and reachable storage. Radar creates a DownloadRequest and follows Velero’s pre-signed object-storage URL. A stopped controller or a URL unreachable from Radar returns an explicit error; configure the storage location’s publicUrl when needed. Data-mover objects (DataUpload/DataDownload) and full backup logs remain unavailable.