velero: On restore PV is not getting restored correctly in Azure AKS

What steps did you take and what happened: I created a namespace soumya and created a deployment, pvc and pv(dynamically provisioned csi disk) in the namespace. The PV created was with retain data. Then i triggered velero backup for the cluster.

After the backup is complete, i deleted the deployment, pvc, pv and the underlying azure disk and then retriggered restored

Post restore i see that deployment anf pvc is restored. PV is restored with the same name as it was backed up and the underlying disk was missing.

What did you expect to happen:

on restore the PV should have been created with a different name as it is dynamically provisioned. To fully confirm this behaviour i retriggered another restore from the same backup , but this time i restored the backed up resources in a different namespace soumya1. Post restore i could see deployment, pvc, pv(with a different name) and also the underlying disk getting created successfully.

Sharing the data post restore. During backup also the pv name was pvc-41f06d44-68f8-4e82-a3e3-f479ae7c09c4

PS C:\Users\sopattna\aks> kubectl get deployment --namespace=soumya
NAME                READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment1   0/2     2            0           162m
nginx-deployment2   0/2     2            0           162m
PS C:\Users\sopattna\aks> kubectl get pvc --namespace=soumya
NAME             STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
pvc-azuredisk2   Bound    pvc-41f06d44-68f8-4e82-a3e3-f479ae7c09c4   10Gi       RWO            managed-csi    163m
PS C:\Users\sopattna\aks> kubectl get deployment --namespace=soumya1
NAME                READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment1   2/2     2            2           157m
nginx-deployment2   2/2     2            2           157m
PS C:\Users\sopattna\aks> kubectl get pvc --namespace=soumya1
NAME             STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
pvc-azuredisk2   Bound    pvc-3eb1b795-b4d2-48bf-89d9-3ce518861d53   10Gi       RWO            managed-csi    158m
PS C:\Users\sopattna\aks> kubectl get pv
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                    STORAGECLASS   REASON   AGE
pvc-3eb1b795-b4d2-48bf-89d9-3ce518861d53   10Gi       RWO            Delete           Bound    soumya1/pvc-azuredisk2   managed-csi             158m
pvc-41f06d44-68f8-4e82-a3e3-f479ae7c09c4   10Gi       RWO            Retain           Bound    soumya/pvc-azuredisk2    managed-csi             163m

Attaching the logs for backup and restores clusterbackup-dataprotection-microsoft-backup-47e70f1e-c1fa-4615-bc20-b01bf772c1d5-logs - backup logs restore-clusterbackup-dataprotection-microsoft-restore-6f926513-fc7e-439d-a20c-a8cda64973a4-logs - restore to soumya namespace logs. Here the same name pv is getting created which is not expected restore-clusterbackup-dataprotection-microsoft-restore-8aa648c4-4ac2-4729-acef-220a613e6eeb-logs- restore to namespace soumya1 with dynamically created PV which is the desired behavior restore-clusterbackup-dataprotection-microsoft-restore-6f926513-fc7e-439d-a20c-a8cda64973a4-logs.gz clusterbackup-dataprotection-microsoft-backup-47e70f1e-c1fa-4615-bc20-b01bf772c1d5-logs.gz restore-clusterbackup-dataprotection-microsoft-restore-8aa648c4-4ac2-4729-acef-220a613e6eeb-logs.gz

About this issue

  • Original URL
  • State: closed
  • Created a year ago
  • Comments: 26 (14 by maintainers)

Most upvoted comments

@anshulahuja98 It’s OK but we’ll make sure there’s a design about the structure of the additional metadata for PV. I’ll try to discuss that in Community meeting after we are back from holiday.