<p>I'm currently trying out Azure AKS and during setup I obviously also want to make backups. For this the best practice seems to be velero. According to the documentation of velero to include pv snapshots you would annotate the pod/deployment. Example:</p>

<pre><code>backup.velero.io/backup-volumes: wp-pv
</code></pre>

<p>Note the above is when using a static managed disk. I can see the snapshot is created. However, when I do a restore a new pv is created instead of using the one from the restore. Is this expected behavior?</p>

<p>Ideally, I would like to use dynamic pv's instead but this would make it even more trivial because I don't know what name the pv will have and thus can't add proper annotations beforehand. </p>

<p>How can I solve this in a clean way? My ideal situation would be to have scheduled backups using velero and in case of a recovery automatically have it use the snapshot as base for the pv instead of it creating a new one that doesn't contain my data. For now, it seems this is a manual procedure? Am I missing something?</p>

xtrc
<p>This is by design. </p>

<p>PersistantVolumes by definitions can only ever belong to one PVC claimant. Even when set as dynamic. </p>

<p>I think what you want is to have the reclaim policy set to retain. See here: </p>

<p><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>

<p>A state of "Retain" should mean that the PVs data persists, it is just needing to be reclaimed by a new PV/PVC. The AKS should pick up on this... But I've only ever done this with AWS/Baremetal</p>

<p>In this case Velero, rightly, has to both recreate the PVC and PV for the volume to be released and reassigned to the new claimant. </p>
