Discovery & policy: BackupPolicy for label-selected, auto-materialized backups

Summary

Add policy-driven discovery: a BackupPolicy that selects databases by label and automatically materializes/owns Backup objects, so new databases get covered with no new manifest. This is the "unified backup platform" capability a CLI fundamentally cannot provide, and the question this project exists to answer: "which databases have no backup?"

Highest ceiling, highest scope risk — sequence after ergonomics / restore / observability. It's a generator on top of Backup, not a parallel engine.

Proposed design

BackupPolicy CRD (selector over Database resources)

apiVersion: gobackup.io/v1
kind: BackupPolicy
spec:
  selector:
    matchLabels: { tier: critical }
  # namespaceSelector: { matchLabels: { backups: enabled } }   # later, cluster-scoped
  template:                     # applied to every matched Database
    schedule: { cron: "0 2 * * *" }
    storages: [{ ref: { name: offsite-s3 }, keep: 30 }]
    compressWith: { type: gzip }
    verify: { mode: integrity }
status:
  matchedDatabases: 7
  managedBackups: 7

Controller: watch Database + BackupPolicy; for each matched Database, create/update an owned Backup (owner-ref → policy, deterministic name <policy>-<database>); reconcile on Database add/delete/label-change; prune Backups whose Database no longer matches. Reuses everything from the ergonomics/restore/observability issues.

Coverage reporting (the payoff)

• status.matchedDatabases / status.managedBackups.
• Metric gobackup_policy_unmanaged_databases{namespace} (in-scope but failing/expired).
• Optional gobackup_databases_without_policy — databases no policy selects at all.

Native-workload discovery (future, gated, separate track)

Discover databases that aren't Database CRs — workloads managed by other operators (CloudNativePG Cluster, Zalando postgresql, Percona, MongoDB Community, Bitnami charts) — via well-known labels/owner-kinds, synthesizing a Database (host = the cluster Service, creds = the operator's generated Secret). Big, fragile surface; opt-in adapter layer, one integration at a time, behind feature flags. Must not block the core policy work.

Phases

1. BackupPolicy selecting Database CRs in its own namespace → owned Backups; prune on unmatch; status counts.
2. Coverage metrics + kubectl get backuppolicy printer columns.
3. namespaceSelector / cluster scope (broadens RBAC — coordinate with the ClusterRole-scope concern in CONCERNS.md).
4. (Separate track) one native-workload adapter, e.g. CloudNativePG, as PoC.

Risks

• Ownership/drift: define policy-owned Backups as fully managed (reconciled back), or support an "adopt, don't overwrite" mode. Document it.
• Blast radius: a bad selector could spawn/delete many Backups. Mitigate with a paused field, status dry-run preview, and a max-matched safety cap requiring explicit override.
• RBAC expansion: cross-namespace discovery needs broader read access — at odds with the "scope secrets down" recommendation. Cluster scope strictly opt-in.
• Native discovery is a maintenance treadmill: each adapter tracks a moving upstream; add only on real demand, version independently.

Success criteria

• Labeling a new Database tier=critical starts backing it up with no new manifest.
• kubectl get backuppolicy shows matched vs. managed counts.
• A single query/alert surfaces every in-scope database lacking a recent successful backup.
• Cluster-scoped discovery is opt-in and documented as a privilege escalation.

Start by reading the existing Database and Backup resources and their controllers, then map how a BackupPolicy controller would reconcile label matches and ownership. Define the first phase around same-namespace selection, owned Backup creation, pruning, and status counts; leave namespaceSelector and native-workload adapters separate. Done means labeling a Database creates its Backup without a new manifest and matched versus managed counts are visible.