Merge pull request #274970 from rajats22/aksbackupupdate-1005-01

AKS Backup Updates

Author: ttorble

articles/backup/azure-kubernetes-service-backup-troubleshoot.md

@@ -25,9 +25,9 @@ This article provides troubleshooting steps that help you resolve Azure Kubernet
    ```
 
 
-**Cause**: The extension has been installed successfully, but the pods aren't spawning. This happens because the required compute and memory aren't available for the pods.
+**Cause**: The extension is installed successfully, but the pods aren't spawning because the required compute and memory aren't available for the pods.
 
-**Resolution**: To resolve the issue, increase the number of nodes in the cluster. This allows sufficient compute and memory to be available for the pods to spawn.
+**Resolution**: To resolve the issue, increase the number of nodes in the cluster, allowing sufficient compute and memory to be available for the pods to spawn.
 To scale node pool on Azure portal, follow these steps:
 
 1. On the Azure portal, open the *AKS cluster*.
@@ -45,7 +45,7 @@ To scale node pool on Azure portal, follow these steps:
    Endpoint http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&client_id=4e95dcc5-a769-4745-b2d9-
    ```
 
-**Cause**: When you enable pod-managed identity on your AKS cluster, an *AzurePodIdentityException* named *aks-addon-exception* is added to the *kube-system* namespace. An *AzurePodIdentityException* allows pods with certain labels to access the Azure Instance Metadata Service (IMDS) endpoint without being intercepted by the NMI server.
+**Cause**: When you enable pod-managed identity on your AKS cluster, an *AzurePodIdentityException* named *aks-addon-exception* is added to the *kube-system* namespace. An *AzurePodIdentityException* allows pods with certain labels to access the Azure Instance Metadata Service (IMDS) endpoint are not intercepted by the NMI server.
 
 The extension pods aren't exempt, and require the Microsoft Entra pod identity to be enabled manually.
 
@@ -82,13 +82,28 @@ This error appears due to absence of these FQDN rules because of which configura
 
 **Resolution**: To resolve the issue, you need to create a *CoreDNS-custom override* for the *DP* endpoint to pass through the public network.
 
-1. To fetch *Existing CoreDNS-custom* YAML in your cluster (save it on your local for reference later), run the following command:
+1. Get Existing CoreDNS-custom YAML in your cluster (save it on your local for reference later)::
 
    ```azurecli-interactive
    kubectl get configmap coredns-custom -n kube-system -o yaml
    ```
 
-2. To override mapping for *Central US DP* endpoint to public IP (download the YAML file attached), run the following command:
+2. Override mapping for centralus DP endpoint to Public IP (use the below YAML):
+   
+    ```yaml
+    apiVersion: v1
+    kind: ConfigMap
+    metadata:
+      name: coredns-custom 
+      namespace: kube-system
+    data:
+        aksdp.override: |
+              hosts { 
+                  20.40.200.153 centralus.dp.kubernetesconfiguration.azure.com
+                  fallthrough
+               }
+    ``` 
+    Now run the below command to apply the update yaml file:
 
    ```azurecli-interactive
    kubectl apply -f corednsms.yaml
@@ -200,7 +215,7 @@ These error codes appear due to issues based on the Backup extension installed i
 
 **Cause**: During extension installation, a Backup Storage Location is to be provided as input that includes a storage account and blob container. The Backup extension should have *Storage Blob Data Contributor* role on the Backup Storage Location (storage account). The Extension Identity gets this role assigned.
 
-**Recommended action**: The error appears if the Extension Identity doesn't have right permissions to access the storage account. This  error appears if AKS backup extension is installed the first time when configuring protection operation. This happens for the time taken for the granted permissions to propagate to the AKS backup extension. As a workaround, wait an hour and retry the protection configuration. Otherwise, use Azure portal or CLI to reassign this missing permission on the storage account.
+**Recommended action**: The error appears if the Extension Identity doesn't have right permissions to access the storage account. This error appears if AKS backup extension is installed the first time when configuring protection operation. This happens for the time taken for the granted permissions to propagate to the AKS backup extension. As a workaround, wait an hour and retry the protection configuration. Otherwise, use Azure portal or CLI to reassign this missing permission on the storage account.
 
 ## Vaulted backup based errors
 
@@ -238,7 +253,7 @@ This error code can appear while you enable AKS backup to store backups in a vau
 
 **Cause**: There is a limited number of snapshots for a Persistent Volume that can exist at a point-in-time. For Azure Disk-based Persistent Volumes, the limit is *500 snapshots*. This error appears when snapshots for specific Persistent Volumes aren't taken due to existence of snapshots higher than the supported limits.
 
-**Recommended action**: Update the Backup Policy to reduce the retention duration and wait for older recovery points to be deleted by the Backup vault.
+**Recommended action**: Update the Backup Policy to reduce the retention duration and wait for Backup Vault to delete the older recovery points.
 
 ### CSISnapshottingTimedOut
 
@@ -268,15 +283,15 @@ This error code can appear while you enable AKS backup to store backups in a vau
 
 **Error code**: UserErrorPVCHasNoVolume
 
-**Cause**: The Persistent Volume Claim (PVC) in context does not have a Persistent Volume attached to it. So, the PVC will not be backed up.
+**Cause**: The Persistent Volume Claim (PVC) in context doesn't have a Persistent Volume attached to it. So, the PVC won't be backed up.
 
 **Recommended action**: Attach a volume to the PVC, if it needs to be backed up.
 
 ### UserErrorPVCNotBoundToVolume
 
 **Error code**: UserErrorPVCNotBoundToVolume
 
-**Cause**: The PVC in context is in *Pending* state and doesn't have a Persistent Volume attached to it. So, the PVC will not be backed up. 
+**Cause**: The PVC in context is in *Pending* state and doesn't have a Persistent Volume attached to it. So, the PVC won't be backed up. 
 
 **Recommended action**: Attach a volume to the PVC, if it needs to be backed up.
 

articles/backup/azure-kubernetes-service-cluster-backup-support-matrix.md

@@ -35,7 +35,7 @@ You can use [Azure Backup](./backup-overview.md) to help protect Azure Kubernete
 
 - AKS backups don't support in-tree volumes. You can back up only CSI driver-based volumes. You can [migrate from tree volumes to CSI driver-based persistent volumes](../aks/csi-migrate-in-tree-volumes.md).
 
-- Currently, an AKS backup supports only the backup of Azure disk-based persistent volumes (enabled by the CSI driver). Both static and dynamically provisioned volumes are supported. For backup of static disks, the persistent volumes specification should have the *storage class* defined in the **YAML** file, otherwise such persistent volumes will be skipped from the backup operation.
+- Currently, an AKS backup supports only the backup of Azure disk-based persistent volumes (enabled by the CSI driver). The supported Azure Disk SKUs are Standard HDD, Standard SSD, and Premium SSD. The disks belonging to Premium SSD v2 and Ultra Disk SKU are not supported. Both static and dynamically provisioned volumes are supported. For backup of static disks, the persistent volumes specification should have the *storage class* defined in the **YAML** file, otherwise such persistent volumes will be skipped from the backup operation.
 
 - Azure Files shares and Azure Blob Storage persistent volumes are currently not supported by AKS backup due to lack of CSI Driver-based snapshotting capability. If you're using said persistent volumes in your AKS clusters, you can configure backups for them via the Azure Backup solutions. For more information, see [Azure file share backup](azure-file-share-backup-overview.md) and [Azure Blob Storage backup](blob-backup-overview.md).
 
@@ -47,7 +47,7 @@ You can use [Azure Backup](./backup-overview.md) to help protect Azure Kubernete
 
 - You must install the backup extension in the AKS cluster. If you're using Azure CLI to install the backup extension, ensure that the version is 2.41 or later. Use `az upgrade` command to upgrade the Azure CLI.
 
-- The blob container provided as input during installation of the backup extension should be in the same region and subscription as that of the AKS cluster.
+- The blob container provided as input during installation of the backup extension should be in the same region and subscription as that of the AKS cluster. Only blob containers in a General-purpose V2 Storage Account are supported and Premium Storage Account are not supported.   
 
 - The Backup vault and the AKS cluster should be in the same region and subscription.
 

articles/backup/azure-kubernetes-service-cluster-restore-using-powershell.md

@@ -22,15 +22,39 @@ You can perform both *Original-Location Recovery (OLR)* (restoring in the AKS cl
 >[!Note]
 >Before you initiate a restore operation, the target cluster should have Backup Extension installed and Trusted Access enabled for the Backup vault. [Learn more](azure-kubernetes-service-cluster-backup-using-powershell.md#prepare-aks-cluster-for-backup).
 
-Here, we've used an existing Backup vault *TestBkpVault*, under the resource group *testBkpVaultRG*, in the examples.
+Initialize the variables with required details related to each resource to be used in commands:
 
-```azurepowershell
-$TestBkpVault = Get-AzDataProtectionBackupVault -VaultName TestBkpVault -ResourceGroupName "testBkpVaultRG"
-```
+- Subscription ID of the Backup Vault
+
+    ```azurepowershell
+    $vaultSubId = "xxxxxxxx-xxxx-xxxx-xxxx"
+    ```
+- Resource Group to which Backup Vault belongs to
+
+    ```azurepowershell
+    $vaultRgName = "testBkpVaultRG"
+    ```
+
+- Name of the Backup Vault
+
+    ```azurepowershell
+    $vaultName = "TestBkpVault"
+    ```
+- Region to which the Backup Vault belongs to
+
+    ```azurepowershell
+    $restoreLocation = "vaultRegion" #example eastus
+    ```
+
+- ID of the target AKS cluster, in case the restore will be performed to an alternate AKS cluster
+
+    ```azurepowershell
+    $targetAKSClusterId = "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx/resourceGroups/targetrg/providers/Microsoft.ContainerService/managedClusters/PSAKSCluster2"
+    ```
 
 ## Before you start
 
-- AKS backup allows you to restore to original AKS cluster (that was backed up) and to an alternate AKS cluster. AKS backup allows you to perform a full restore and item-level restore. You can utilize [restore configurations](#restore-to-an-aks-cluster) to define parameters based on the cluster resources that will be picked up during the restore.
+- AKS backup allows you to restore to original AKS cluster (that was backed up) and to an alternate AKS cluster. AKS backup allows you to perform a full restore and item-level restore. You can utilize [restore configurations](#restore-to-an-aks-cluster) to define parameters based on the cluster resources that will be restored.
 
 - You must [install the Backup Extension](azure-kubernetes-service-cluster-manage-backups.md#install-backup-extension) in the target AKS cluster. Also, you must [enable Trusted Access](azure-kubernetes-service-cluster-manage-backups.md#register-the-trusted-access) between the Backup vault and the AKS cluster.
 
@@ -43,29 +67,23 @@ For more information on the limitations and supported scenarios, see the [suppor
 Fetch all instances using the `Get-AzDataProtectionBackupInstance` cmdlet and identify the relevant instance.
 
 ```azurepowershell
-$AllInstances = Get-AzDataProtectionBackupInstance -ResourceGroupName "testBkpVaultRG" -VaultName $TestBkpVault.Name
+$AllInstances = Get-AzDataProtectionBackupInstance -ResourceGroupName $vaultRgName -VaultName $vaultName
 ```
 
 You can also use `Az.Resourcegraph` and `Search-AzDataProtectionBackupInstanceInAzGraph` cmdlets to search across instances in multiple vaults and subscriptions.
 
 ```azurepowershell
-$AllInstances = Search-AzDataProtectionBackupInstanceInAzGraph -ResourceGroupName "testBkpVaultRG" -VaultName $TestBkpVault.Name -DatasourceType AzureKubernetesService  -ProtectionStatus ProtectionConfigured
+$AllInstances = Search-AzDataProtectionBackupInstanceInAzGraph -Subscription $vaultSubId -ResourceGroup $vaultRgName -Vault $vaultName -DatasourceType AzureKubernetesService  -ProtectionStatus ProtectionConfigured
 ```
 
-Once the instance is identified, fetch the relevant recovery point.
+Once the instance is identified, fetch the relevant recovery point. Supposedly, from the output array of the above command, third backup instance is to be restored.
 
 ```azurepowershell
-$rp = Get-AzDataProtectionRecoveryPoint -ResourceGroupName "testBkpVaultRG" -VaultName $TestBkpVault.Name -BackupInstanceName $AllInstances[2].BackupInstanceName
+$rp = Get-AzDataProtectionRecoveryPoint -ResourceGroupName $vaultRgName -VaultName $vaultName -BackupInstanceName $AllInstances[2].BackupInstanceName
 ```
 
 ### Prepare the restore request
 
-Get the Azure Resource Manager ID of the AKS cluster where you want to perform the restore operation.
-
-```azurepowershell
-$targetAKSClusterd = /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx/resourceGroups/targetrg/providers/Microsoft.ContainerService/managedClusters/PSAKSCluster2
-```
-
 Use the `New-AzDataProtectionRestoreConfigurationClientObject` cmdlet to prepare the restore configuration and defining the items to be restored to the target AKS cluster.
 
 ```azurepowershell
@@ -74,16 +92,23 @@ $aksRestoreCriteria = New-AzDataProtectionRestoreConfigurationClientObject -Data
 
 Then, use the `Initialize-AzDataProtectionRestoreRequest` cmdlet to prepare the restore request with all relevant details.
 
+In case you want to perform restore to the original AKS cluster backedup, use the below format for the cmdlet
+
+```azurepowershell
+$aksRestoreRequest = Initialize-AzDataProtectionRestoreRequest -DatasourceType AzureKubernetesService  -SourceDataStore OperationalStore -RestoreLocation $restoreLocation -RestoreType OriginalLocation -RecoveryPoint $rp[0].Property.RecoveryPointId -RestoreConfiguration $aksRestoreCriteria -BackupInstance $AllInstances[2]
+```
+In case you want to perform restore to an alternate AKS cluster, use the below format for the cmdlet
+
 ```azurepowershell
-$aksRestoreRequest = Initialize-AzDataProtectionRestoreRequest -DatasourceType AzureKubernetesService  -SourceDataStore OperationalStore -RestoreLocation $dataSourceLocation -RestoreType OriginalLocation -RecoveryPoint $rps[0].Property.RecoveryPointId -RestoreConfiguration $aksRestoreCriteria -BackupInstance $backupInstance
+$aksRestoreRequest = Initialize-AzDataProtectionRestoreRequest -DatasourceType AzureKubernetesService  -SourceDataStore OperationalStore -RestoreLocation $restoreLocation -RestoreType AlternateLocation -TargetResourceId $targetAKSClusterId -RecoveryPoint $rp[0].Property.RecoveryPointId -RestoreConfiguration $aksRestoreCriteria -BackupInstance $AllInstances[2]
 ```
 
 ## Trigger the restore
 
 Before you trigger the restore operation, validate the restore request created earlier.
 
 ```azurepowershell
-$validateRestore = Test-AzDataProtectionBackupInstanceRestore -SubscriptionId $sub -ResourceGroupName $rgName -VaultName $vaultName -RestoreRequest $aksRestoreRequest -Name $backupInstance.BackupInstanceName
+$validateRestore = Test-AzDataProtectionBackupInstanceRestore -SubscriptionId $vaultSubId  -ResourceGroupName $vaultRgName -VaultName $vaultName -RestoreRequest $aksRestoreRequest -Name $AllInstances[2].BackupInstanceName
 ```
 
 >[!Note]
@@ -93,10 +118,10 @@ $validateRestore = Test-AzDataProtectionBackupInstanceRestore -SubscriptionId $s
 2. The *User Identity* attached with the Backup Extension should have *Storage Account Contributor* roles on the *storage account* where backups are stored. 
 3. The *Backup vault* should have a *Reader* role on the *Target AKS cluster* and *Snapshot Resource Group*.
 
-Now, use the `Start-AzDataProtectionBackupInstanceRestore` cmdlet to trigger the restore operation with the request prepared above.
+Now, use the `Start-AzDataProtectionBackupInstanceRestore` cmdlet to trigger the restore operation with the request prepared earlier.
 
 ```azurepowershell
-$restoreJob = Start-AzDataProtectionBackupInstanceRestore -SubscriptionId $sub -ResourceGroupName $rgName -VaultName $vaultName -BackupInstanceName $backupInstance.BackupInstanceName -Parameter $aksRestoreRequest
+$restoreJob = Start-AzDataProtectionBackupInstanceRestore -SubscriptionId $vaultSubId  -ResourceGroupName $vaultRgName -VaultName $vaultName -BackupInstanceName $AllInstances[2].BackupInstanceName -Parameter $aksRestoreRequest
 ```
 
 ## Tracking job
@@ -106,7 +131,7 @@ Track all the jobs using the `Get-AzDataProtectionJob` cmdlet. You can list all
 Use the `Search-AzDataProtectionJobInAzGraph` cmdlet to get the relevant job, which can be across any Backup vault.
 
 ```azurepowershell
-$job = Search-AzDataProtectionJobInAzGraph -Subscription $sub -ResourceGroupName "testBkpVaultRG" -Vault $TestBkpVault.Name -DatasourceType AzureDisk -Operation OnDemandBackup
+$job = Search-AzDataProtectionJobInAzGraph -Subscription -SubscriptionId $vaultSubId -ResourceGroup $vaultRgName -Vault $vaultName -DatasourceType AzureKubernetesService -Operation Restore
 ```
 
 ## Next steps