In this article, we will share with you how to auto-protect Azure File Shares in Azure Backup, so you make sure that once a new file share(s) is created, Azure Backup will automatically protect your data in your Recovery Services vault.
With automated protection in place, you can focus on your business while ensuring the security and recoverability of your valuable data.
Table of Contents
Introduction
Azure Backup ensures your backup data is stored securely by leveraging the built-in security capabilities of the Azure platform role-based access control (RBAC) and encryption. In addition, with the new capabilities for soft-delete, Multi-User Authorization, and Immutable vault, Azure Backup protects against any accidental and malicious attempts to delete your backups.
With a powerful architecture built into Azure, Azure Backup does all this for you in a simple, secure, and cost-effective manner without needing you to worry about anything at all.
Azure File storage offers shared storage for applications using the standard SMB 3.0 protocol. Microsoft Azure virtual machines and cloud services like Azure Container Apps (ACA) and Azure Kubernetes Service (AKS) can share file data across application components via mounted shares, and on-premises applications can access file data in a share via the File storage API.
When you create a new Azure file share, you can protect your data in the share and enable backup for the short-term and/or long-term. This operation is done manually after the fact as described in this article.
In a previous article, we shared how to automate the backup for Azure File Shares using PowerShell, so you can schedule it to take snapshots at regular intervals every week, month, or year for long-term retention of up to 10 years.
A new corporate compliance policy requires that all data in the file shares must be auto-protected by Azure Backup and remains in the same Azure region. At the time of this writing, Microsoft does not have a native capability to achieve this requirement.
// Azure Automation to the rescue!
In this guide, we will describe how to auto-protect Azure File Shares that are created in your environment, so you don’t need to perform this task manually anymore!
Prerequisites
To follow this article, you need to have the following:
1) Azure subscription – If you don’t have an Azure subscription, you can create a free one here.
2) You need to have at least one Azure Recovery Services vault created. The vault must be in the same region as the storage account. Please check the following quick start guide to create and configure a Recovery Services vault.
3) You need to have at least one Azure Backup policy for Azure File Share. Check how to create an Azure Backup policy for Azure File Share using PowerShell.
4) You need to have at least one storage account in the same subscription and region of your Recovery Services vault. To create a General Purpose v2 (GPv2) storage account, you can follow the instructions described here.
Now an important point is, the snapshot (Backup) for Azure Files is stored within the same storage account. At the time of this writing, transferring (hardening) to Recovery Services Vault is NOT supported yet. Stay Tuned!
Assuming you have all the prerequisites in place, take now the following steps:
Get started
Before we get started, we want to mention that you can accomplish the same scenario using Azure Policy, but the easier way is configuring a PowerShell script via Runbook in Automation Accounts to detect the protectable file shares within a storage account and trigger configure backup for them.
First, we need to create an Azure automation resource with a Managed Identity. Microsoft recommends using Managed Identities for the Automation accounts instead of using Run As accounts. Managed identity would be more secure and offers ease of use since it doesn’t require any credentials to be stored. Azure Automation support for Managed Identities is now generally available.
Create Automation Account
When you create an Automation Account, it creates a new service principal in Azure Active Directory (Azure AD) by default. Next, you must assign the appropriate (Azure RBAC) role to allow access to the storage account and Azure Backup for the service principal at the subscription or the management group level.
In this example, we have assigned the Storage Account Contributor role to the managed identity at the management group level. Always keep in mind to use the principle of least privilege (PoLP) when assigning permissions. Please note that you need the following least privileged role-based access control (RBAC) Azure roles assigned for this solution to work:
1) Backup Operator – This role has permissions for everything a Backup Contributor does except removing backup and managing backup policies. You can assign this role at the resource group level where the Recovery Services vault is created.
2) Custom Role – This custom role will have access to the Microsoft storage account to list keys and update the properties with write permissions – You can assign this role at the resource group level where the storage account is created. Check the following article to learn how to create or update Azure custom roles using the Azure portal.
Once Azure Backup triggers and auto-configures backup for the file shares, a lock will be created in your storage account under the Locks page called “AzureBackupProtectionLock” with the Lock type “Delete“. This lock is intended to guard against the deletion of backups due to accidental deletion of the storage account.
> Microsoft.Storage/storageAccounts/listkeys/action: This permission will return the access keys for the specified storage account.
> Microsoft.Storage/storageAccounts/write: This permission will create a storage account with the specified parameters or update the properties or tags or adds a custom domain for the specified storage account.
Using a managed identity instead of the Automation Run As account makes management simpler. You don’t have to renew the certificate used by the Automation Run As account. Additionally, you don’t have to specify the Run As connection object in your runbook code. You can access resources using your Automation account’s managed identity from a runbook without creating certificates, connections, Run As accounts, etc.
Please note that Azure Automation Run As Account will retire on September 30, 2023, and will be replaced with Managed Identities.
Open the Azure portal, and click All services found in the upper left-hand corner. In the list of resources, type Automation. As you begin typing, the list filters based on your input. Select Automation Accounts.
Click +Add. Enter the automation account name, and choose the right subscription, resource group, and location. By default, a system-assigned managed identity is selected.
Then select Review + Create and click Create.
Az Modules
In your list of Automation Accounts, select the account you created in the previous step. Then from your Automation account, select Modules under Shared Resources.
The good news is that starting in September 2021, automation accounts will now have the Az modules installed by default. You don’t need to import the modules from the gallery as we used to do in the past. Please note that you can also update the modules to the latest Az version from the modules blade as shown in the figure below.
The most common PowerShell modules are provided by default in each Automation account. See the default modules imported on this page. As the Azure team updates the Azure modules regularly, changes can occur with the included cmdlets.
Create PowerShell Runbook
In this step, you can create multiple Runbooks based on which storage account you want to protect all of its Azure file shares. PowerShell Runbooks are based on Windows PowerShell. You directly edit the code of the Runbook using the text editor in the Azure portal. Or, you can also use any offline text editor such as Visual Studio Code, and import the Runbook into Azure Automation.
From your automation account, select Runbooks under Process Automation. Click the ‘+ Create a runbook‘ button to open the Create a runbook blade as shown in the figure below.
Please make sure to select the right runtime PowerShell version. In this example, the PowerShell modules (Az.Accounts, Az.Storage, and Az.RecoveryServices) targeting the 7.1 runtime version will be used.
In this example, we will create a Runbook to auto-protect all Azure File Shares in a specific storage account. You can also be creative as much as you want and cover multiple storage accounts across multiple subscriptions, the logic is the same.
Edit the Runbook
Once you have the Runbook created, you need to edit the Runbook, then write or add the script to choose which Azure file shares tiers you want to sync and move the files. Of course, you can create scripts that suit your environment.
As mentioned earlier, in this example, we will create a Runbook to check all Azure File Shares (existing and new file shares) for a specific storage account and verify if Azure Backup is enabled. If Azure Backup is not enabled, then the runbook will auto-protect the file share using the backup policy that you defined.
And to maintain a high level of security, we WON’T use the storage account keys. Instead, we will create a time-limit SAS token URI for Azure Files with Read and List permissions only, and the SAS token will expire automatically after 1 day. So, if you regenerate your storage account keys in the future, the automation process won’t break.
The automation runbook is as follows:
<#
.DESCRIPTION
A Runbook that continuously checks all Azure File Shares for a specific storage account and verifies if Azure Backup is enabled.
If Azure Backup is not enabled, then the runbook will auto-protect the file share using the backup policy you define.
.NOTES
Filename : AzureFileShare-AutoProtection
Author : Charbel Nemnom (Microsoft MVP/MCT)
Version : 1.0
Date : 11-July-2023
Updated : 11-July-2023
.LINK
To provide feedback or for further assistance please visit:
https://charbelnemnom.com
#>
Param (
[Parameter(Mandatory = $true)][ValidateNotNullOrEmpty()]
[String] $azureSubscriptionId,
[Parameter(Mandatory = $true)][ValidateNotNullOrEmpty()]
[String] $recoveryServicesVaultName,
[Parameter(Mandatory = $true)][ValidateNotNullOrEmpty()]
[String] $afsBackupPolicyName,
[Parameter(Mandatory = $true)][ValidateNotNullOrEmpty()]
[String] $storageAccountName
)
# Ensures you do not inherit an AzContext in your runbook
Disable-AzContextAutosave -Scope Process
# Connect to Azure with system-assigned managed identity (automation account)
Connect-AzAccount -Identity
# Set Azure Subscription context
Set-AzContext -Subscription $azureSubscriptionId
# Get Azure Storage Account details
$storageAccount = Get-AzStorageAccount | Where-Object { $_.StorageAccountName -eq $storageAccountName }
# Get Azure Source Storage Account Key
$storageAccountKey = (Get-AzStorageAccountKey -ResourceGroupName $storageAccount.ResourceGroupName -Name $StorageAccountName).Value[0]
# Set Azure Storage Context
$storageContext = New-AzStorageContext -StorageAccountKey $storageAccountKey -StorageAccountName $storageAccountName
# Generate file share SAS URI Token valid for 24 hours with Read and List permissions only
$shareSASURI = New-AzStorageAccountSASToken -Context $storageContext -Service File -ResourceType Service, Container, Object -ExpiryTime(get-date).AddDays(1) -Permission "rl"
$shareSASURI = $shareSASURI.Split('?')[-1]
# Get all Azure file shares for the storage account
Write-Output ("List all Azure file shares for the storage account: " + $storageAccountName)
$URI = "https://$storageAccountName.file.core.windows.net/?comp=list&$($shareSASURI)"
$response = Invoke-RestMethod $URI -Method 'GET'
# Fix XML Response body
$fixedXML = $response.Replace('<?xml version="1.0" encoding="utf-8"?>', '<?xml version=''1.0'' encoding=''UTF-8''?>')
$doc = New-Object xml
$doc = [xml]$fixedXML
if ($doc.FirstChild.NodeType -eq 'XmlDeclaration') {
$doc.FirstChild.Encoding = $null
}
# Store all Azure File Shares name in a variable
$azFileShares = $doc.EnumerationResults.shares.share.name
Write-Output ("Azure file shares name: " + $azFileShares)
# Loop accross all Azure File Shares and check if Azure Backup is enabled
foreach ($azFileShare in $azFileShares) {
Write-Output ("Working on FileShare: " + $azFileShare)
$shareProperties = Get-AzStorageShare -Name $azFileShare -Context $storageContext | Select-Object -Expand ShareProperties
if ($shareProperties.Metadata.AzureBackupProtected -eq "false") {
# Enable Azure Backup for the file share
Write-Output ("Enabling backup for FileShare: " + $azFileShare)
Get-AzRecoveryServicesVault -Name $recoveryServicesVaultName | Set-AzRecoveryServicesVaultContext
$afsPol = Get-AzRecoveryServicesBackupProtectionPolicy -Name $afsBackupPolicyName
Enable-AzRecoveryServicesBackupProtection -StorageAccountName $storageAccountName -Name $azFileShare -Policy $afsPol
}
else {
Write-Output ("Backup is already enabled for FileShare: " + $azFileShare)
}
Write-Output ("")
}Save the script in the CMDLETS pane as shown in the figure below.
Then test the runbook using the “Test pane” and fill in all the required parameters to verify it’s working as intended before you publish it.
On the Test page, you need to supply the following 8 parameters manually and then click the Start button to test the automation script.
- AZURESUBSCRIPTIONID
- RECOVERYSERVICESVAULTNAME
- AFSBACKUPPOLICYNAME
- STORAGEACCOUNTNAME
Once the test is completed successfully, you need to publish the Runbook by clicking Publish. This is a very important step.
Schedule the Runbook
In the final step, you need to schedule the Runbook to run based on the desired time that you want to check and auto-protect newly created Azure File Shares.
Within the same Runbook that you created in the previous step, select Schedules and then click + Add Schedule.
So, if you need to schedule the Runbook to run every 4 hours, then you need to create the following schedule with Recur every 4 Hours with Set expiration to No and then click “Create“. The minimum you can run the Runbook every 1 hour and you can also run it on-demand if you wish to do so.
While scheduling the Runbook, you need to enter the required parameters for the PowerShell script to run successfully. In this scenario, you need to specify the following 4 parameters:
- Azure Subscription ID where the storage account and the recovery services vault are created.
- Recovery Services Vault Name where you want to auto-protect Azure File Shares.
- Azure File Share Backup Policy Name which you want to associate with.
- Storage Account Name where the Azure file shares will be created.
The automation script takes those parameters as input as shown in the figure below.
Once done, click OK twice.
Test and monitor the Runbook
In this section, we will test the Runbook and request on-demand auto-protect for Azure File Shares instead of waiting for the schedule to kick in. This scenario simulates when an application or user creates a new Azure file share in a storage account.
Browse to the recently created Runbook, and on the Overview page click the “Start” button. Enter the required parameters as input and then click “OK“.
The job will kick in, now depending on your storage account and the number of file shares that you have, the job will take some time, in this example, it took around 4 minutes to complete. You will see the output and logs under the “Output” to verify that the copy job finished successfully as shown in the figure below.
You can also monitor the success or failure of these schedules using the “Jobs” page of Runbooks under the Resources section.
You can see the next run schedule using the “Schedules” page. In my example, the Runbook will run every 4 hours, the next run is at 9:45 PM, and so on…
That’s it there you have it!
This is version 1.0, if you have any feedback or changes that everyone should receive, please feel free to leave a comment below.
Azure File Shares Backup Constraints
When designing a backup strategy for Azure file shares, you need to take into consideration the following two constraints:
1) All the Azure file shares hosted in the same storage account need to be protected with the same Recovery Services vaults.
2) The maximum number of file shares that can be protected per vault is 2,000, and the maximum number of storage accounts that can be registered per vault is 200.
Ideally, any configuration or deployment that fulfills the above constraints should be good to go and you don’t have to worry about any scalability, soft/hard limits per vault or subscription, and potential I/O bottlenecks.
Conclusion
In this article, we showed you how to auto-protect newly created Azure File Shares, so you make sure that Azure Backup is continuously protecting your data in your Recovery Services vault.
The Azure file share backup is a cloud-native solution designed to safeguard your data in the cloud, removing the need for extra maintenance associated with on-premises backup methods. By seamlessly integrating with Azure File Sync, the Azure Backup service enables you to consolidate both your file share data and backups. This straightforward, dependable, and secure solution empowers you to easily set up protection for your corporate file shares, ensuring that your data can be recovered in the event of accidental deletion.
Do you want to learn more about Azure Storage including Azure Blobs and Azure File Shares? Make sure to check my recently published online course here: Azure Storage Essential Training.
__
Thank you for reading my blog.
If you have any questions or feedback, please leave a comment.
-Charbel Nemnom-
