Review Kubernetes reclaim policy before deleting a storage claim

Deleting an application claim can have consequences outside the cluster’s API objects.

Source facts

The reclaim policy on a Kubernetes PersistentVolume determines what happens after its claim is released. Retain leaves the volume and its previous data for manual reclamation; it is not immediately available for another claim. Delete can remove both the PersistentVolume and the associated supported storage asset. The selected policy therefore affects the post-deletion recovery path.

Source: Kubernetes documentation — Persistent Volumes.

Applicability

Review released PersistentVolumes and the supported storage asset affected by their reclaim policy.

DSE recommendation

DSE recommends recording the actual volume, claim, storage backend identifier, and reclaim policy before any application retirement or namespace cleanup. Confirm which data must be preserved and where a usable recovery copy exists. Do not infer retention from the application’s deletion procedure or from an assumed StorageClass default. For retained assets, assign an owner and a controlled reclamation process so preserved data does not become untracked infrastructure. For deletion, require evidence that the business retention requirement has already been met elsewhere.

Verification

On a disposable volume, delete its test claim and inspect both Kubernetes objects and the backend asset. Confirm that the observed retention or deletion matches the recorded policy. Treat a successful backup job as insufficient until a suitable restore exercise has been completed. Keep the test backend identifier in the evidence so an absent API object cannot be mistaken for deleted storage. Have the data owner approve the retained-data handling or the separate recovery copy before repeating the procedure on a real retirement.

Official reference

Kubernetes documentation — Persistent Volumes. Reviewed October 20, 2026.