<p>I have created/provisioned a PVC and PV dynamically from a custom storage class that has a retain reclaimPolicy using the below k8s resource files.</p>
<pre><code># StorageClass yaml spec
# kubectl apply -f storage-class.yaml

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-ssd
provisioner: kubernetes.io/gce-pd
parameters:
  type: pd-ssd
  fstype: ext4
  replication-type: none
reclaimPolicy: Retain
allowVolumeExpansion: true
volumeBindingMode: Immediate
</code></pre>
<pre><code># PersistentVolumeClaim yaml specs
# kubectl apply -f mysql-pvc.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  labels:
    app: test-mysql
  name: test-mysql-pv-claim
spec:
  storageClassName: &quot;fast-ssd&quot;
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 51G
</code></pre>
<p>Below are the sequence of steps to followed to reproduce my scenario:</p>
<pre><code>ubuntu@ubuntu-ThinkPad-X230-Tablet:/home/ubuntu/test$ kubectl apply -f mysql-pvc.yaml 
persistentvolumeclaim/test-mysql-pv-claim created

ubuntu@ubuntu-ThinkPad-X230-Tablet:/home/ubuntu/test$ kubectl get pvc,pv
NAME                                        STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
persistentvolumeclaim/test-mysql-pv-claim   Bound    pvc-a6bd789c-9e3c-43c8-8604-2e91b2fee616   48Gi       RWO            fast-ssd       7s

NAME                                                        CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                         STORAGECLASS   REASON   AGE
persistentvolume/pvc-a6bd789c-9e3c-43c8-8604-2e91b2fee616   48Gi       RWO            Retain           Bound    default/test-mysql-pv-claim   fast-ssd                6s

ubuntu@ubuntu-ThinkPad-X230-Tablet:/home/ubuntu/test$ kubectl delete -f mysql-pvc.yaml 
persistentvolumeclaim &quot;test-mysql-pv-claim&quot; deleted

ubuntu@ubuntu-ThinkPad-X230-Tablet:/home/ubuntu/test$ kubectl get pvc,pv
NAME                                                        CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS     CLAIM                         STORAGECLASS   REASON   AGE
persistentvolume/pvc-a6bd789c-9e3c-43c8-8604-2e91b2fee616   48Gi       RWO            Retain           Released   default/test-mysql-pv-claim   fast-ssd                44s

ubuntu@ubuntu-ThinkPad-X230-Tablet:/home/ubuntutest$ kubectl apply -f mysql-pvc.yaml 
persistentvolumeclaim/test-mysql-pv-claim created

ubuntu@ubuntu-ThinkPad-X230-Tablet:/home/ubuntu/test$ kubectl get pvc,pv

NAME                                        STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
persistentvolumeclaim/test-mysql-pv-claim   Bound    pvc-fbc266ab-60b0-441b-a789-84f950071390   48Gi       RWO            fast-ssd       6m6s

NAME                                                        CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS     CLAIM                         STORAGECLASS   REASON   AGE
persistentvolume/pvc-a6bd789c-9e3c-43c8-8604-2e91b2fee616   48Gi       RWO            Retain           Released   default/test-mysql-pv-claim   fast-ssd                7m6s
persistentvolume/pvc-fbc266ab-60b0-441b-a789-84f950071390   48Gi       RWO            Retain           Bound      default/test-mysql-pv-claim   fast-ssd                6m5s

</code></pre>
<p>As we can see from the last part of the output new PVC is bounded to new PV, not to the old released PV.</p>
<p>So can we make some changes in mysql-pvc.yaml file so that our PVC can again be reassigned/bounded to old release PV, as that PV will have important data that we need?</p>

devops-admin
<p>When your reclaim policy is &quot;retain&quot;, any change in the pvc YAML will not work.</p>
<p>As per Kubernetes doc:</p>
<blockquote>
<p>The Retain reclaim policy allows for manual reclamation of the resource. When the <code>PersistentVolumeClaim</code> is deleted, the <code>PersistentVolume</code> still exists and the volume is considered &quot;released&quot;. But it is not yet available for another claim because the previous claimant's data remains on the volume. An administrator can manually reclaim the volume with the following steps.</p>
</blockquote>
<ul>
<li>Delete the <code>PersistentVolume</code>. The associated storage asset in external infrastructure (such as an AWS EBS, GCE PD, Azure Disk, or Cinder volume) still exists after the PV is deleted.</li>
<li>Manually clean up the data on the associated storage asset accordingly.</li>
<li>Manually delete the associated storage asset, or if you want to reuse the same storage asset, create a new <code>PersistentVolume</code> with the storage asset definition.</li>
</ul>
<p>Ref:
<a href="https://kubernetes.io/docs/concepts/storage/persistent-volumes/#retain" rel="nofollow noreferrer">https://kubernetes.io/docs/concepts/storage/persistent-volumes/#retain</a></p>
