Kubernetes persistent storage is a storage model that keeps application data available beyond the lifecycle of individual Pods. It separates durable state from the replaceable compute that reads and writes it.
For small teams, the important decision is not simply whether Kubernetes can mount a volume. It is whether a workload genuinely needs durable filesystem semantics, how that storage will be provisioned and reclaimed, and what protects the data when persistence alone is not enough. Raff Technologies provides managed Kubernetes storage independently from individual Pods, but the same production rule still applies: a volume that survives a Pod replacement is not automatically a backup.
The practical model is to treat PersistentVolumes, PersistentVolumeClaims, StorageClasses, snapshots, and backups as different layers. This guide explains those layers, the trade-offs between them, and the recovery questions a small team should answer before putting important state inside a cluster.
Kubernetes persistent storage separates state from the Pod lifecycle
Containers and Pods are designed to be replaceable. A Pod can be recreated after a crash, rescheduled onto another worker, replaced during a rollout, or removed when a workload scales down. Data that must survive those events needs a lifecycle that is not tied to the individual Pod.
Kubernetes provides that separation through its persistent storage subsystem.
Application Pod ↓ mounts PersistentVolumeClaim (PVC) ↓ binds to PersistentVolume (PV) ↓ provisioned through StorageClass / storage implementation
A PersistentVolume is a cluster storage resource with a lifecycle independent of the individual Pod using it. A PersistentVolumeClaim is the workload's request for storage. A StorageClass describes how a class of storage can be provisioned and what lifecycle behavior applies to dynamically created volumes.
That abstraction is useful because application configuration can request storage without hard-coding the details of the underlying storage system.
It is also easy to overestimate what persistence solves. A PV can preserve data when a Pod disappears while still leaving the application exposed to accidental deletion, corrupt writes, destructive migrations, compromised credentials, or a failed restore process.
At Raff, the storage review rule is to name the data, access pattern, reclaim behavior, and restore path before approving persistent state. If the restore plan is only “the volume survives,” the recovery design is incomplete.
PersistentVolumes, claims, and StorageClasses divide responsibility
The three core objects solve different parts of the storage problem.
| Kubernetes object | Primary responsibility | Production question |
|---|---|---|
| PersistentVolume (PV) | Represents durable storage available to the cluster | What storage resource exists? |
| PersistentVolumeClaim (PVC) | Requests capacity and access characteristics | What does this workload need? |
| StorageClass | Defines a provisionable class of storage | How should matching storage be created and managed? |
A PVC can request capacity and an access mode without needing to know the storage implementation behind it. When dynamic provisioning is configured, a matching StorageClass can cause a volume to be provisioned specifically for that claim.
This is usually cleaner than applications shipping their own pre-created PV definitions. Kubernetes documentation recommends portable application configuration around PVCs and a selectable storage class rather than assuming the application has permission to create the underlying PersistentVolume.
StorageClasses are also where administrators can define important storage behavior such as the provisioner, reclaim policy, binding mode, parameters, and whether expansion is allowed when the storage implementation supports it.
For a small team, this division creates a useful ownership boundary:
- application teams define the storage requirement;
- the cluster provides approved storage classes;
- the storage implementation handles provisioning and attachment;
- the recovery process protects the business data independently from ordinary volume lifecycle.
The simpler this contract is, the easier it is to move workloads between nodes or replace application Pods without turning storage into a manual infrastructure task.
Access modes and binding behavior shape workload placement
Storage capacity is only one part of the decision. A stateful workload also needs the right access pattern.
Kubernetes PersistentVolumes can advertise access modes including ReadWriteOnce, ReadOnlyMany, ReadWriteMany, and ReadWriteOncePod. These names are easy to read too broadly.
For example, ReadWriteOnce means the volume can be mounted read-write by a single node. Multiple Pods on that same node can still use the volume. ReadWriteOncePod is the stricter mode intended to restrict read-write access to one Pod when supported by the CSI storage stack.
The application requirement should therefore come first:
| Requirement | Storage implication |
|---|---|
| One stateful Pod writes the filesystem | Single-writer storage may fit |
| Several replicas need the same writable filesystem | Shared-write capability is required |
| Replicas can rebuild local state | Persistent storage may be unnecessary |
| Data is really database state | Database-aware storage and backup may be more important than filesystem sharing |
| Data is shared user uploads | Object storage may be a better architecture than a shared mounted disk |
Binding behavior matters as well. Some StorageClasses can use WaitForFirstConsumer, delaying volume binding and provisioning until Kubernetes knows where the consuming Pod will be scheduled. That can help storage provisioning account for node topology and placement constraints instead of committing storage before workload placement is known.
This is one reason storage class design belongs in cluster architecture rather than being treated as an application-only setting.
Reclaim policy controls what happens after a claim is released
A volume surviving a Pod replacement is different from a volume surviving deletion of the claim that consumed it.
StorageClasses can define a reclaim policy for dynamically provisioned PersistentVolumes. The two important behaviors are Delete and Retain.
Delete means the dynamically provisioned storage is normally removed when the corresponding claim is released, according to the storage provider's implementation. Kubernetes documentation states that Delete is the default when a StorageClass does not specify a reclaim policy.
Retain preserves the PersistentVolume and underlying storage for manual recovery or reuse after the claim is released. That reduces the chance that claim deletion immediately destroys the underlying data, but it also introduces operational work because the retained storage must be reviewed and managed deliberately.
The decision should follow the data rather than a universal preference.
| Data type | Reclaim preference to evaluate | Why |
|---|---|---|
| Disposable cache | Delete may be appropriate | Data can be rebuilt |
| Development test data | Delete may reduce abandoned storage | Low recovery value |
| Business-critical filesystem state | Retain may provide a safer deletion boundary | Accidental claim deletion should not immediately erase the storage |
| Database volume | Retain may help, but database backup is still required | Filesystem persistence alone is not recovery |
Reclaim policy is therefore a deletion-lifecycle control, not a backup policy.
A retained corrupt volume is still corrupt. A retained volume after a bad schema migration still contains the bad state. The team needs a recovery copy that represents a known restore point.
Snapshots and backups protect different failure modes
Snapshots can be useful, but they should not be described as a universal Kubernetes backup system.
Kubernetes VolumeSnapshot resources are part of the CSI snapshot model. Snapshot availability depends on the Kubernetes distribution, the required snapshot components and CRDs, and support from the CSI storage driver. Kubernetes does not guarantee that every PersistentVolume can be snapshotted simply because it is a PV.
A snapshot is also not automatically application-consistent. If an application is actively writing while storage is captured, the snapshot may represent a crash-consistent point rather than a clean application transaction boundary unless the workload coordinates writes appropriately.
The protection layers solve different risks:
| Protection layer | Protects mainly against | Does not prove |
|---|---|---|
| PersistentVolume | Pod/container replacement | Historical restore is possible |
| Storage replication | Loss of an individual storage component | Deleted or corrupted data can be rolled back |
| Volume snapshot | Point-in-time storage state when supported | Application consistency or off-system recovery |
| Application/database backup | Logical data recovery when correctly designed | Restore process actually works |
| Tested restore | Recovery procedure can produce a working system | Future backups will always remain valid |
For critical state, the backup destination should also avoid sharing every failure path with the live storage. A backup that disappears with the same cluster, credentials, or destructive automation as production has a weaker recovery boundary than it appears to have.
Small teams do not need an elaborate disaster-recovery platform for every workload, but they do need an answer to three questions: what is backed up, how long is it retained, and how is it restored?
The decision framework matches data to storage and recovery
PersistentVolumes are appropriate when an application genuinely needs mounted durable filesystem semantics. They are not the default destination for every form of application state.
Use this framework before creating a PVC:
| Workload state | Preferred starting point | Recovery requirement |
|---|---|---|
| Stateless application code | Container image, not persistent storage | Redeploy the image |
| Database records | Managed database or purpose-built database storage where appropriate | Database-consistent backups and restore testing |
| Shared customer uploads | Object storage in many architectures | Retention/versioning/backup appropriate to the data |
| Filesystem-dependent app data | PVC/PV through an approved StorageClass | Snapshot/backup plan plus restore test |
| Cache or rebuildable index | Disposable or service-managed state | Rebuild procedure |
| Local scratch/work files | Ephemeral storage | No durable recovery requirement |
When a PVC is justified, make five decisions explicitly:
Capacity. Size for current state, growth, working space, and the storage system's expansion behavior. Kubernetes can support volume expansion when the StorageClass and storage implementation allow it, but expansion is not the same as automatic capacity planning.
Access mode. Match the actual writer/reader topology instead of choosing a shared mode “just in case.”
StorageClass. Know which class is requested, whether dynamic provisioning is available, and which lifecycle parameters it applies.
Reclaim policy. Decide what should happen when the claim is deleted or released.
Recovery path. Define snapshots or backups separately from the live volume and test the restore into a usable application state.
A good small-team storage design is usually the one with the fewest stateful workloads that still satisfies the application. Moving uploads, databases, logs, or other data to services designed for those state types can make Kubernetes workers easier to replace and clusters easier to recover.
Raff persistent storage fits the durable filesystem layer
Raff managed Kubernetes provides dedicated cluster storage for workloads that need persistent mounted state. Current Raff Kubernetes storage nodes can be sized from 10 GB to 1,000 GB and are priced at $0.08/GB-month, so 100 GB represents an $8/month storage line.
Raff states that Kubernetes storage is replicated across nodes and that same-region traffic between cluster and storage is not metered. Replication improves the live storage availability model, but it should not be treated as a substitute for backup. If an application deletes data correctly from the filesystem, replication can faithfully preserve that deletion across the storage system.
The same architectural distinction applies to Raff's standalone Volumes product for VM workloads: durable block storage and Kubernetes PVC lifecycle solve related storage problems, but application recovery still depends on the workload and the backup plan around it.
For a small Raff Kubernetes deployment, the useful storage review is:
Does the workload need mounted durable state? ↓ yes Which StorageClass / access pattern fits? ↓ What happens if the Pod or node is replaced? ↓ What happens if the claim or data is deleted? ↓ Where is the recovery copy? ↓ Has restore been tested?
Raff also publishes a $0 standard Kubernetes control plane and a $30/month three-master HA option. Control-plane HA and storage replication improve infrastructure availability, but neither answers the application-level question of which data can be restored after corruption or operator error.
Persistent storage should always have an explicit restore path
Kubernetes persistent storage gives state a lifecycle beyond individual Pods, but production durability requires more than a PVC. PersistentVolumes represent storage, claims express workload requirements, and StorageClasses define how storage is provisioned and managed. Reclaim policies determine what happens when claims are released, while snapshots and backups address different recovery scenarios.
For small teams, the cleanest rule is to keep workloads stateless where practical and use persistent volumes only when mounted filesystem state is genuinely required. For every important PVC, document the access mode, storage class, reclaim behavior, backup method, retention period, and restore owner before calling the workload production-ready.
Continue with Kubernetes Networking and Storage Architecture for the broader cluster design and Kubernetes Network Policies for Small Teams for workload traffic isolation.