A team deletes a PVC expecting the data gone, but it's later recovered from the underlying disk — why, and how should reclaim policy be chosen deliberately?

The PersistentVolume's reclaimPolicy — Delete or Retain — controls what happens to the underlying storage when its bound PVC is deleted, independently of whatever the team assumed. If the StorageClass (or the PV) was set to Retain, deleting the PVC only releases the PV from its claim; the underlying disk and its data remain fully intact until someone explicitly deletes it. This is often a deliberate safety default from whoever set up the StorageClass, but it needs to be an explicit, understood decision — not a surprise discovered during an incident or a compliance review.

reclaimPolicy is independent of the PVC deletion action itself: deleting a PVC is a request to release the claim, not an instruction about what should happen to the underlying storage — that separate decision is controlled entirely by the PV's reclaimPolicy, which is typically inherited from the StorageClass that provisioned it, but can also be set directly on the PV object.

Delete reclaim policy actually destroys the underlying storage: when a PVC bound to a PV with reclaimPolicy: Delete is deleted, Kubernetes also deletes the PV object and instructs the storage backend to delete the actual underlying disk — this is the behavior most people intuitively expect from "deleting" storage, and it's the default for many dynamically-provisioned StorageClasses.

Retain reclaim policy deliberately preserves the data: with reclaimPolicy: Retain, deleting the PVC only moves the PV to a Released state — the underlying disk and its data are left completely untouched, and the PV object itself isn't automatically deleted or made available for a new claim. Someone has to explicitly clean it up (or manually re-bind it to a new PVC after clearing its claim reference) for it to be reused or truly removed.

Why Retain is often the deliberately safer default for valuable data: for anything where accidental deletion would be costly (databases, anything subject to data-retention or compliance requirements), Retain is a genuine safety mechanism — it converts an irreversible mistake (accidentally deleting a PVC) into a recoverable one, at the cost of leaving storage (and its cost) allocated until someone actively cleans it up.

The compliance and security implication cuts both ways: Retain protects against accidental data loss, but it also means "deleted" data isn't actually gone — for data subject to a deletion requirement (a right-to-erasure request, a data-retention policy that mandates actual destruction after a period), Retain being the default without anyone realizing it means the organization may not actually be complying with what it believes it's doing when a PVC is deleted.

This should be a deliberate, documented decision per workload, not an inherited default nobody examined: knowing which reclaim policy a given StorageClass uses, and choosing it deliberately based on the workload's actual data-value and compliance requirements (rather than accepting whatever the cluster-wide default happens to be), is what prevents both failure modes — accidental permanent loss on one side, and "deleted" data that isn't actually deleted on the other.

• reclaimPolicy (Delete or Retain), not the act of deleting a PVC itself, determines whether the underlying storage and data actually get destroyed.
• Delete removes both the PV object and the underlying disk; Retain leaves the disk and data fully intact, requiring explicit manual cleanup.
• Retain is a deliberate safety mechanism for valuable data, converting accidental PVC deletion from irreversible to recoverable.
• For data subject to compliance-driven deletion requirements, Retain being the default (without anyone realizing it) can mean "deleted" data isn't actually destroyed — this needs to be a deliberate per-workload decision.

• Kubernetes: Persistent Volumes — Reclaiming