Tier 0: Kubernetes Volume Snapshot support for low-impact base backups

[gbartolini]

Introduce Tier 0 as an additional, non-durable backup source, built on CloudNativePG's own robust, well-tested support for Kubernetes VolumeSnapshots: point-in-time snapshots of a PostgreSQL cluster's PGDATA and tablespace volumes, taken when the underlying StorageClass supports it. Klio asynchronously offloads this data into Tier 1, and from there Tier 2, for durable, long-term storage, removing the long-standing barrier to trusting local-storage snapshots as a backup source, and enabling faster recovery on local storage such as LVM.

Motivation

Producing a base backup traditionally means reading the live database, which competes with the running workload for I/O and CPU. CloudNativePG already provides mature, well-tested orchestration of Kubernetes VolumeSnapshots for a cluster's volumes; Klio builds on that capability rather than re-implementing snapshot orchestration itself, and treats the resulting static, isolated copy as the source for the backup, with zero ongoing impact on the primary.

Volume snapshots on local storage have historically had a hard limit as a backup strategy: the snapshot lives on the same disk, or the same host, as the data it protects, so on its own it offers no durability against disk or node loss (someone still has to get that data onto another disk). That manual step has long been a barrier to adopting local-storage snapshots, for example on LVM-backed StorageClasses, as a real backup mechanism. Klio removes that barrier by automating the offload of a Tier 0 snapshot into Tier 1, and from there into Tier 2, giving local-storage snapshots the same durability guarantees as any other backup source without anyone having to wire that offload up by hand.

A retained local snapshot is also faster to recover from than a Tier 1 restore, since it avoids pulling a base backup across the network (this matters in particular for local, non-networked storage such as LVM). CloudNativePG already supports bootstrapping a cluster from a volume snapshot; this epic's role is to make sure a valid, correctly-retained Tier 0 snapshot exists for that bootstrap path to use, not to implement a restore mechanism of its own (at least initially). This speed advantage applies where the local cluster and its storage are still intact. It does not substitute for Tier 1/Tier 2 in a genuine disaster-recovery scenario where local storage is lost.

Scope

• Configuration: a way to enable and configure Tier 0 per cluster, consistent with how Tier 1 and Tier 2 are already configured.
• Integration with CloudNativePG's VolumeSnapshot orchestration: Klio consumes a CloudNativePG-coordinated, consistent, point-in-time snapshot of the cluster's full volume set (PGDATA plus all tablespaces). Hot and cold method supported.
• Asynchronous offload: transfer of the data captured in the VolumeSnapshot into Tier 1 (and, from there, eligible for Tier 2), decoupled from the snapshot-creation step, without impacting the running primary.
• Retention for Tier 0: manage the lifecycle of the VolumeSnapshot objects themselves, independent of Tier 1/Tier 2 retention, and consistent with their use as a source for CloudNativePG's bootstrap-from-snapshot recovery.

Success criteria

• A base backup can be produced via a VolumeSnapshot
• The resulting backup in Tier 1 is a correct, consistent base backup — including all tablespaces — indistinguishable in restore behaviour from a directly-streamed Tier 1 backup.
• A Tier 0 snapshot is never left as the sole copy of a backup for longer than necessary: it is either promptly offloaded to Tier 1, or clearly surfaced as ephemeral/at-risk if the offload hasn't completed.
• A retained Tier 0 snapshot remains valid and usable by CloudNativePG's own bootstrap-from-snapshot recovery path for as long as its configured retention window specifies.
• Tier 0 VolumeSnapshot objects are correctly retained/pruned per configured policy, and pruning never removes a snapshot an in-flight offload depends on.
• The feature only works where the underlying StorageClass genuinely supports VolumeSnapshot; a cluster on a non-supporting StorageClass is unaffected.

Dependencies

Relies on CloudNativePG's existing VolumeSnapshot orchestration as the source of truth for snapshot creation and cross-volume consistency, and on CloudNativePG's existing bootstrap-from-snapshot recovery mechanism for actually restoring from a Tier 0 snapshot. Klio does not reimplement either. Relies on Tier 1, and transitively Tier 2, as the durable destination for offloaded data.

Open questions

• What is Klio's integration point with a CloudNativePG-orchestrated VolumeSnapshot backup: how does Klio get notified of, or participate in, a completed snapshot in order to start the offload to Tier 1? Shall we just detect new volume snapshots for a managed cluster?
• How long should a Tier 0 snapshot be retained: only long enough to complete the offload, or longer, to remain usable by CloudNativePG's bootstrap-from-snapshot path? Is that one retention policy or two, or three?
• What retention enforcement mechanism applies to Tier 0, given VolumeSnapshot objects are Kubernetes resources rather than the kind of storage Tier 1/Tier 2 retention already manages?
• What happens if the offload to Tier 1 fails or stalls indefinitely — is the Tier 0 snapshot retained past its normal lifecycle until the offload succeeds, or is that treated as a backup failure?

Out of scope

• Recovery from a Tier 0 volume snapshot: this happens through CloudNativePG's own bootstrap-configuration recovery path (restoring/provisioning a cluster from an existing snapshot), which this epic does not implement or wrap. At least in an initial phase.
• Archiving the snapshot itself to object storage as a distinct durability mechanism outside Klio's own tiering: some cloud providers/storage classes support this natively, but Tier 0 in Klio is a staging step feeding Tier 1/Tier 2, not an alternative durable tier of its own.