Kubernetes Changed Block Tracking: The Backup Efficiency Trap
Sources
Full volume snapshots are expensive and slow. To do incremental backups properly, you need to know exactly which blocks changed since the last snapshot. Historically, this was a proprietary feature of the storage vendor (AWS EBS, GCP PD, etc.). K8s is now bringing this into the core with the Changed Block Tracking (CBT) API (Beta).
The Technicals
The CBT API allows backup software to query the volume for a list of modified blocks. This turns a "snapshot everything" workflow into a "stream only changes" workflow, drastically reducing backup windows and storage costs for multi-terabyte volumes.
The Catch: The CSI Driver Gap
The API is just a contract. The actual heavy lifting is done by the CSI driver. If your storage vendor's driver has a buggy CBT implementation, you won't get a "failure" message—you'll get a successful backup that is internally corrupted because it missed a few changed blocks. This is the ultimate nightmare for a backup admin.
Additionally, the transition to Beta has introduced "Beta Differences" in the API. If you've been testing the Alpha version, your integration code will break. You'll need to update your clients to handle the refined resource definitions.
Verdict
A necessary evolution for stateful workloads at scale. However, do not trust it blindly. Implement a rigorous "restore and verify" pipeline. If you can't prove your incremental backups actually work, you don't have a backup strategy—you have a hope strategy.