How to fix PersistentVolumeClaim status.phase=Lost in Kubernetes

KubernetesADVANCEDCRITICALUpdated Dec 6, 2025· 169 views

A PVC has entered the Lost phase, meaning it lost its binding to the underlying PersistentVolume. This is a critical error indicating data may be inaccessible or lost. It occurs when the PV is deleted while PVC still references it, storage backend fails, or finalizers block cleanup. Recovery is difficult; prevention through backups is essential.

Quick fix

Fixes PersistentVolumeClaim status.phase=Lost

kubectl get pvc -n <namespace>
kubectl describe pvc <pvc-name> -n <namespace>
kubectl get pv
kubectl describe pv <pv-name>
  1. Verify the PVC status and check if PV still exists
  2. Check the underlying storage system
  3. Attempt to rescue data if storage still exists
  4. Clean up Lost PVC and PV objects
kubernetes — error
kubectl get pvc -n <namespace>
kubectl describe pvc <pvc-name> -n <namespace>
kubectl get pv
kubectl describe pv <pv-name>
PersistentVolumeClaim status.phase=Lost

What this error means

When a PersistentVolume is deleted or becomes inaccessible while a PersistentVolumeClaim (PVC) still references it, Kubernetes marks the PVC as Lost. This is a final-state error indicating that Kubernetes can no longer guarantee data availability. The PVC object exists but points to a volume that no longer exists or is unreachable. Pods depending on the Lost PVC cannot start. In most scenarios, data on the lost volume is permanently unavailable without manual storage backend recovery (which is often impossible).

Typical symptoms

  • kubectl get pvc shows phase=Lost instead of Bound
  • Pod fails to schedule with "PersistentVolumeClaim not found" or similar message
  • Application logs indicate "volume does not exist" or mount failures
  • Pod remains in Pending state indefinitely despite PVC existing
  • Storage events warn "Data on the volume is lost!" or "ClaimLost" conditions
  • kubectl describe pvc shows no binding to a PersistentVolume

Common causes

  1. PersistentVolume backing the PVC was deleted (intentionally or accidentally)
  2. Underlying storage infrastructure (EBS volume, GCP PD, etc.) was deleted or destroyed
  3. Storage backend failure or permanent loss of storage device
  4. Reclaim policy set to Retain but underlying storage capacity was lost
  5. Finalizer deadlock preventing PVC and PV cleanup, resulting in Lost state
  6. Node crash or network partition preventing access to NFS/remote storage volumes

How to fix "PersistentVolumeClaim status.phase=Lost"

1Verify the PVC status and check if PV still exists

First, confirm the Lost state and check for the backing volume:

bash
kubectl get pvc -n <namespace>
kubectl describe pvc <pvc-name> -n <namespace>
kubectl get pv
kubectl describe pv <pv-name>

If the PV doesn't appear in the list or its status shows "Released" but no volume is accessible, the underlying storage is likely gone.

2Check the underlying storage system

Depending on your storage type, check if the physical storage exists:

For cloud volumes (AWS EBS, GCP PD, Azure Disk):

bash
# AWS EBS
aws ec2 describe-volumes --volume-ids vol-xxxxx

# GCP Persistent Disk
gcloud compute disks describe <disk-name> --zone <zone>

# Azure Managed Disk
az disk show --resource-group <rg> --name <disk-name>

For NFS/network storage:

bash
kubectl exec -it <pod> -- mount | grep <volume-path>
kubectl exec -it <pod> -- df -h | grep <volume-path>

For local volumes:

SSH to the node and check if the path exists and is accessible:

bash
ssh <node>
ls -la <local-volume-path>
3Attempt to rescue data if storage still exists

If the underlying storage device still exists (visible in cloud console or mounted on node) but the PV is Lost:

1. Create a recovery pod that directly accesses the storage:

yaml
apiVersion: v1
kind: Pod
metadata:
  name: recovery-pod
spec:
  nodeSelector:
    kubernetes.io/hostname: <node-with-storage>
  containers:
  - name: recovery
    image: ubuntu:latest
    command: ["/bin/bash"]
    args: ["-c", "sleep 3600"]
    volumeMounts:
    - name: recovery-vol
      mountPath: /data
  volumes:
  - name: recovery-vol
    hostPath:
      path: <path-to-storage>  # Local path to volume
      type: Directory

2. Copy data to persistent storage (e.g., cloud object storage, external NFS):

bash
kubectl cp recovery-pod:/data /tmp/recovered-data
# Then copy to external storage:
gsutil -m cp -r /tmp/recovered-data/* gs://backup-bucket/

3. Restore from backup if available (see Prevention section).

4Clean up Lost PVC and PV objects

Once you've attempted recovery, remove the Lost resources to avoid confusion:

bash
kubectl delete pvc <pvc-name> -n <namespace>
kubectl delete pv <pv-name>

If deletion hangs due to finalizers, force-remove them:

bash
kubectl patch pvc <pvc-name> -n <namespace> -p '{"metadata":{"finalizers":null}}' --type=merge
kubectl patch pv <pv-name> -p '{"metadata":{"finalizers":null}}' --type=merge
kubectl delete pvc <pvc-name> -n <namespace> --force --grace-period=0
kubectl delete pv <pv-name> --force --grace-period=0
5Recreate PVC and PV with correct configuration

Deploy fresh persistent storage:

yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: standard
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp3
  iops: "3000"
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: data-claim
spec:
  storageClassName: standard
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 50Gi

Apply and verify binding:

bash
kubectl apply -f storage.yaml
kubectl get pvc,pv
6Restore application data from backup

Use your backup solution to restore the latest good copy:

Using Velero (Kubernetes backup framework):

bash
velero restore create --from-backup <backup-name>
velero restore logs <restore-name>

Using Kasten K10:

Use the K10 dashboard to restore PVCs from snapshots.

Using manual snapshots:

If you took AWS EBS snapshots, GCP disk snapshots, or other backups before loss:

bash
# AWS EBS
aws ec2 create-volume --snapshot-id snap-xxxxx --availability-zone <zone>

# GCP
gcloud compute disks create <new-disk> --source-snapshot=<snapshot-name>

Once the volume is restored, mount it in a new PVC and restore your application.

Advanced notes

Prevention is critical since Lost PVCs usually result in permanent data loss. Implement automated backup solutions (Velero, Kasten K10) that snapshot PVC data independent of cluster lifecycle. Enable Kubernetes VolumeSnapshot API and regularly test snapshot recovery. Use storage replication at the infrastructure layer (AWS multi-AZ EBS, GCP regional persistent disks, Azure zone-redundant storage). Configure RBAC strictly to prevent accidental PV/PVC deletion. Monitor PVC health with alerts on phase changes, binding failures, or capacity issues. For critical applications, use ReadWrite Many (RWX) access modes with replicated storage (NFS with HA, Ceph) so pod rescheduling doesn't lose data. Document PVC dependencies and backup schedules for all stateful services. Regularly test disaster recovery procedures and cluster migration scenarios. Note: Once a PVC reaches Lost state, data recovery is extremely difficult; focus resources on prevention.

Frequently asked questions

What does "PersistentVolumeClaim status.phase=Lost" mean?
When a PersistentVolume is deleted or becomes inaccessible while a PersistentVolumeClaim (PVC) still references it, Kubernetes marks the PVC as Lost. This is a final-state error indicating that Kubernetes can no longer guarantee data availability. The PVC object exists but points to a volume that no longer exists or is unreachable.
How do I fix "PersistentVolumeClaim status.phase=Lost"?
A PVC has entered the Lost phase, meaning it lost its binding to the underlying PersistentVolume. This is a critical error indicating data may be inaccessible or lost. It occurs when the PV is deleted while PVC still references it, storage backend fails, or finalizers block cleanup. Recovery is difficult; prevention through backups is essential.
What causes "PersistentVolumeClaim status.phase=Lost"?
PersistentVolume backing the PVC was deleted (intentionally or accidentally) Underlying storage infrastructure (EBS volume, GCP PD, etc.) was deleted or destroyed Storage backend failure or permanent loss of storage device
Is the "PersistentVolumeClaim status.phase=Lost" error serious?
Yes. This is a critical-severity error that usually blocks work until it is fixed, but the steps above resolve it.

Official resources & further reading