-
Notifications
You must be signed in to change notification settings - Fork 21.1k
/
backup-azure-files-faq.yml
310 lines (229 loc) · 22.1 KB
/
backup-azure-files-faq.yml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
### YamlMime:FAQ
metadata:
title: Back up Azure Files FAQ
description: In this article, discover answers to common questions about how to protect your Azure file shares with the Azure Backup service.
ms.date: 10/14/2022
ms.topic: faq
ms.service: backup
author: AbhishekMallick-MS
ms.author: v-abhmallick
title: Questions about backing up Azure Files
summary: |
This article answers common questions about backing up Azure Files. In some of the answers, there are links to the articles that have comprehensive information. You can also post questions about the Azure Backup service in the [Microsoft Q&A question page for discussion](/answers/topics/azure-backup.html).
To quickly scan the sections in this article, use the links to the right, under **In this article**.
sections:
- name: Configuring the backup job for Azure Files
questions:
- question: |
Why can't I see some of my Storage Accounts that I want to protect, which contain valid Azure file shares?
answer: |
Refer to the [Support Matrix for Azure file shares backup](azure-file-share-support-matrix.md) to ensure the storage account belongs to one of the supported storage account types. It's also possible the Storage Account you're looking for is already protected or registered with another Vault. [Unregister the storage account](manage-afs-backup.md#unregister-a-storage-account) from the vault to discover the Storage Account in other vaults for protection.
- question: |
Why can't I see some of my Azure file shares in the Storage Account when I'm trying to configure backup?
answer: |
Check if the Azure file share is already protected in the same Recovery Services vault or if it has been deleted recently.
- question: |
Why is it recommended to enable lock on the storage account?
answer: |
The current Azure Files backup solution keeps snapshots in the same storage account as the backed-up file share. If the storage account gets deleted, you'll lose all your snapshots. To protect your account against accidental deletion, Azure Backup takes a Delete lock on the storage account. It means authorized users can still read and modify a resource, but they can't delete it. The lock also restricts the deletion of any file share under the storage account. Hence, you get protection from the accidental deletion of both the storage account and files shares.
- question: |
Can I protect File Shares connected to a Sync Group in Azure File Sync?
answer: |
Yes. Protection of Azure File Shares connected to Sync Groups is enabled.
- question: |
When trying to back up file shares, I selected a Storage Account to discover the file shares in it. However, I didn't protect them. How do I protect these file shares with any other vault?
answer: |
When trying to back up, selecting a Storage Account to discover file shares within it registers the Storage Account with the vault from which this is done. If you choose to protect the file shares with a different vault, [unregister](manage-afs-backup.md#unregister-a-storage-account) the chosen Storage Account from this vault.
- question: |
Why can't I change the vault to configure backup for the file share?
answer: |
If the storage account is already registered with a vault or other file shares in the storage account are protected using a vault, you aren't given an option to change it. All file shares in a storage account can be protected only by the same vault. If you want to change the vault, you'll need to [stop protection for all file shares in the storage account](manage-afs-backup.md#stop-protection-on-a-file-share) from the connected vault, [unregister](manage-afs-backup.md#unregister-a-storage-account) the Storage Account, and then choose a different vault for protection.
- question: |
Can I change the Vault to which I back up my file shares?
answer: |
Yes. However, you'll need to [stop protection on the file share](manage-afs-backup.md#stop-protection-on-a-file-share) from the connected vault, [unregister](manage-afs-backup.md#unregister-a-storage-account) this Storage Account, and then protect it from a different vault.
- question: |
Can I protect two different file shares from the same Storage Account to different Vaults?
answer: |
No. All file shares in a Storage Account can be protected only by the same Vault.
- name: Backup
questions:
- question: |
What should I do if my backups start failing due to the maximum limit reached error?
answer: |
You can have up to 200 Snapshots for a file share at any point in time. The limit includes snapshots taken by Azure Backup as defined by your policy. If your backups start failing after reaching the limit, delete On-Demand snapshots for successful future backups.
- question: |
How's the total number of snapshots corresponding to a backup policy configuration calculated?
answer: |
The following table explains the snapshot count as per the backup policy configuration:
| Backup frequency | Retention period | Snapshot count |
| ---------------- | ---------------- | -------------- |
| **Daily** | Add the retention values configured for daily, weekly, monthly, and yearly backups. For example, you configure a backup policy with the following values: <br><br> - Daily retention: 30 days <br> - Weekly retention: 40 weeks <br> - Monthly retention: 4 months <br> - Yearly retention: 6 years | This corresponds to 80 snapshots (30+40+4+6).
| **Hourly** | There's a buffer allocated for any delay in pruning the expired snapshots. For example, you configure a backup policy with: <br><br> - Number of daily snapshots as per your schedule: 6 <br> - Daily retention: 30 days <br> - Monthly retention: 11 months <br> - Yearly retention: 8 years | Considering 1 day buffer for each daily snapshot, the daily retention of 30 days is considered as 31 days for each of the 6 daily snapshots. So, this configuration corresponds to 205 [(6X31)+11+8] snapshots.
- name: Restore
questions:
- question: |
Can I recover from a deleted Azure file share?
answer: |
If the file share is in the soft deleted state, you need to first undelete the file share to perform the restore operation. The undelete operation will bring the file share into the active state where you can restore to any point in time. To learn how to undelete your file share, visit [this link](../storage/files/storage-files-enable-soft-delete.md?tabs=azure-portal#restore-soft-deleted-file-share) or see the [Undelete File Share Script](./scripts/backup-powershell-script-undelete-file-share.md). If the file share is permanently deleted, you won't be able restore the contents and snapshots.
- question: |
Can I restore from backups if I stopped protection on an Azure file share?
answer: |
Yes. If you chose **Retain Backup Data** when you stopped protection, then you can restore from all existing restore points.
- question: |
What happens if I cancel an ongoing restore job?
answer: |
If an ongoing restore job is canceled, the restore process stops and all files restored before the cancellation, stay in configured destination (original or alternate location) without any rollbacks.
- question: |
Why can't I see a specific recovery point?
answer: |
If a recovery point isn't listed, it must have expired. We recommend you checking the retention configured in the backup policy to understand the retention duration for recovery points of your backed-up file share.
- name: Manage backup
questions:
- question: |
Can I use PowerShell to configure/manage/restore backups of Azure File shares?
answer: |
Yes. Refer to the detailed documentation [here](backup-azure-afs-automation.md).
- question: |
Why data transferred in MB is 0 for the backup jobs?
answer: |
In the current backup solution for Azure Files, no data is transferred to the vault, and snapshots are retained in the same storage account as the backed-up file share. So, the data transferred in MB is 0.
- question: |
Why Azure Files backups doesn't replicate based on the Storage Replication Type setting of the vault?
answer: |
The Storage Replication setting of the vault isn't relevant for Azure Files backup. This is because the current solution is snapshot-based and there's no data transferred to the vault. Snapshots are stored in the same storage account as the backed-up file share, and therefore replicated as per the replication setting of storage account.
- question: |
Can I access the snapshots taken by Azure Backups and mount them?
answer: |
All snapshots taken by Azure Backup can be accessed by viewing snapshots in the portal, PowerShell, or CLI. To learn more about Azure Files share snapshots, see [Overview of share snapshots for Azure Files](../storage/files/storage-snapshots-files.md).
- question: |
What happens after I move a backed-up file share to a different subscription?
answer: |
Once a file share is moved to a different subscription, it's considered as a new file share by Azure Backup. These are the recommended steps:
Scenario: Let's say you have a file share *FS1* in subscription *S1* and it's protected using the *V1* vault. Now you want to move your file share to subscription *S2*.
1. Move the desired storage account and file share (FS1) to the different subscription (S2).
2. In the V1 vault, trigger the stop protection with delete data operation for FS1.
3. Unregister the storage account hosting FS1 from the V1 vault.
4. Reconfigure backup for FS1, now moved to S2, with a vault (V2) in the S2 subscription.
Note that after reconfiguring backup with V2, the snapshots that were taken with V1 will no longer be managed by Azure Backup. So you'll have to delete those snapshots manually according to your requirements.
- question: |
Can I move my backed-up file share to a different resource group?
answer: |
Yes, you can move your backed-up file share to a different resource group. However, you'll need to reconfigure backup for the file share as it will be treated as a new resource by Azure Backup. Also, the snapshots that were created before the resource group move will no longer be managed by Azure backup. So you'll have to delete those snapshots manually according to your requirements.
- question: |
What is the maximum retention I can configure for backups?
answer: |
Refer to the [support matrix](azure-file-share-support-matrix.md) for details on maximum retention. Azure Backup does a real-time calculation of the number of snapshots when you enter the retention values while configuring backup policy. As soon as the number of snapshots corresponding to your defined retention values exceeds 200, the portal will show a warning requesting you to adjust your retention values. This is so you don’t exceed the limit of maximum number of snapshots supported by Azure Files for any file share at any point in time.
- question: |
What is the impact on existing recovery points and snapshots when I modify the Backup policy for an Azure file share to switch from “Daily Policy" to "GFS Policy”?
answer: |
When you modify a Daily backup policy to GFS policy (adding weekly/monthly/yearly retention), the behavior is as follows:
- **Retention**: If you're adding weekly/monthly/yearly retention as part of modifying the policy, all the future recovery points created as part of the scheduled backup will be tagged according to the new policy. All the existing recovery points will still be considered as daily recovery points and so won’t be tagged as weekly/monthly/yearly.
- **Snapshots and recovery points cleanup**:
- If daily retention is extended, the expiration date of the existing recovery points is updated according to the daily retention value configured in the new policy.
- If daily retention is reduced, the existing recovery points and snapshots are marked for deletion in the next cleanup run job according to the daily retention value configured in the new policy, and then deleted.
Here's an example of how this works:
**Existing Policy [P1]**
|Retention Type |Schedule |Retention |
|---------|---------|---------|
|Daily | Every day at 8 PM | 100 days |
**New Policy [Modified P1]**
| Retention Type | Schedule | Retention |
| -------------- | ------------------------------ | --------- |
| Daily | Every day at 9 PM | 50 days |
| Weekly | On Sunday at 9 PM | 3 weeks |
| Monthly | On Last Monday at 9 PM | 1 month |
| Yearly | In Jan on Third Sunday at 9 PM | 4 years |
**Impact**
1. The expiration date of existing recovery points will be adjusted according to the daily retention value of the new policy: that is, 50 days. So any recovery point that’s older than 50 days will be marked for deletion.
2. The existing recovery points won’t be tagged as weekly/monthly/yearly based on new policy.
3. All the future backups will be triggered according to the new schedule: that is, at 9 PM.
4. The expiration date of all future recovery points will be aligned with the new policy.
>[!NOTE]
>The policy changes will affect only the recovery points created as part of the scheduled backup job run. For on-demand backups, retention is determined by the **Retain Till** value specified at the time of taking backup.
- question: |
What is the impact on existing recovery points when I modify an existing GFS Policy?
answer: |
When a new policy is applied on file shares, all the future scheduled backups will be taken according to the schedule configured in the modified policy. The retention of all existing recovery points is aligned according to the new retention values configured. So, if the retention is extended, existing recovery points are marked to be retained according to the new policy. If the retention is reduced, they're marked for clean-up in the next cleanup job and then deleted.
Here's an example of how this works:
**Existing Policy [P2]**
| Retention Type | Schedule | Retention |
| -------------- | ------------------ | --------- |
| Daily | Every day at 8 PM | 50 days |
| Weekly | On Monday at 8 PM | 3 weeks |
**New Policy [Modified P2]**
| Retention Type | Schedule | Retention |
| -------------- | ---------------------- | --------- |
| Daily | Every day at 9 PM | 10 days |
| Weekly | On Monday at 9 PM | 2 weeks |
| Monthly | On Last Monday at 9 PM | 2 months |
**Impact of change**
1. The expiration date of existing daily recovery points will be aligned according to the new daily retention value (10 days). So any daily recovery point older than 10 days will be deleted.
2. The expiration date of existing weekly recovery points will be aligned according to the new weekly retention value (two weeks). So, any weekly recovery point older than two weeks will be deleted.
3. The monthly recovery points will only be created as part of future backups based on the new policy configuration.
4. The expiration date of all future recovery points will be aligned with the new policy.
>[!NOTE]
>The policy changes will affect only the recovery points created as part of the scheduled backup. For on-demand backups, retention is determined by the **Retain Till** value specified at the time of taking the backup.
- question: |
What does the duration attribute in Azure Files backup policy signify?
answer: |
The **duration** attribute helps to determine the timestamp for last backup of the day.
For example, if the **start time** is “x AM” and **duration** is “y hours”, the backups will be scheduled between “x AM” and (x AM + y hours) based on the **schedule** attribute defined in the policy. This attribute enables you to ensure backups are only triggered during your working hours when there are frequent update operations on file share contents; so, taking multiple snapshots will safeguard data from any accidental changes.
- question: |
How are the backups scheduled based on the attributes - start time, schedule, and duration?
answer: |
For example, you created a policy with the following configuration:
- **Start time**: 9 AM
- **Schedule**: Every 4 hours
- **Duration**: 12 hours
Based on these values, the backup window is calculated as 9 AM – (9 AM + 12 hours), that is, 9 AM – 9 PM. Therefore, all backups will be scheduled within this window.
The first backup of the day is triggered at the start time mentioned in the policy, that is, 9 AM, and the **schedule** determines the time difference between consecutive backups, that is, 4 hours. With this calculation, your backup schedule would be: 9 AM, 1 PM (9 AM + 4 hours), 5 PM (1 PM + 4 hours), and 9 PM (5 PM + 4 hours).
Since the end time of the backup window we calculated was 9 PM, no backup would be triggered after this time.
- question: |
Why am I getting the error “The selected configuration will trigger only 1 backup per day”?
answer: |
This error occurs if you specified a **schedule** that's greater than the **duration**. For example, you've configured **start time** as 9 AM, **schedule** as 6 hours, and **duration** as 4 hours. In this scenario, the only time when backup job can trigger is 9 AM, since the next backup time of 3 PM (9 AM + 6 hours) is outside the backup window: 9 AM – 1 PM (9 AM + 4 hours).
To fix this, we recommend you adjust your schedule or duration, or select **Daily** frequency instead of **Hourly**.
- question: |
Why am I getting the error “The selected configuration extends backup window to next day”?
answer: |
This error occurs if the backup window's **start time** and **end time**, determined based on the backup **schedule** and **duration**, falls on two different days.
For example, you configured a policy with the following parameters:
- **Schedule**: Every 4 hours
- **Start time**: 12 PM
- **Duration**: 15 hours
Based on this configuration, the backup window will be: 12 PM – 3 AM (12 PM + 15 hours). Since the start and end times are falling on two different days, we recommend you adjust the **start time** or **duration** to ensure they are on the same day.
Let’s assume, you change the start time to 6 AM in the above configuration. Now, the backup window will be 6 AM – 9 PM (6 AM + 15 hours). This is a supported configuration.
- question: |
What’s the impact on the existing recovery points when I switch from “Daily” to “Hourly” frequency?
answer: |
When you switch from **Daily** to **Hourly** frequency, the behavior is as follows:
- **Retention**: If you're adding weekly/monthly/yearly retention as part of modifying the policy, all the future recovery points created as part of the scheduled backup will be tagged according to the new policy. All the existing recovery points will still be considered as daily recovery points; so, they won’t be tagged as weekly/monthly/yearly.
- **Snapshots and recovery points cleanup**:
- If daily retention is extended, the expiration date of the existing daily recovery points is updated according to the daily retention value configured in the new policy.
- If daily retention is reduced, the existing daily recovery points and snapshots are marked for deletion in the next cleanup run job according to the daily retention value configured in the new policy, and then deleted.
- name: Lease snapshots
questions:
- question: |
Will the storage account deletion be blocked if there’s an active lease on the snapshots?
answer: |
No, the storage account deletion isn’t blocked by a lease on snapshots.
- question: |
What’s the recommended way to delete a backed-up file share with a lease on snapshots?
answer: |
We recommend you to perform the _stop protection with delete data_ operation on the backed-up file share. <br><br> After this operation, Azure Backup will release the lease and delete all snapshots. Then you can delete the file share.
- question: |
Does Azure Backup take the lease retroactively?
answer: |
No, Azure Backup only takes a lease on the snapshots that are taken after the release of this capability.
- question: |
Is the lease effective on snapshots in a file share undeleted from the soft delete state?
answer: |
No. If you delete a file share containing leased snapshots, the lease won’t be in place when the file share is undeleted.
- question: |
Can I configure different backup policies for file shares in a storage account?
answer: |
Yes, you can protect file shares in a storage account in the same Recovery Services vault with different backup policies.
additionalContent: |
## Next steps
- [Troubleshoot problems while backing up Azure file shares](troubleshoot-azure-files.md)