Kubernetes moves CSI Changed Block Tracking to beta and drops v1alpha1
Changed Block Tracking for Kubernetes CSI drivers, in alpha since September 2025, moved to beta with the external-snapshot-metadata v1.0.0 release and removed the v1alpha1 API with no automatic conversion. Backup vendors and CSI driver maintainers must re-apply the CRD and migrate their manifests to v1beta1.
September 2025. Changed Block Tracking (CBT) for Kubernetes CSI drivers ships as alpha. March 2026. The v1.0.0 release of the external-snapshot-metadata project promotes it to beta. September 14, 2026. The official blog post by Prasad Ghangal, a maintainer at Veeam Kasten, finally spells out what changed — and it’s an unusual move for the ecosystem: the v1alpha1 API is removed, not kept alongside the new one. Why it matters: incremental volume backups no longer depend on full-disk scans, but anyone who adopted the alpha must migrate with no conversion safety net.
CBT solves a problem every cluster operator knows: backing up a volume is slow and expensive once the volume is large. A full scan re-reads every block, including the ones that haven’t moved since yesterday. Changed block tracking flips the logic: the storage layer itself reports which blocks changed since a snapshot, and the backup only transfers those.
What Changed Block Tracking does
The feature rests on three components, described at the alpha announcement back in September 2025. First, the SnapshotMetadata gRPC service exposed by the CSI driver. Second, the SnapshotMetadataService custom resource (CRD) that advertises a driver as speaking this protocol. Third, the external-snapshot-metadata sidecar running in the controller pod, bridging the Kubernetes API to the driver.
Two calls capture the whole model. GetMetadataAllocated returns the list of blocks allocated to a volume. GetMetadataDelta returns the difference between two snapshots — precisely the blocks added, changed, or removed. That second call is what makes an incremental backup possible without reading the whole disk.
One limit, stated from the start and still true in beta: CBT only covers block volumes. File volumes and network file shares fall outside its scope. For databases, filesystems, and stateful workloads on EBS, Ceph RBD, or LVM, though, it is the missing piece.
What changed in beta
The core change is the promotion of the SnapshotMetadataService CRD from v1alpha1 to v1beta1. The metadata service, previously served under cbt.storage.k8s.io/v1alpha1, now answers at cbt.storage.k8s.io/v1beta1.
Two points deserve attention. The schema is unchanged: fields, structure, and semantics do not move between versions. But v1alpha1 is not served in parallel with the new version, as is the usual Kubernetes pattern. It is removed, and there is no automatic conversion between the two.
This is a deliberate maintainer choice. Serving two versions of a storage-metadata API means doubling the test surface in a domain where a bug costs you corrupted backups. By deleting the old version instead of maintaining it, the team forces a clean, final migration — at the price of a hard cut for early adopters.
A three-step migration
To move from alpha to beta, the official post lists three mandatory actions:
- Re-apply the CRD definition shipped with the
v1.0.0release of external-snapshot-metadata, which installs thev1beta1schema. - Update SnapshotMetadataService manifests to use
apiVersion: cbt.storage.k8s.io/v1beta1. - Update the code of any client or controller that talks to the CRD.
It is a one-time migration, not ongoing upkeep. The absence of conversion means there is no transparent upgrade path: an operator who delays the migration stays on a schema nothing serves anymore, and their backup tooling stops working.
Compatibility
The prerequisites are precise and light for an up-to-date cluster. The minimum Kubernetes version is 1.33. The CSI driver must implement spec 1.10 or newer. The sidecar image is registry.k8s.io/sig-storage/csi-snapshot-metadata:v1.0.0.
Deploying comes down to three steps: confirm the driver supports volume snapshots and ships the sidecar, install the v1beta1 CRD, then create a SnapshotMetadataService resource for the driver. A client — the snapshot-metadata-lister example in the repo, or your own implementation — then calls GetMetadataAllocated and GetMetadataDelta. The hostpath driver serves as an end-to-end testbed.
Why it took so long
CBT arrives late in Kubernetes history, which stabilized volume snapshots back in 2019 with the VolumeSnapshot CRD. The reason is structural: detecting changed blocks requires the CSI driver to expose a primitive few arrays provide in a standard way. Every vendor had their own mechanism — an in-VM agent, a snapshot hook, a proprietary API — and incremental backup rested on fragile homegrown integrations.
The SnapshotMetadata spec changes the game by standardizing the contract. The driver declares once what it can do, and the backup tool no longer needs to know the underlying array. It is the same movement that turned snapshots themselves from ad hoc scripts into a stable API: the building block exists, and products build on it instead of reinventing it.
The typical incremental backup flow reads like this: the tool creates a VolumeSnapshot, queries GetMetadataDelta between the previous snapshot and the new one, gets the list of changed blocks, then reads only those blocks from the snapshot. On a multi-terabyte volume where 2% changed, you read gigabytes instead of the whole thing — a gain that makes one-hour RPOs realistic without saturating the storage network.
The trade-off is maturation time. Between the alpha of September 2025 and the beta of March 2026, the schema had to stabilize, reference clients had to be written, and the first drivers had to be convinced to ship the sidecar. The choice to delete v1alpha1 rather than serve it in parallel accelerates that maturation: it avoids fragmenting an ecosystem that would otherwise split across two versions for years, and it mirrors how VMware CBT once standardized incremental backup before the whole industry adopted it.
Why backup teams should care
CBT changes the economics of backing up stateful workloads. Without it, an incremental backup must either re-read the entire volume to detect changes or lean on fragile external mechanisms. With it, the recovery point objective (RPO) tightens without exploding transfer cost or storage load.
The presence of Prasad Ghangal in the credits is not incidental: Veeam Kasten, a Kubernetes backup vendor, actively drives the feature within SIG Storage. It is the classic pattern for good platform APIs: the vendor that needs a primitive specifies it, funds it, and pushes it upstream, then the whole ecosystem benefits. The parallel with VMware CBT, which became the de facto standard for incremental VM backup, is explicit.
The roadmap for the rest of beta is clear: wider CSI driver adoption and operational feedback before GA. Driver maintainers are explicitly invited to evaluate adding support now, and backup tool vendors to test the streaming clients and the iterator package. A working reference client is what turns a spec into a product, and the example code is the fastest way for a vendor to validate the API against their own storage.
Verdict
If you maintain a CSI driver, now is the time to evaluate implementing the SnapshotMetadata service: the spec is stable, the scope is bounded to block mode, and adopting early positions you well before GA. If you build backup or disaster-recovery tooling on Kubernetes, integrate GetMetadataDelta instead of a full scan — it is the difference between an RPO of minutes and one gated by full-volume read time. If you adopted the alpha, do not wait: re-apply the v1beta1 CRD, migrate your manifests and your code, because v1alpha1 is already gone and there is no conversion path.