Kubernetes / Storage, Configuration & Data Protection
Check reclaim policy before deleting a Kubernetes storage claim
Deleting a claim can trigger deletion of its backing storage depending on policy and provisioner behavior. Inspect the actual bound PV first.
Environment and inputs: Kubernetes · kubectl with supported client/server versions and delegated RBAC. Examples use namespace app unless noted. Check context, namespace, APIs and provider support first.
Start with this check
Confirm the environment and replace sample objects, namespaces, images, paths and hosts with approved targets. Share only relevant, sanitized output. Follow the workload owner’s process for changes.
kubectl get pv pv-example -o jsonpath='{.spec.persistentVolumeReclaimPolicy}{" "}{.status.phase}{" "}{.spec.claimRef}'Read the result
The result links the example PV to its claim and reclaim behavior. It does not prove a valid backup or authorize cleanup.
Resolve and verify
Confirm the real volume, data owner and recovery copy before any decommission. Use the supported retention or migration plan and verify backend state.
Before changing production
Do not delete a PVC as a troubleshooting experiment or assume recreating its name restores the original data.