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)
@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.