Introduction

If a PVC was deleted and the PV moved to Released, recovery is only possible if the underlying storage still exists. In practice, that usually means the PV had a reclaim policy of Retain, or the backend disk survived even though Kubernetes released the claim.

First, Check Whether the Data Still Exists

Start by inspecting the PV:

kubectl get pv
kubectl describe pv my-pv

The key details are:

• 'Status'
• 'Reclaim Policy'
• storage backend identifier
• existing claimRef

If the reclaim policy was Delete and the cloud disk or backend volume was actually destroyed, Kubernetes cannot recover the data for you. At that point you need snapshots, backups, or provider-level recovery options.

If the policy was Retain, the data is often still present and the PV is recoverable manually.

Why Released Happens

When a PVC is deleted, Kubernetes does not automatically make a retained volume reusable. The PV still remembers the old claim through claimRef, so its state becomes Released rather than Available.

That is a safety feature. It prevents another claim from silently attaching to data that belonged to a previous workload.

So recovery usually means:

1. confirm the backend storage is still there
2. remove the stale claim reference
3. bind a new PVC to the existing PV
4. mount it in a recovery Pod

Remove the Old Claim Reference

The usual manual step is editing the PV to clear claimRef:

kubectl edit pv my-pv

Remove the claimRef section, save, and exit.

After that, Kubernetes can consider the volume for rebinding. In some environments, admins prefer a patch-based workflow, but the important idea is the same: the old deleted claim reference must be removed.

Create a New PVC That Binds to the Existing PV

Create a new claim that points at the recovered volume explicitly:

1apiVersion: v1
2kind: PersistentVolumeClaim
3metadata:
4  name: recovered-data
5spec:
6  accessModes:
7    - ReadWriteOnce
8  resources:
9    requests:
10      storage: 20Gi
11  volumeName: my-pv
12  storageClassName: ""

Apply it:

kubectl apply -f recovered-pvc.yaml
kubectl get pvc recovered-data

Using volumeName tells Kubernetes exactly which PV you want. Setting storageClassName explicitly can help avoid accidental dynamic provisioning when your goal is to reattach an existing volume.

Mount the Recovered Claim in a Pod

Once the new PVC is bound, mount it in a simple recovery Pod:

1apiVersion: v1
2kind: Pod
3metadata:
4  name: recovery-shell
5spec:
6  containers:
7    - name: shell
8      image: busybox:1.36
9      command: ["sh", "-c", "sleep 3600"]
10      volumeMounts:
11        - name: data
12          mountPath: /data
13  volumes:
14    - name: data
15      persistentVolumeClaim:
16        claimName: recovered-data

Then inspect the files:

kubectl exec -it recovery-shell -- sh
ls -la /data

This is the safest way to verify whether the expected application data is still present before reconnecting the volume to a production workload.

Be Careful with Stateful Workloads

If the original application might still be running somewhere else, make sure the recovered volume is not being written to by two workloads at the same time. Data recovery is not just about reattaching storage. It is also about avoiding corruption.

This is especially important with ReadWriteOnce volumes, databases, and filesystems that assume exclusive access.

When Recovery Is Not Possible

Recovery is usually not possible through Kubernetes alone when:

• the reclaim policy was Delete and the backend storage was removed
• the storage backend scrubbed the data after release
• the PV object still exists but points to a disk that no longer does

In those cases, the next layer to investigate is your storage provider, snapshots, or backups. Kubernetes only manages the attachment metadata. It is not a backup system.

Common Pitfalls

• Assuming Released automatically means the data is gone. Often it just means the old claim reference still exists.
• Rebinding the PV without first checking whether the underlying storage was retained.
• Forgetting to clear claimRef, which prevents the volume from becoming reusable.
• Accidentally triggering dynamic provisioning instead of binding the old PV.
• Mounting the recovered volume into a live workload before verifying the contents safely.

Summary

• A Released PV is often recoverable if the underlying storage still exists.
• Recovery usually requires clearing the stale claimRef and creating a new PVC bound to the old PV.
• Mount the recovered claim in a simple Pod first to inspect the data safely.
• If the reclaim policy was Delete and the backend volume is gone, Kubernetes cannot restore it for you.
• Retained PVs are not backups, but they do make manual recovery possible.