For years, organizations running stateful workloads on Kubernetes have been creating backups that appear successful but can fail catastrophically at restore time, according to a technical analysis published by The New Stack. The core problem: when applications spread their state across multiple storage volumes—a database with separate data and log disks, for example—individual snapshots of each volume capture different points in time, creating restore points that never actually existed. As of Kubernetes version 1.36, released in May 2026, a new feature called VolumeGroupSnapshot finally addresses this gap by bringing consistency groups back as a standard API.
The issue stems from how the Container Storage Interface standardized snapshots around a single object scoped to one PersistentVolumeClaim at a time. When backup tools protect multi-volume applications, they enumerate the volumes and issue snapshots sequentially—snapshot volume A, then B, then C—with each individually crash-consistent but not synchronized with one another. Between snapshotting the first and second volume, the application continues writing. A transaction can land in a log on volume B that references data never captured on volume A because that first volume was frozen hundreds of milliseconds earlier. The busier the application and the more volumes involved, the wider the inconsistency window grows. Enterprise storage arrays solved this decades ago with consistency groups that froze all related volumes at the same instant, but that guarantee disappeared when teams migrated to Kubernetes-native storage.
The report describes the new VolumeGroupSnapshot primitive as producing "a set of snapshots that each looks healthy and collectively describes a state that never existed" under the old approach, while the new API delivers "one atomic, point-in-time snapshot across every selected volume" with no application quiescence required. According to the analysis, the feature uses a label selector—such as `app=postgres`—to pick up data and log volumes together, expressing the group boundary in Kubernetes terms that survive adding or resizing volumes over time. The author, who implemented VolumeGroupSnapshot support in Velero, the CNCF's standard backup project, notes that "multi-volume backups on Kubernetes are finally consistent by construction, not by luck."
The mechanism works through three objects: a VolumeGroupSnapshotClass that describes how group snapshots are created for a given storage driver, a VolumeGroupSnapshot that carries the label selector picking out every volume belonging to the application, and a VolumeGroupSnapshotContent that tracks the provisioned result. The report explains that while the API is standard, adoption depends on individual CSI drivers implementing support—a growing set including Ceph CSI now do—and the atomicity guarantee is only as strong as the storage backend behind the driver. Organizations should validate by restoring, not by reading success statuses. Individual volume snapshots remain appropriate for single-volume workloads or genuinely independent volumes, since grouping them adds coordination overhead with no benefit. But any application where cross-volume write ordering matters—data plus write-ahead logs, data plus index—now has a path to correct snapshots.
The broader shift represents Kubernetes storage catching up to enterprise array capabilities, but as an open standard rather than a vendor-locked feature. Organizations relying on per-volume snapshots today likely have inconsistent restore points that have never been tested under real failure, making an audit of existing backups urgent before the next incident reveals the gap. With backup tooling adopting the upstream API, the days of discovering corrupted restores at 2 a.m. should finally end. The introduction of a standard consistency primitive may reshape expectations around what constitutes production-ready stateful infrastructure, forcing a broader reckoning with the hidden trade-offs teams accepted when they first moved workloads to cloud-native platforms.