-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Issue with Velero Restore : Azure disk PV Created with Old SKU Despite Updated Storage Class #8401
Comments
Can you share your PVC & StorageClass YAML as well? Also what type of backup approach do you use? CSI? FSBackup? CSI Datamover? Snapshotting via AzurePlugin? Can you also share version of Velero used |
Hi @anshulahuja98 please find the details StroageClass yaml Default SC
`
` PVC
Backup Approach is Snapshotting via AzurePlugin velero version Helm chart 8.0.0 image version v1.15.0 Velero config
Also what type of backup approach do you use? CSI? FSBackup? CSI Datamover? |
|
Sorry for the delay response . please find detailed yamls and instruction which I am following FYIP velero restore is happening with the updated storage class and the pv is created with update storage class but the skuname is of the old storageclass I am trying to change the SC default (skuname: StandardSSD_LRS) --- > SC name managed-zrs-csi-premium (skuname: Premium_ZRS) YAML for deploy same yaml Velero confimap Storageclass txt Backup & restore instruction velero create backup otx-replica-manual --include-namespaces=otx-replica velero backup create pvc-ns-manual-backup --include-namespaces=pvc-poc velero restore create pvc-restore-v1 --from-backup pvc-ns-manual-backup Please find the Yaml for newly created PV and PVC Below is the velero backup n restore logs backup-logs.txt And If i create new application with managed-zrs-csi-premium storage class directly the PV is created with right sku |
I went through the code for AzurePlugin based restore flow velero/pkg/restore/pv_restorer.go Line 80 in 7e80d8f
Seems like velero might not be fetching the StorageClass for the SKU and relying on the original SKU it saved. This change storage class is probably for dynamic scenarios (CSI) My suggestion for now would be to try your experiment with CSI plugin for snapshotting instead of AzurePlugin. That should work as expected. Once we confirm this behaviour, we can callout in the docs. |
EnableCSI is already true. Is there any other attribute I need to change/Add to use CSI plugin for snapshotting instead of AzurePlugin? My setup instruction helm upgrade -i velero vmware-tanzu/velero -f .\values.yml -n velero below are my values.yml for helm
|
You can follow https://velero.io/docs/v1.15/csi/#installing-velero-with-csi-support on install + running backup which trigger CSI instead of AzurePlugin. |
Hi @kaovilai / @anshulahuja98 I tried with CSI plugin . The issue still persists . The storage class during the restore updates but the SKU type of disk is still old as the pervious storage class
|
please share backup/restore logs, pvc yaml |
What steps did you take and what happened:
I am trying to change to storage class of azure disk from LRS to ZRS or from storage to another using name: change-storage-class-config option in velero
I am trying to change the storage class from the default Storage class i.e SKU StandardSSD_LRS to azuredisk-standard-ssd-zrs i.e SKU StandardSSD_ZRS
What did you expect to happen:
After applying the change-storage-class-config and after restoring the velero backup . The application is UP and new PV, PVC are created and data persist in the new PV.
The Storage is updated in the PVC based on Velero configmap but the SKU of PV is still same after the OLD PV before restore
Below is my configmap and PV yaml after Velero restoration
apiVersion: v1
data:
default: azuredisk-standard-ssd-zrs
kind: ConfigMap
metadata:
labels:
velero.io/change-storage-class: RestoreItemAction
velero.io/plugin-config: ""
name: change-storage-class-config
namespace: velero
apiVersion: v1
kind: PersistentVolume
metadata:
name: pvc-###############
labels:
velero.io/backup-name: test-nginx-12
velero.io/restore-name: restore12
annotations:
pv.kubernetes.io/provisioned-by: disk.csi.azure.com
volume.kubernetes.io/provisioner-deletion-secret-name: ''
volume.kubernetes.io/provisioner-deletion-secret-namespace: ''
finalizers:
- external-provisioner.volume.kubernetes.io/finalizer
- kubernetes.io/pv-protection
- external-attacher/disk-csi-azure-com
spec:
capacity:
storage: 10Gi
csi:
driver: disk.csi.azure.com
volumeHandle: >-
/subscriptions/##########/providers/Microsoft.Compute/disks/restore-##################
volumeAttributes:
csi.storage.k8s.io/pv/name: pvc-#############
csi.storage.k8s.io/pvc/name: PVC-nginx
csi.storage.k8s.io/pvc/namespace: test-nginx-2
requestedsizegib: '10'
skuname: StandardSSD_LRS
storage.kubernetes.io/csiProvisionerIdentity: ############-disk.csi.azure.com
accessModes:
- ReadWriteOnce
claimRef:
kind: PersistentVolumeClaim
namespace: test-nginx-2
name: pvc-nginx
persistentVolumeReclaimPolicy: Delete
storageClassName: azuredisk-standard-ssd-zrs
volumeMode: Filesystem
nodeAffinity:
required:
nodeSelectorTerms:
- matchExpressions:
- key: topology.disk.csi.azure.com/zone
operator: In
values:
- westeurope-1
The following information will help us better understand what's going on:
Expected Behavior:
The restored PV should be created with the SKU specified in the new storage class (StandardSSD_ZRS).
Actual Behavior:
The PVC gets restored with the updated storage class, but the new PV is created with the old SKU (StandardSSD_LRS).
Vote on this issue!
This is an invitation to the Velero community to vote on issues, you can see the project's top voted issues listed here.
Use the "reaction smiley face" up to the right of this comment to vote.
The text was updated successfully, but these errors were encountered: