In this article, I will show you how to enable self-service restore in Azure File Sync, so users can restore files from Azure file share(s) without depending on the IT administrator.
In This Article
Azure Files offers shared storage for applications using the standard SMB 3.0 protocol. Microsoft Azure virtual machines and cloud services 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.
Applications running on Azure virtual machines can mount a File storage share to access file data, just as a desktop application would mount a typical SMB share. Any number of Azure virtual machines or roles can mount and access the File Storage share simultaneously.
Microsoft also introduced the Azure File Sync service which allows you to centralize your file shares in Azure Files, whilst maintaining the compatibility of an on-premises file server with all the flexibility and performance benefits that provide. For more information about Azure File Sync and how to get started, please check the following step-by-step guide.
Self-service restore capability is a new feature introduced in Azure File Sync starting with agent version 9 (or above), this is a powerful capability where your users can restore files from Azure file share(s) without depending on the restore from an IT administrator.
Self-Service restore overview
Self-service restore was introduced to the storage sync agent starting with version 9 last year. Self-service restore is built on top of the Previous Versions and Volume Shadow Copy Service (VSS) feature in Windows that you are most probably familiar with. VSS feature has been in the Windows Client since Windows XP and Windows Server 2003.
Previous Versions allows you to utilize server-side VSS snapshots of a volume to present restorable versions of a file to an SMB client. So if a user accidentally deletes a file, they don’t need to contact the IT admin to restore the file. They can actually just open up the file share, right-click on the blank space in File Explorer, choose Properties and then select the Previous Versions tab, select the desired snapshot (date/time) of the share as shown in the figure below.
Then click Open and select the desired file to restore. As you can see in the figure below, this file is tiered to Azure files and the size on disk is 0 bytes.
Then simply the user can drag and drop the file, and then the restore process will kick-in from Azure file share directly as shown in the figure below.
Please note that VSS snapshots and Previous Versions work independently of Azure File Sync. However, cloud tiering must be set to a compatible mode. Many Azure File Sync server endpoints (server shares) can exist on the same volume.
You have to make the following PowerShell call per volume that has even one server endpoint where you plan to or are using cloud tiering.
Enable Self-service restore
To enable self-service restore, this has to be done on the volume level and NOT per individual share on the local server.
Open PowerShell session on the file server where the Azure file sync agent is installed and take the following steps:
Import the storage sync module server cmdlets assuming the agent is installed on the C:\ volume.
#! Import Storage Sync Module Import-Module "C:\Program Files\Azure\StorageSyncAgent\StorageSync.Management.ServerCmdlets.dll" #! Enable self-service restore on the D:\ volume Enable-StorageSyncSelfServiceRestore -Driveletter D: -force
To see if the self-service restore compatibility is enabled on your server, you can run the following cmdlet. In this example, the self-service restore is enabled on the D:\ volume.
#! Check self-service restore policy Get-StorageSyncSelfServiceRestore -Driveletter D:
This command will list the chosen volume(s) on the server as well as the number of cloud tiering compatible days for each (45 days in this example). This number is automatically calculated based on the maximum possible snapshots per volume and the default snapshot schedule. So by default, all previous versions presented to a user can be used to restore from. The same is true if you change the default schedule to take more snapshots (more on this in a bit). However, if you change the schedule in a way that will result in an available snapshot on the volume that is older than the compatible days’ value, then users will not be able to use this older snapshot (previous version) to restore from.
If you want to disable self-service restore on a specific volume, you can run the following cmdlet to turn it off.
#! Disable self-service restore policy Disable-StorageSyncSelfServiceRestore -Driveletter D:
How it works…
When you enable self-service restore, it configures Azure File Sync cloud tiering on the specified volume to be compatible with previous versions and guarantees that a file can be restored from a previous version (even if the file is tiered to the cloud as described in the previous section). Additionally, self-service restore enables the default Volume Shadow Copy Service (VSS) schedule. You can decide to modify the VSS schedule if you want. The default snapshot schedule takes two snapshots per day, Monday through Friday. That schedule is configurable via a Windows Scheduled Task, or directly on the volume by choosing the desired volume, right-click select Properties, then choose Shadow Copies tab, select a volume and then click Settings. In the settings page, select Schedule and then change it according to your needs a shown in the figure below. The default maximum number of VSS snapshots per volume is 64, as well as the default schedule to take them (twice per day), this result in a maximum of 45 days of previous versions a user can restore from, depending on how many VSS snapshots you can store on your volume. If the maximum 64 VSS snapshots per volume are not the right setting for you, you can change and modify this value via the following registry key PowerShell cmdlet.
#! The default data for this value is 64. The minimum value is 1. The maximum value is 512. New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\VSS\Settings\' ` -Name MaxShadowCopies -PropertyType DWord -Value 128 | Out-Null Get-Item -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\VSS\Settings\'
Please note that for the new VSS limit to take effect, you need to re-run the cmdlet to enable Previous Versions compatibility on every volume it was previously enabled, with the -Force parameter to take the new maximum number of VSS snapshots per volume into account.
#! Re-enable self-service restore on the same volume that was previously enabled Enable-StorageSyncSelfServiceRestore -Driveletter D: -force
This will result in a newly calculated number of compatible days which becomes 90 days in this example instead of 45 days. Please note that this change will only take effect on newly tiered files and overwrite any customization’s on the VSS schedule you might already have made.
Things to consider
There are a couple of things you should be aware of before you enable this feature:
- If you use the -Force parameter when enabling self-service and Volume Shadow Copy Service (VSS) is currently enabled, then it will overwrite the current VSS snapshot schedule and replace it with the default schedule. Ensure you save your custom VSS configuration before enabling self-service restore as described above.
- If you are enabling self-service restore on a cluster node, please note that you must also run it on all the other nodes in the cluster.
- Enabling self-service restore can have an impact on your Azure storage consumption and bill. This impact is limited to files currently tiered on the server only. Enabling this feature ensures that there is a file version available in the cloud that can be referenced via previous versions (VSS snapshot) entry on your local file server.
- If you disable this feature with tiered files, the Azure storage consumption will slowly decline until the compatible days’ window has passed. There is no way to speed this up.
- If you are not using cloud tiering capability, then you will not consume additional Azure storage, however, you still have to enable this feature for the users to be able to self-restore.
As described in this article, you can easily enable self-service restore on your Azure file shares so users can restore files without contacting the IT department. This is so powerful feature that will reduce support calls and speed up the restore process.
Azure File Sync extends on-premises file servers into Azure by providing cloud benefits while maintaining performance and compatibility. Azure File Sync provides:
- Multi-site access – provide write access to the same data across Windows servers and Azure Files.
- Cloud tiering – store only recently accessed data on the local server(s) and save on capacity storage.
- Integrates with Azure backup – no need to back up your data on-premises.
- Fast disaster recovery – restore file metadata immediately and recall data as needed.
I hope you find this guide useful. To learn more about Azure File Sync, please check the following step by step guides.
Thank you for reading my blog.
If you have any questions or feedback, please leave a comment.