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
@@ -13,12 +13,72 @@ Before deploying a template, you might want to preview the changes that will hap
13
13
> [!NOTE]
14
14
> The what-if operation is currently in preview. To use it, you must [sign up for the preview](https://aka.ms/armtemplatepreviews). As a preview release, the results may sometimes show that a resource will change when actually no change will happen. We're working to reduce these issues, but we need your help. Please report these issues at [https://aka.ms/whatifissues](https://aka.ms/whatifissues).
15
15
16
-
You can use the what-if operation with the `New-AzDeploymentWhatIf`PowerShell command or the [Deployments - What If](/rest/api/resources/deployments/whatif)REST operation.
16
+
You can use the what-if operation with the PowerShell commands or REST API operations.
17
17
18
-
In PowerShell, the output looks like:
18
+
In PowerShell, the output includes color-coded results that help you see the different types of changes.
19
19
20
20
21
21
22
+
The text ouptput is:
23
+
24
+
```powershell
25
+
Resource and property changes are indicated with these symbols:
You can use either Azure PowerShell or Azure REST API for the what-if operation.
54
+
55
+
### Azure PowerShell
56
+
57
+
To see a preview of the changes before deploying a template, add the `-Whatif` switch parameter to the deployment command.
58
+
59
+
*`New-AzResourceGroupDeployment -Whatif` for resource group deployments
60
+
*`New-AzSubscriptionDeployment -Whatif` and `New-AzDeployment -Whatif` for subscription level deployments
61
+
62
+
Or, you can use the `-Confirm` switch parameter to preview the changes and get prompted to continue with the deployment.
63
+
64
+
*`New-AzResourceGroupDeployment -Confirm` for resource group deployments
65
+
*`New-AzSubscriptionDeployment -Confirm` and `New-AzDeployment -Confirm` for subscription level deployments
66
+
67
+
The preceding commands return a text summary that you can manually inspect. To get an object that you can programmatically inspect for changes, use:
68
+
69
+
*`$results = Get-AzResourceGroupDeploymentWhatIf` for resource group deployments
70
+
*`$results = Get-AzSubscriptionDeploymentWhatIf` or `$results = Get-AzDeploymentWhatIf` for subscription level deployments
71
+
72
+
> [!NOTE]
73
+
> Prior to the release of version 2.0.1-alpha5, you used the `New-AzDeploymentWhatIf` command. This command has been replaced by the `Get-AzDeploymentWhatIf`, `Get-AzResourceGroupDeploymentWhatIf`, and `Get-AzSubscriptionDeploymentWhatIf` commands. If you've used an earlier version, you need to update that syntax. The `-ScopeType` parameter has been removed.
74
+
75
+
### Azure REST API
76
+
77
+
For REST API, use:
78
+
79
+
*[Deployments - What If](/rest/api/resources/deployments/whatif) for resource group deployments
80
+
*[Deployments - What If At Subscription Scope](/rest/api/resources/deployments/whatifatsubscriptionscope) for subscription level deployments
81
+
22
82
## Change types
23
83
24
84
The what-if operation lists six different types of changes:
@@ -35,84 +95,191 @@ The what-if operation lists six different types of changes:
35
95
36
96
-**Deploy**: The resource exists, and is defined in the template. The resource will be redeployed. The properties of the resource may or may not change. The operation returns this change type when it doesn't have enough information to determine if any properties will change. You only see this condition when [ResultFormat](#result-format) is set to `ResourceIdOnly`.
37
97
38
-
## Deployment scope
98
+
## Result format
99
+
100
+
You can control the level of detail that is returned about the predicted changes. In the deployment commands (`New-Az*Deployment`), use the **-WhatIfResultFormat** parameter. In the programmatic object commands (`Get-Az*DeploymentWhatIf`), use the **ResultFormat** parameter.
39
101
40
-
You can use the what-if operation for deployments at either the subscription or resource group level. You set the deployment scope with the `-ScopeType` parameter. The accepted values are `Subscription` and `ResourceGroup`. This article demonstrates resource group deployments.
102
+
Set the format parameter to **FullResourcePayloads** to get a list of resources that will change and details about the properties that will change. Set the format parameter to **ResourceIdOnly** to get a list of resources that will change. The default value is **FullResourcePayloads**.
41
103
42
-
To learn about subscription level deployments, see [Create resource groups and resources at the subscription level](deploy-to-subscription.md#).
104
+
The following results show the two different output formats:
43
105
44
-
## Result format
106
+
- Full resource payloads
45
107
46
-
You can control the level of detail that is returned about the predicted changes. Set the `ResultFormat` parameter to `FullResourcePayloads` to get a list of resources what will change and details about the properties that will change. Set the `ResultFormat` parameter to `ResourceIdOnly` to get a list of resources that will change. The default value is `FullResourcePayloads`.
108
+
```powershell
109
+
Resource and property changes are indicated with these symbols:
110
+
- Delete
111
+
+ Create
112
+
~ Modify
47
113
48
-
The following screenshots show the two different output formats:
To see how what-if works, let's runs some tests. First, deploy a template from [Azure Quickstart templates that creates a storage account](https://github.com/Azure/azure-quickstart-templates/blob/master/101-storage-account-create/azuredeploy.json). The default storage account type is `Standard_LRS`. You'll use this storage account to test how changes are reported by what-if.
154
+
To see how what-if works, let's runs some tests. First, deploy a [template that creates a virtual network](https://github.com/Azure/azure-docs-json-samples/blob/master/azure-resource-manager/what-if/what-if-before.json). You'll use this virtual network to test how changes are reported by what-if.
After the deployment completes, you're ready to test the what-if operation. Run the what-if command but change the storage account type to `Standard_GRS`.
167
+
After the deployment completes, you're ready to test the what-if operation. This time deploy a [template that changes the virtual network](https://github.com/Azure/azure-docs-json-samples/blob/master/azure-resource-manager/what-if/what-if-after.json). It is missing one the original tags, a subnet has been removed, and the address prefix has changed.
Notice at the top of the output that colors are defined to indicate the type of changes.
90
210
91
-
At the bottom of the output, it shows the sku name (storage account type) will be changed from **Standard_LRS** to **Standard_GRS**.
211
+
At the bottom of the output, it shows the tag Owner was deleted. The address prefix changed from 10.0.0.0/16 to 10.0.0.0/15. The subnet named subnet001 was deleted. Remember this changes weren't actually deployed. You see a preview of the changes that will happen if you deploy the template.
212
+
213
+
Some of the properties that are listed as deleted won't actually change. Properties can be incorrectly reported as deleted when they aren't in the template, but are automatically set during deployment as default values. This result is considered "noise" in the what-if response. The final deployed resource will have the values set for the properties. As the what-if operation matures, these properties will be filtered out of the result.
214
+
215
+
## Programmatically evaluate what-if results
216
+
217
+
Now, let's programmatically evaluate the what-if results by setting the command to a variable.
92
218
93
-
Some of the properties that are listed as deleted won't actually change. In the preceding image, these properties are accessTier, encryption.keySource and others in that section. Properties can be incorrectly reported as deleted when they aren't in the template, but are automatically set during deployment as default values. This result is considered "noise" in the what-if response. The final deployed resource will have the values set for the properties. As the what-if operation matures, these properties will be filtered out of the result.
The what-if operation supports using [deployment mode](deployment-modes.md). When set to complete mode, resources not in the template are deleted. The following example deploys a [template that has no resources defined](https://github.com/Azure/azure-docs-json-samples/blob/master/empty-template/azuredeploy.json) in complete mode.
98
237
99
-
```azurepowershell-interactive
100
-
New-AzDeploymentWhatIf `
101
-
-ScopeType ResourceGroup `
238
+
To preview changes before deploying a template, use the `-Confirm` switch parameter with the deployment command. If the changes are as you expected, confirm that you want the deployment to complete.
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "Y"):
277
+
```
278
+
279
+
You see the expected changes and can confirm that you want the deployment to run.
112
280
113
281
## Next steps
114
282
115
283
- If you notice incorrect results from the preview release of what-if, please report the issues at [https://aka.ms/whatifissues](https://aka.ms/whatifissues).
116
284
- To deploy templates with Azure PowerShell, see [Deploy resources with Resource Manager templates and Azure PowerShell](deploy-powershell.md).
117
285
- To deploy templates with REST, see [Deploy resources with Resource Manager templates and Resource Manager REST API](deploy-rest.md).
118
-
- To roll back to a successful deployment when you get an error, see [Rollback on error to successful deployment](rollback-on-error.md).
description: Learn how to back up Azure file shares in the Recovery Services vault
4
+
ms.topic: conceptual
5
+
ms.date: 03/05/2020
6
+
---
7
+
8
+
# About Azure file share backup
9
+
10
+
Azure file share backup is a native, cloud based backup solution that protects your data in the cloud and eliminates additional maintenance overheads involved in on-premises backup solutions. The Azure Backup service smoothly integrates with Azure file sync, and allows you to centralize your file share data as well as your backups. This simple, reliable, and secure solution enables you to configure protection for your enterprise file shares in few simple steps with an assurance that you can recover your data in case of any disaster scenario.
11
+
12
+
## Key benefits of Azure file share backup
13
+
14
+
* Zero infrastructure: No deployment is needed to configure protection for your file shares.
15
+
* Built in management capabilities: You can schedule backups and specify the desired retention period without the additional overhead of data pruning.
16
+
* Instant restore: Azure file share backup uses file share snapshots, so you can select just the files you want to restore instantly.
17
+
* Alerting and reporting: You can configure alerts for backup and restore failures and use the reporting solution provided by Azure Backup to get insights on backups across your files shares.
1. The first step in configuring backup for Azure File shares is creating a recovery services vault. The vault gives you a consolidated view of the backups configured across different workloads.
26
+
27
+
2. Once you create a vault, the Azure Backup service discovers the storage accounts that can be registered with the vault. You can select the storage account hosting the file shares you want to protect.
28
+
29
+
3. After you select the storage account, the Azure Backup service lists the set of file shares present in the storage account and stores their names in the management layer catalog.
30
+
31
+
4. You then configure the backup policy (schedule and retention) according to your requirements, and select the file shares to back up. The Azure Backup service registers the schedules in the control plane to do scheduled backups.
32
+
33
+
5. Based on the policy specified, the Azure Backup scheduler triggers backups at the scheduled time. As part of that job, the file share snapshot is created using the File share API. Only the snapshot URL is stored in the metadata store.
34
+
35
+
>[!NOTE]
36
+
>The file share data is not transferred to the Backup service, since the Backup service creates and manages snapshots that are part of your storage account.
37
+
38
+
6. You can restore the Azure file share contents (individual files or the full share) from snapshots available on the source file share. Once the operation is triggered, the snapshot URL is retrieved from the metadata store and the data is listed and transferred from the source snapshot to the target file share of your choice.
39
+
40
+
7. The backup and restore job monitoring data is pushed to the Azure Backup Monitoring service. This allows you to monitor cloud backups for your file shares in a single dashboard. In addition, you can also configure alerts or email notifications when backup health is affected. Emails are sent via the Azure email service.
41
+
42
+
## Next steps
43
+
44
+
* Learn how to [Back up Azure file shares](backup-afs.md)
45
+
* Find answers to [Questions about backing up Azure Files](backup-azure-files-faq.md)
0 commit comments