# CSI Volume Cloning

LLMS index: [llms.txt](/llms.txt)

---

<!-- overview -->

This document describes the concept of cloning existing CSI Volumes in Kubernetes.
Familiarity with [Volumes](/docs/concepts/storage/volumes) is suggested.

<!-- body -->

## Introduction

The <a class='glossary-tooltip' title='The Container Storage Interface (CSI) defines a standard interface to expose storage systems to containers.' data-bs-toggle='tooltip' data-bs-placement='top' href='/docs/concepts/storage/volumes/#csi' target='_blank' aria-label='CSI'>CSI</a> Volume Cloning feature adds
support for specifying existing <a class='glossary-tooltip' title='Claims storage resources defined in a PersistentVolume so that it can be mounted as a volume in a container.' data-bs-toggle='tooltip' data-bs-placement='top' href='/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims' target='_blank' aria-label='PVC'>PVC</a>s
in the `dataSource` field to indicate a user would like to clone a <a class='glossary-tooltip' title='A directory containing data, accessible to the containers in a pod.' data-bs-toggle='tooltip' data-bs-placement='top' href='/docs/concepts/storage/volumes/' target='_blank' aria-label='Volume'>Volume</a>.

A Clone is defined as a duplicate of an existing Kubernetes Volume that can be
consumed as any standard Volume would be.  The only difference is that upon
provisioning, rather than creating a "new" empty Volume, the back end device
creates an exact duplicate of the specified Volume.

The implementation of cloning, from the perspective of the Kubernetes API, adds
the ability to specify an existing PVC as a dataSource during new PVC creation.
The source PVC must be bound and available (not in use).

Users need to be aware of the following when using this feature:

* Cloning support (`VolumePVCDataSource`) is only available for CSI drivers.
* Cloning support is only available for dynamic provisioners.
* CSI drivers may or may not have implemented the volume cloning functionality.
* You can only clone a PVC when it exists in the same namespace as the destination PVC
  (source and destination must be in the same namespace).
* Cloning is supported with a different Storage Class.
  - Destination volume can be the same or a different storage class as the source.
  - Default storage class can be used and storageClassName omitted in the spec.
* Cloning can only be performed between two volumes that use the same VolumeMode setting
  (if you request a block mode volume, the source MUST also be block mode)

## Provisioning

Clones are provisioned like any other PVC with the exception of adding a dataSource
that references an existing PVC in the same namespace.

```yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
    name: clone-of-pvc-1
    namespace: myns
spec:
  accessModes:
  - ReadWriteOnce
  storageClassName: cloning
  resources:
    requests:
      storage: 5Gi
  dataSource:
    kind: PersistentVolumeClaim
    name: pvc-1
```


<div class="alert alert-info" role="note"><h4 class="alert-heading">Note:</h4>You must specify a capacity value for <code>spec.resources.requests.storage</code>, and the
value you specify must be the same or larger than the capacity of the source volume.</div>


The result is a new PVC with the name `clone-of-pvc-1` that has the exact same
content as the specified source `pvc-1`.

## Usage

Upon availability of the new PVC, the cloned PVC is consumed the same as other PVC.
It's also expected at this point that the newly created PVC is an independent object.
It can be consumed, cloned, snapshotted, or deleted independently and without
consideration for it's original dataSource PVC.  This also implies that the source
is not linked in any way to the newly created clone, it may also be modified or
deleted without affecting the newly created clone.