You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/backup/azure-kubernetes-service-cluster-restore-using-cli.md
+25-1Lines changed: 25 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -162,6 +162,8 @@ The restore configuration is composed of following items:
162
162
163
163
-`namespace_mappings`: You can map namespace (and underlying resources) to a different namespace in the target cluster. If the target namespace doesn't exist in the cluster, then a new namespace is created by the extension. The input value should be provided as key value pair.
164
164
165
+
-`object_type`: This variable specifies whether the restore configuration is intended for a recovery point stored in the Operational Tier or the Vault Tier. If the recovery point is in the Operational Tier, set the value to **KubernetesClusterRestoreCriteria**. If the recovery point is in the Vault Tier or being restored to a secondary region, set the value to **KubernetesClusterVaultTierRestoreCriteria**.
166
+
165
167
-`persistent_volume_restore_mode`: You can use this variable to decide whether you would like to restore the persistent volumes backed up or not. Accepted values are RestoreWithVolumeData, RestoreWithoutVolumeData
166
168
167
169
-`resource_modifier_reference`: You can refer the Resource Modifier resource deployed in the cluster with this variable. The input value is a key value pair of the Namespace in which the resource is deployed and the name of the yaml file.
@@ -172,6 +174,8 @@ The restore configuration is composed of following items:
172
174
173
175
-`staging_storage_account_id`: In case you're restoring backup stored in the **vault tier**, you need to provide an ID of storage account as a staging location. In this resource group, the backed up kubernetes resources are hydrated before being restored to the target cluster.
174
176
177
+
178
+
175
179
Now, prepare the restore request with all relevant details. If you're restoring the backup to the original cluster, then run the following command:
176
180
177
181
```azurecli
@@ -185,6 +189,13 @@ If the Target AKS cluster for restore is different from the original cluster, th
> In case you have picked a recovery point from vault tier with `--source-datastore` as VaultStore then provide a storage account and snapshot resource group in restore configuration.
@@ -197,6 +208,13 @@ Now, you can update the JSON object as per your requirements, and then validate
This command checks if the AKS Cluster and Backup vault have the required roles on different resource needed to perform restore. If the validation fails due to missing roles, you can assign them by running the following command:
202
220
@@ -212,7 +230,7 @@ az dataprotection backup-instance update-msi-permissions --datasource-type Azure
212
230
> - The *User Identity* attached with the Backup Extension should have *Storage Blob Data Contributor* roles on the *storage account* where backups are stored in case of Operational Tier and on the **staging storage account* in case of Vault Tier.
213
231
> - The *Backup vault* should have a *Reader* role on the *Target AKS cluster* and *Snapshot Resource Group* in case of restoring from Operational Tier.
214
232
> - The *Backup vault* should have a *Contributor* role on the *Staging Resource Group* in case of restoring backup from Vault Tier.
215
-
> - The *Backup vault* should have a *Storage Account Contributor* and *Storage Blob Data Owner* role on the *Staging Resource Group* in case of restoring backup from Vault Tier.
233
+
> - The *Backup vault* should have a *Storage Account Contributor* and *Storage Blob Data Owner* role on the *Staging Storage Account* in case of restoring backup from Vault Tier.
216
234
217
235
## Trigger the restore
218
236
@@ -221,6 +239,12 @@ Once the role assignment is complete, you should validate the restore object onc
221
239
```azurecli
222
240
az dataprotection backup-instance restore trigger --backup-instance-name $backupinstancename --restore-request-object restorerequestobject.json
223
241
```
242
+
If the target cluster is in secondary region then use the flag `--use-secondary-region`.
>The resources hydrated in the staging resource group and storage account are not automatically cleaned up after the restore job is completed and are to be deleted manually.
Copy file name to clipboardExpand all lines: articles/backup/backup-vault-overview.md
+12Lines changed: 12 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -39,6 +39,18 @@ Azure Backup provides you two options (**Microsoft managed keys** and **Customer
39
39
40
40
You can fetch your own keys to encrypt the backup data by using the **Customer Managed Keys** option under **Encryption settings** on the *Backup vault*.
41
41
42
+
### Role-Based Access Control (RBAC) in Backup vault
43
+
44
+
Backup vaults provide a robust Role-Based Access Control (RBAC) mechanism that not only governs who can access a Backup vault and what operations they can perform, but also enables fine-grained control over which individual workloads the vault can access and to what extent. This includes access to Azure resources such as Azure Disks or PostgreSQL servers to be backed up and Key Vaults used for encryption key management.
45
+
46
+
RBAC is enforced through Managed Identities associated with the Backup vault. Specific roles can be assigned to these identities to grant the required access. Backup vaults support two types of managed identities:
47
+
48
+
-**System Assigned Managed Identity:** This identity is automatically created when the Backup vault is provisioned and is tied to the lifecycle of the vault. You have the option to disable this identity if needed.
49
+
50
+
-**User Assigned Managed Identity:** This is an independent Azure resource that can be assigned to one or more Backup vaults. Once assigned, any roles granted to this identity apply to the vault as well. The lifecycle of a user-assigned managed identity is decoupled from the vault, providing greater flexibility. Multiple user-assigned identities can be associated with a single Backup vault.
51
+
52
+
These identities ensure secure and manageable access control, enabling Backup vaults to operate with the least privilege necessary while aligning with organizational security policies.
53
+
42
54
## Cross Region Restore support for PostgreSQL using Azure Backup
43
55
44
56
Azure Backup allows you to replicate your backups to an additional Azure paired region by using Geo-redundant Storage (GRS) to protect your backups from regional outages. When you enable the backups with GRS, the backups in the secondary region become accessible only when Microsoft declares an outage in the primary region. However, Cross Region Restore enables you to access and perform restores from the secondary region recovery points even when no outage occurs in the primary region; thus, enables you to perform drills to assess regional resiliency.
0 commit comments