Επεξεργασία

Κοινή χρήση μέσω


Questions about backing up Azure Files

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.

To quickly scan the sections in this article, use the links to the right, under In this article.

Configuring the backup job for Azure Files

Why can't I see some of my Storage Accounts that I want to protect, which contain valid Azure file shares?

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.

Why can't I see some of my Azure file shares in the Storage Account when I'm trying to configure backup?

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.

Can I protect File Shares connected to a Sync Group in Azure File Sync?

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

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?

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.

Why can't I change the vault to configure backup for the file share?

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.

Can I change the Vault to which I back up my file shares?

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.

Can I protect two different file shares from the same Storage Account to different Vaults?

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

Backup

What should I do if my backups start failing due to the maximum limit reached error?

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.

How's the total number of snapshots corresponding to a backup policy configuration calculated?

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:

- Daily retention: 30 days
- Weekly retention: 40 weeks
- Monthly retention: 4 months
- 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:

- Number of daily snapshots as per your schedule: 6
- Daily retention: 30 days
- Monthly retention: 11 months
- 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.

Restore

Can I recover from a deleted Azure file share?

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 or see the Undelete File Share Script. If the file share is permanently deleted, you won't be able restore the contents and snapshots.

Can I restore from backups if I stopped protection on an Azure file share?

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

What happens if I cancel an ongoing restore job?

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.

Why can't I see a specific recovery point?

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.

Manage backup

Can I use PowerShell to configure/manage/restore backups of Azure File shares?

Yes. Refer to the detailed documentation here.

Why data transferred in MB is 0 for the backup jobs?

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.

Why Azure Files backups doesn't replicate based on the Storage Replication Type setting of the vault?

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.

Can I access the snapshots taken by Azure Backups and mount them?

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.

What happens after I move a backed-up file share to a different subscription?

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.

Can I move my backed-up file share to a different resource group?

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.

What is the maximum retention I can configure for backups?

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.

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”?

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.

What is the impact on existing recovery points when I modify an existing GFS 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]

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.

What does the duration attribute in Azure Files backup policy signify?

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.

How are the backups scheduled based on the attributes - start time, schedule, and duration?

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.

Why am I getting the error “The selected configuration will trigger only 1 backup per day”?

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.

Why am I getting the error “The selected configuration extends backup window to next day”?

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.

What’s the impact on the existing recovery points when I switch from “Daily” to “Hourly” frequency?

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.

Lease snapshots

Will the storage account deletion be blocked if there’s an active lease on the snapshots?

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.

Does Azure Backup take the lease retroactively?

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

Is the lease effective on snapshots in a file share undeleted from the soft delete state?

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

Can I configure different backup policies for file shares in a storage account?

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