Frequently asked questions about backing up Azure Files

Refer to the Support Matrix for Azure file shares backup 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 from the vault to discover the Storage Account in other vaults for protection.

Check if the Azure file share is already protected in the same Recovery Services vault or if it has been deleted recently.

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.

Yes. Protection of Azure File Shares connected to Sync Groups is enabled.

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 the chosen Storage Account from this vault.

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 from the connected vault, unregister the Storage Account, and then choose a different vault for protection.

Yes. However, you'll need to stop protection on the file share from the connected vault, unregister this Storage Account, and then protect it from a different vault.

No. All file shares in a Storage Account can be protected only by the same Vault.

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.

The following table explains the snapshot count as per the backup policy configuration:

If the file share is in the soft deleted state, you need to first undelete the file share to perform the restore operation. 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 or see the Undelete File Share Script. If the file share is permanently deleted, you won't be able restore the contents and snapshots.

Yes. If you chose Retain Backup Data when you stopped protection, then you can restore from all existing restore points.

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.

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.

Yes. Refer to the detailed documentation here.

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.

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.

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.

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.

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.

Refer to the support matrix 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.

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 clean up:

  • 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]

New Policy [Modified P1]

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.

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]

New Policy [Modified P2]

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.

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.

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.

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.

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.

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 clean up:

  • 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.

Expiry Time of recovery points are updated when Garbage Collector (GC) runs, which is every 24 hours. After you update the backup policy, it can take up to 24 hours to show the updates in the Expiry Time, if there're no delays in GC jobs.

When both snapshot and vaulted backups are configured, the expiry date initially reflects the retention period of the snapshot backup. After the snapshot backup expires, the expiry date will update to reflect the retention period of the vaulted backup.

No, the storage account deletion isn’t blocked by a lease on snapshots.

We recommend you to perform the stop protection with delete data operation on the backed-up file share.

After this operation, Azure Backup will release the lease and delete all snapshots. Then you can delete the file share.

No, Azure Backup only takes a lease on the snapshots that are taken after the release of this capability.

No. If you delete a file share containing leased snapshots, the lease won’t be in place when the file share is undeleted.

Yes, you can protect file shares in a storage account in the same Recovery Services vault with different backup policies.

Next steps

• Troubleshoot problems while backing up Azure file shares