Introduction

A PersistentVolumeClaim does not normally "delete the contents of the pod." What usually happens is either a volume mount hides the files that were baked into the container image at that path, or the backing storage is cleared because of the reclaim policy after the PVC itself is deleted.

The Most Common Cause: Mounting Over an Existing Directory

When you mount a volume into a container, Kubernetes mounts it at the target path inside the container filesystem. That mount overlays whatever the image originally had in that directory.

Example:

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

If the image originally contained files under /data, they will appear to vanish after the PVC is mounted there. They were not deleted from the image. They are simply hidden by the mounted volume.

Why This Feels Like Data Loss

From inside the running container, the result looks like deletion because ls /data now shows the contents of the PVC-backed volume instead of the image layer. This is normal mount behavior and not specific to Kubernetes.

If you need both the image files and the persistent volume, use one of these patterns:

• Mount the PVC at a different path.
• Copy initial files into the volume during startup.
• Use an init container to seed the volume before the main container starts.

Seeding a Volume Safely

A common approach is to keep the image data in one path and copy it into the mounted volume when the volume is empty.

1apiVersion: v1
2kind: Pod
3metadata:
4  name: seeded-demo
5spec:
6  initContainers:
7    - name: seed
8      image: busybox
9      command: ["sh", "-c", "cp -rn /seed/. /workdir/"]
10      volumeMounts:
11        - name: app-storage
12          mountPath: /workdir
13  containers:
14    - name: app
15      image: busybox
16      command: ["sh", "-c", "ls -la /workdir && sleep 3600"]
17      volumeMounts:
18        - name: app-storage
19          mountPath: /workdir
20  volumes:
21    - name: app-storage
22      persistentVolumeClaim:
23        claimName: app-pvc

The key idea is that the application should treat the volume as the authoritative writable location instead of expecting the image directory contents to remain visible after mounting.

Actual Data Deletion Happens at the Volume Layer

Real data loss usually happens when the PVC or PV is deleted and the storage backend is configured with a destructive reclaim policy. The important field is on the PersistentVolume, not inside the pod:

1apiVersion: v1
2kind: PersistentVolume
3metadata:
4  name: app-pv
5spec:
6  capacity:
7    storage: 10Gi
8  accessModes:
9    - ReadWriteOnce
10  persistentVolumeReclaimPolicy: Retain

Typical reclaim policies are:

• 'Retain, which preserves the underlying storage after claim deletion.'
• 'Delete, which removes the backing storage automatically.'

If a PVC is removed and the PV uses Delete, the underlying data may really be destroyed by the storage provider.

Distinguish Pod Restart From Volume Deletion

A pod restart does not delete a correctly attached persistent volume. That is the whole point of a PVC. If data disappears after a restart, investigate these possibilities:

• The volume was mounted at the wrong path.
• The application writes to a non-persistent path instead of the mounted directory.
• A startup script clears the directory.
• The claim was rebound or recreated against different storage.

In other words, do not blame the PVC first. Confirm where the application was actually writing.

Common Pitfalls

• Mounting a PVC over a directory that already contains image files and interpreting the overlay as deletion.
• Writing application data outside the mounted path and losing it on container restart.
• Deleting the PVC without checking the PV reclaim policy.
• Assuming a pod restart and PVC deletion have the same storage consequences.
• Seeding a volume incorrectly and overwriting existing persistent data on every startup.

Summary

• A PVC usually does not delete pod contents; it mounts storage over a path.
• Files from the image can appear to vanish because the mount hides them.
• Use a different mount path or an init container if you need to seed persistent storage.
• Real data loss is usually tied to PVC or PV deletion and the reclaim policy.
• Always verify where the application writes before concluding that Kubernetes removed your data.