Correcting a PVC request does not shrink the volume
Kubernetes 1.34 lets failed expansion requests be corrected. Separate requested size, allocated capacity and group snapshots when planning storage recovery.
By 
Paul. Architecture and infrastructure
A storage incident can contain three different numbers: the capacity someone requested, the capacity actually allocated and the capacity needed to restore a useful recovery point. A runbook that treats them as the same state can turn a correction into a dangerous assumption. Kubernetes 1.34 made failed expansion requests easier to amend. It did not make physical volume shrinking supported or make a snapshot sufficient proof of recoverability.
Looking back from November 2026, the 19 September 2025 recovery announcement describes the feature reaching general availability in 1.34. Its example concerns an oversized request that has not completed. The corrected request must remain larger than the original actual capacity in .status.capacity. That is a boundary on an unfulfilled growth request, not permission to reclaim already allocated storage by lowering a manifest value.
Start with the state that actually exists
A desired size expresses an instruction. Status and storage-system observations describe progress toward it. When an expansion fails, copying the desired value into an incident summary as though it were allocated capacity loses the information needed to choose the next step. Preserve the original size, unsuccessful target and observed progress separately before deciding what a correction can accomplish.
The version 1.34 feature-gate reference lists RecoverVolumeExpansionFailure as enabled and GA in 1.34, after enabled beta in 1.32–1.33. A cluster version is still insufficient evidence about the complete storage path. Expansion needs an expansion-capable driver and an appropriate StorageClass with expansion allowed; the versioned persistent-volume documentation describes those prerequisites. Confirm the installed components rather than assuming every storage backend acquired the same ability.
The business distinction is straightforward. Correcting an impossible request can let a still-needed, smaller expansion proceed. It does not return the application to an earlier data state. If the incident concerns corrupted records rather than an unavailable expansion target, the desired-size correction addresses a different problem. Naming the incident accurately keeps operators from promising recovery through a mechanism that only changes requested capacity.
A group snapshot answers another question
The 16 September 2025 group-snapshot article concerns the move to v1beta2, a second beta of extension APIs supported by CSI drivers. It describes crash-consistent snapshots across a selected group of volumes. This was not the GA status of expansion recovery, and it was not a guarantee that all storage providers supported group snapshots.
The API revision addressed missing restoreSize information when a driver did not implement ListSnapshots. The post describes per-snapshot information returned through the driver and a conversion webhook for existing beta objects. These details matter because recognizing a group object and obtaining the metadata needed for individual restore volumes are separate capabilities. An API name in a release summary cannot establish that the installed controller, sidecar and driver agree on that contract.
Component availability has its own chronology: external-snapshotter v8.4.0, released on 23 October 2025, explicitly introduces v1beta2. The September article alone cannot date that component release. The v8.4.0 README requires group-snapshot CRDs and CSIVolumeGroupSnapshot enablement in both snapshot controller and CSI snapshotter sidecar; it describes group support for CSI 1.10.0 and later. The driver still needs the group operation, and serving older beta objects needs the conversion webhook. These are later, versioned implementation details, not proof of availability on every September cluster. This article changes none of those components.
Crash consistency leaves application work
A crash-consistent point across volumes is useful because the captured storage state corresponds to a common failure boundary. It does not mean an application deliberately stopped writes and established its own consistent business checkpoint. A database and an attached file store can have obligations that require application-specific coordination. Grouping their claims by label does not define that coordination.
A recovery plan should therefore say what the application expects to find after restoration. It may need replay, reconciliation or a documented quiescence procedure when creating a recovery point. Which procedure is appropriate depends on the application and driver contract. These are design questions, not a claimed Kubernetes recovery experiment or a universal instruction to pause every workload.
Restore availability also depends on more than retaining an API object. The underlying snapshots, permissions, compatible destination capacity and restoration path must still exist when needed. A successful capture does not prove that a replacement environment can use it. The relevant evidence would come from an authorized restore exercise with application checks; no cluster mutation, snapshot creation or restore was performed for this article.
Keep the smallest adequate recovery plan
The strongest counterargument is an application with one ordinary volume and a failed request that never changed its allocated size. Group snapshots and application coordination can be irrelevant to correcting that incident. A focused correction under the documented expansion prerequisites may be sufficient. Adding a complicated restore procedure merely because a neighbouring release post mentions snapshots can increase confusion.
Conversely, where the incident genuinely requires restoring several volumes, changing a PVC request cannot substitute for a recovery point. Keep capacity correction and restoration as separate branches in the runbook. Record which observations select each branch and which person can confirm the application result. That makes the plan useful under pressure without pretending the platform has removed every storage-specific condition.
For custom software development, hand over a storage-state explanation with the operational instructions. Identify requested growth, allocated capacity and recoverable data independently. Use the September changes for the narrower contracts they improve, and require application evidence before declaring that a storage operation restored the service customers actually need.