A PersistentVolumeClaim requests storage with an access mode and size. The bound volume may outlive a Pod, but persistence alone is not a backup. A StorageClass and volume reclaim policy determine how the underlying storage is provisioned and what may happen when claims are removed. StatefulSet identity and storage are useful for some stateful systems, yet they do not replace the database's replication or recovery design.
Make this comfortable
Persistent storage: PVC lifecycle and data ownership
Operational decision
For an audit-journal component, first decide whether its data belongs on a managed database, object store, or a Pod-mounted volume. If a PVC is required, name the StorageClass, capacity, access mode, encryption expectations, snapshot method, and reclaim behavior. The sample requests 37 GiB with ReadWriteOnce; that mode constrains mounting according to the storage driver and is not a cross-zone replication promise. Rehearse Pod replacement, node loss, and claim deletion in a disposable namespace. Inspect the StorageClass reclaimPolicy before assuming deleted claims preserve data. Store the application's schema revision with backup metadata so restored data can be opened by a compatible image. A successful reschedule to a new node only proves attachment, not data integrity.
apiVersion: v1
kind: PersistentVolumeClaim
metadata: {name: audit-journal-data, namespace: audit}
spec:
accessModes: [ReadWriteOnce]
storageClassName: encrypted-durable
resources:
requests:
storage: 37GiCost and verification
Durable storage costs money even when the application is idle, and snapshots consume additional capacity. ReadWriteOnce does not mean exactly one Pod in all circumstances; interpret the access mode through its Kubernetes and driver semantics. The sample StorageClass name is illustrative and must exist in the target cluster. Volume deletion can be irreversible when the class uses Delete reclaim policy. Keep restore tests independent of the volume's apparent persistence and monitor capacity before the filesystem fills.
Common Mistakes
- Do not call a PVC a backup.
- Do not assume claim deletion retains the underlying disk.
- Do not select a storage class without testing zone and attachment behavior.
Connected lessons
- DevOps: delivery, infrastructure, and reliable operations
- Backups and disaster recovery: prove the restore path
- Kubernetes requests and limits: schedule for real load
- Database change safety: expand, migrate, contract
Advanced follow-up
Advanced follow-up
Advanced follow-up
Advanced follow-up
- ReadWriteOncePod: enforce one Kubernetes writer for one claim
- Delayed volume binding: choose storage topology with the first Pod
- PVC expansion: verify both backing volume and usable filesystem
- PV reclaim policy: trace the real asset before deleting a claim
Linux storage follow-up
devops
operations