Backup Overview

Central read-only view of Velero and CloudNativePG backups and schedules across connected clusters in the Polycrate API: architecture, dashboard, statuses, overdue detection and best practices.

Backup Overview

Overview

The Polycrate API provides a central read-only view of Velero and CloudNativePG backups and schedules in connected clusters.

Architecture

Backup monitoring is integrated into the Polycrate Operator. The operator detects Velero installations in the cluster and automatically synchronizes backup status with the Polycrate API.

graph TB
    subgraph cluster1[Kubernetes Cluster 1]
        VELERO1[Velero]
        OP1[Polycrate Operator]
        BACKUP_CRD1[Backup CRs]

        VELERO1 --> BACKUP_CRD1
        OP1 -->|Reads| BACKUP_CRD1
    end

    subgraph cluster2[Kubernetes Cluster 2]
        VELERO2[Velero]
        OP2[Polycrate Operator]
        BACKUP_CRD2[Backup CRs]

        VELERO2 --> BACKUP_CRD2
        OP2 -->|Reads| BACKUP_CRD2
    end

    subgraph api[Polycrate API]
        OVERVIEW[Aggregated overview]
        DASHBOARD[Status dashboard]
        ALERTS[Alerts on problems]
        HISTORY[History & trends]
    end

    OP1 -->|Push status| api
    OP2 -->|Push status| api

Operator-based backup monitoring (default)

In Kubernetes clusters with the Polycrate Operator installed, backups are detected automatically and transmitted to the API:

  1. Velero detection: The operator checks for a Velero installation during cluster reconciliation
  2. CRD reading: Reads Backup, Schedule and BackupStorageLocation CRs
  3. Status push: Synchronizes backup status to the Polycrate API
  4. S3 linking: Links backups to S3 buckets from the BackupStorageLocation

Advantages of the operator-based approach:

  • ✅ Automatic Velero detection
  • ✅ Real-time updates on backup status changes
  • ✅ No manual configuration required
  • ✅ Works even during temporary API outages

Fallback: API pull (without operator)

For workspaces without a connected Polycrate Operator, the API can pull backup status directly from the cluster:

graph LR
    subgraph cluster[Cluster without operator]
        VELERO[Velero]
        BACKUP_CRD[Backup CRs]
    end

    API[Polycrate API]

    API -->|Pull status| BACKUP_CRD

What you can see

Backup dashboard

Under Kubernetes → Backups you will find:

Information Description
All backups Overview of all Velero backups across all clusters
Status completed, running, failed, partial
Cluster assignment Which backup belongs to which cluster
Timestamps When the backup was started/finished
Expiry When the backup expires (retention)

Backup status

Status Meaning
pending Backup scheduled but not yet started
running Backup currently running
completed Backup completed successfully
partial Backup completed with warnings
failed Backup failed
expired Backup expired

Backup details

Visible for every backup:

  • Creation time: When was the backup taken?
  • Expiration time: When will the backup be deleted?
  • Retention policy: TTL configuration (e.g. "96h")
  • Provider: Backup tool (Velero, CloudnativePG, etc.)
  • S3 bucket: Where is the backup stored?
  • Velero statistics: Volume snapshots, warnings, errors
  • Provider metadata (CLI ≥ 0.53.0 / current operator): BSL bucket, item count/size (Velero), retention (CNPG)

Backup types

Type Description
cluster Full cluster backup (all namespaces)
app Application-specific backup
database Database-specific backup (e.g. CloudnativePG)

Backup Schedules

The operator also detects Velero Schedules and shows them in the cluster detail view. Polycrate monitors every schedule and indicates whether the last backup is overdue.

Overdue status

A backup schedule is considered overdue (overdue) when more time has passed since the last successful backup than the configured interval. Polycrate checks this status every 5 minutes based on the actual last backup (last_backup_at).

Overdue schedules are highlighted in the Operations Dashboard under "Overdue Backup Schedules" and trigger a notification – so missed backups become visible immediately without having to search manually.

# Example: detected schedule
name: daily-backup
schedule: "0 2 * * *"
template:
  includedNamespaces: ["*"]
  snapshotVolumes: true
status:
  phase: Enabled
  lastBackup: "2025-01-27T02:00:00Z"

Cross-cluster overview

The Polycrate API shows backups of all connected clusters in a single view:

Cluster Last backup Status Next scheduled
prod-eu 2 hours ago ✅ completed in 22 hours
prod-us 3 hours ago ✅ completed in 21 hours
staging 1 day ago ⚠️ partial in 23 hours

Advantages of the central overview

  • Fast problem detection: Failed backups are visible immediately
  • No cluster hopping: All backup statuses in one place
  • Trend analysis: Detect recurring problems
  • Compliance evidence: Documentation of backup execution

Metrics & trends

The dashboard shows aggregated information:

  • Backup success rate: % successful backups (last 7/30 days)
  • Error trend: Are backup errors increasing or decreasing?
  • Average backup size: Per cluster/namespace
  • Last successful backups: Per critical namespace

Velero configuration (in the cluster)

Triggering a backup

# In the Kubernetes cluster
velero backup create manual-backup-$(date +%Y%m%d) \
  --include-namespaces production

Running a restore

# In the Kubernetes cluster
velero restore create --from-backup daily-backup-20250115

Configuring a schedule

# In the Kubernetes cluster
velero schedule create daily-backup \
  --schedule="0 2 * * *" \
  --include-namespaces production \
  --ttl 168h

Best Practices

Monitoring recommendations

  1. Install the Polycrate Operator: For automatic backup monitoring
  2. Check alert configuration: Make sure backup alerts are enabled
  3. Regular dashboard checks: Daily look at backup status
  4. Watch trends: Pay attention to declining success rates

In case of backup failures

  1. In the Polycrate API: Check alert details and error message
  2. In the cluster: Analyze Velero logs
    kubectl logs -n velero deployment/velero
    
  3. Check storage: Is the backup storage reachable?
  4. Manual retry: Restart the backup manually

Monitor important namespaces

Make sure critical namespaces are backed up regularly:

  • Production workloads
  • Databases and stateful services
  • Configurations and secrets

Supported backup providers

Provider Status Description
Velero Supported Cluster and application backups (Backup, Schedule)
CloudNativePG Supported PostgreSQL (Backup, ScheduledBackup) — operator from CLI 0.49.0

See also