---
title: Volume claim templates
description: By default, the operator creates a PersistentVolumeClaim with a capacity of 1Gi for each pod in an Elasticsearch cluster to prevent data loss in case...
url: https://www.elastic.co/elastic/docs-builder/docs/4843/deploy-manage/deploy/cloud-on-k8s/volume-claim-templates
products:
- Elastic Cloud on Kubernetes
- Elastic Documentation
applies_to:
- Elastic Cloud on Kubernetes: Generally available
---
# Volume claim templates
### Specifying the volume claim settings
By default, the operator creates a [`PersistentVolumeClaim`](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) with a capacity of 1Gi for each pod in an Elasticsearch cluster to prevent data loss in case of accidental pod deletion. For production workloads, you should define your own volume claim template with the desired storage capacity and (optionally) the Kubernetes [storage class](https://kubernetes.io/docs/concepts/storage/storage-classes/) to associate with the persistent volume.
The name of the volume claim must always be `elasticsearch-data`, unless you set up a corresponding volume mount yourself. Refer to [Use a custom volume claim name](#k8s-volume-claim-templates-custom-name).
```yaml
spec:
nodeSets:
- name: default
count: 3
volumeClaimTemplates:
- metadata:
name: elasticsearch-data
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 5Gi
storageClassName: standard
```
### Use a custom volume claim name
If you name the volume claim something other than `elasticsearch-data`, add a volume mount with the same name to the `elasticsearch` container, and mount it at `/usr/share/elasticsearch/data`. This is the default data path of Elasticsearch in ECK, so you do not need to set `path.data`. ECK rejects a volume claim that is not mounted in any container.
```yaml
spec:
nodeSets:
- name: default
count: 3
podTemplate:
spec:
containers:
- name: elasticsearch
volumeMounts:
- name: my-data
mountPath: /usr/share/elasticsearch/data
volumeClaimTemplates:
- metadata:
name: my-data
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 5Gi
```
Do not mount the volume at another path or set `path.data` yourself. If the mount path differs from the data path, Elasticsearch starts normally but writes its data to the ephemeral storage of the container, and the data is lost when the Pod is recreated.
## Controlling volume claim deletion
ECK automatically deletes PersistentVolumeClaim resources if the owning Elasticsearch nodes are scaled down. The corresponding PersistentVolumes may be preserved, depending on the configured [storage class reclaim policy](https://kubernetes.io/docs/concepts/storage/storage-classes/#reclaim-policy).
In addition, you can control what ECK should do with the PersistentVolumeClaims if you delete the Elasticsearch cluster altogether through the `volumeClaimDeletePolicy` attribute.
```yaml
apiVersion: elasticsearch.k8s.elastic.co/v1
kind: Elasticsearch
metadata:
name: es
spec:
version: 9.5.6
volumeClaimDeletePolicy: DeleteOnScaledownOnly
nodeSets:
- name: default
count: 3
```
The possible values are `DeleteOnScaledownAndClusterDeletion` and `DeleteOnScaledownOnly`. By default `DeleteOnScaledownAndClusterDeletion` is in effect, which means that all PersistentVolumeClaims are deleted together with the Elasticsearch cluster. However, `DeleteOnScaledownOnly` keeps the PersistentVolumeClaims when deleting the Elasticsearch cluster.
After you delete the cluster, do not delete any of the retained PersistentVolumeClaims. ECK does not check the integrity of the data on adopted PersistentVolumeClaims. Missing or damaged data can cause data loss or prevent master discovery. Recovery requires last-resort steps that can also lose data: [restore a snapshot](https://www.elastic.co/elastic/docs-builder/docs/4843/deploy-manage/tools/snapshot-and-restore/restore-snapshot) into a new cluster, or use the `elasticsearch-node` tool as described in [Suspend Elasticsearch](/elastic/docs-builder/docs/4843/troubleshoot/deployments/cloud-on-k8s/troubleshooting-methods#k8s-suspend-elasticsearch).
If you recreate a deleted cluster with the same name, namespace, and node sets as before, the existing PersistentVolumeClaims will be adopted by the new cluster.
### Updating the volume claim settings
If the storage class allows [volume expansion](https://kubernetes.io/blog/2018/07/12/resizing-persistent-volumes-using-kubernetes/), you can increase the storage requests size in the volumeClaimTemplates. ECK will update the existing PersistentVolumeClaims accordingly, and recreate the StatefulSet automatically. If the volume driver supports `ExpandInUsePersistentVolumes`, the filesystem is resized online, without the need of restarting the Elasticsearch process, or re-creating the Pods. If the volume driver does not support `ExpandInUsePersistentVolumes`, Pods must be manually deleted after the resize, to be recreated automatically with the expanded filesystem.
Kubernetes forbids any other changes in the volumeClaimTemplates, such as [changing the storage class](https://kubernetes.io/docs/concepts/storage/storage-classes) or [decreasing the volume size](https://kubernetes.io/blog/2018/07/12/resizing-persistent-volumes-using-kubernetes/). To make these changes, you can create a new nodeSet with different settings, and remove the existing nodeSet. In practice, that’s equivalent to renaming the existing nodeSet while modifying its claim settings in a single update. Before removing Pods of the deleted nodeSet, ECK makes sure that data is migrated to other nodes.
### EmptyDir
Don’t use `emptyDir` as it might generate permanent data loss.
If you are not concerned about data loss, you can use an `emptyDir` volume for Elasticsearch data:
```yaml
spec:
nodeSets:
- name: data
count: 10
podTemplate:
spec:
volumes:
- name: elasticsearch-data
emptyDir: {}
```
Besides the risk of data loss, `emptyDir` (or any volume that isn't a `volumeClaimTemplates` PVC) prevents ECK from determining the storage capacity of the affected nodes. On Elasticsearch 8.3 and later, the `Elasticsearch` resource then reports the `ResourcesAwareManagement` condition as `False`.`ResourcesAwareManagement` indicates whether ECK could compute CPU, memory, and storage for all expected nodes so it can tell Elasticsearch the intended cluster topology. When the condition is `False`, ECK stops publishing that topology and removes any topology it published earlier. Without it, Elasticsearch may make less optimal topology-aware decisions. The condition is cluster-wide, so a single nodeSet using `emptyDir` sets it to `False` for the whole cluster. ECK still reconciles the `Elasticsearch` resource (StatefulSets, Pods, and CPU and memory settings) as usual.