How To Calculate The File Share Snapshots Size For An Azure Storage Account

7 min read


Azure Files provides the capability to take share snapshots of file shares. Share snapshots capture the shared state at that point in time. The file share snapshots help to protect against an application error and data corruption, as well as, against accidental deletions or unintended changes. Azure Files share snapshot went GA back in March 2018, you can read about the announcement by Microsoft here.

After you create a file share, you can use periodic share snapshots for protection against accidental deletions. You also can use AzCopy, Robocopy, or a third-party backup tool that can back up a mounted file share. A share snapshot, when taken periodically, helps maintain previous versions of data that can be used for future audit requirements or disaster recovery. Azure Backup offers backup of Azure Files. Azure Backup relies on share snapshots to take backup which integrates perfectly with Azure Files and Azure File Sync. For more information about Azure Backup integration with Azure Files, please check the following article.

In this quick blog post, I will share with you how to find the file share snapshot size for your Azure file share so you can calculate the storage and price accurately. This is also useful when it comes to estimating the Azure Backup price for Azure Files/Azure File Sync before you enable backup in the cloud. Azure Backup uses Azure File Share snapshots for creating recovery points. Storage charges incurred for snapshots is billed along with your Azure Files usage. For more information about the Snapshots data storage price, please check the pricing guide from Microsoft here.

Share snapshot usage

When a share snapshot is created, the contents of the file share and the share snapshot are exactly the same. However, only the incremental changes are written to the snapshot. This makes snapshot creation faster, space-efficient, and cost-effective. The base snapshot is the share itself. All the subsequent snapshots are incremental in nature and will only store the difference from the previous snapshot. This means that the delta changes that will be seen in your bill will be minimal if your workload churn is minimal. So if during a specific period of time the churn was high, then the share snapshot size and the bill will be also high. Churn is the amount of new data every day (that is, written or appended to existing files).

Let’s take the following example:

You created an Azure file share and you put in it 100 GiB, then you took a snapshot.

  • The file share size is 100 GiB, however, the snapshot size will be 0 GiB because no new files were changed or appended.

You modified and changed some of the existing files in the share (i.e. +2 GiB) and then you took another snapshot. The snapshot could be manually triggered, or by Azure Backup, or by any third-party backup tool.

  • The file share total capacity size will be 102 GiB, however, the snapshot size is now 2 GiB. Please note that if you just added/uploaded new files to the file share and then took a snapshot, the size of the new files won’t be calculated toward the snapshot size, they will fall under the file share total size.

To conserve space on your file share, you can delete the share snapshot for the period when the churn was highest. Snapshots also cost money, you don’t want to keep too many around. Please note that Azure File Sync will also automatically takes share snapshots and file snapshots for internal use to provide data consistency.

Share snapshot size

Now to calculate the share snapshot size, you can jump to the Azure Portal, open the storage account (standard or premium) where the file share is created and then look into Metrics under Monitoring.

If you are using a premium storage account, you can also go directly to that specific file share under File service select File shares, click on the file share name and then select Metrics under Monitoring. By default, the metric is populated as follows:

  • Scope: Storage account name
  • Metric Namespace: File
  • Metric: File Count
  • Aggregation: Avg

In addition to the metric, you will also see the filter which is predefined and set by default to the file share name.

Now to look for the share snapshot size, you need to modify the metric by clicking on the name of the storage account and then modify the METRIC and choose File share snapshot size under CAPACITY. You can also select a time range if you want. By default, the chart shows the most recent 24 hours of metrics data. For more information about Azure Metrics Explorer, please check the following document from Microsoft.

Once you select the File share snapshot size, the chart will be updated to show you the average of all the snapshots size for that particular file share. In this example, I appended an exiting file in the share with +2.3 GiB and then I took a snapshot. The File share snapshot size is reporting correctly (2.6 GiB).

Please note that the file share snapshot size is updated once per day, so if you create a snapshot, the metric size won’t reflect immediately in the chart below.

That’s it there you have it!

There’s more…

How Azure Files do snapshots compare to Azure NetApp Files?

  • Does Azure Files do file-level snapshots?
    • Meaning that regardless of how much the file itself changes, the snapshot engine just identifies the files that are modified and does a full copy out of the file (less granular) that has changed. So, incremental changes happens on the file share itself but not granular at the block level per file.
  • OR does Azure Files do granular block-level deltas within the specific file?

Both services (Azure NetApp Files and Azure Files) are native in the Azure portal. So if you are a NetApp person, maybe you are familiar with the granular snapshot technology of ONTAP where they do pointers at the block level (4k) granularity, so only the actual changes within the file (4k block level) take up incremental space usage.

Since these are both Microsoft native services, you want to make sure that you properly represent cost considerations when snapshot retention policies are implemented.

The good news is, Azure Files does granular block-level in such a way that if you change just a part of the file, only the changed parts are stored (and billed as part of the snapshot cost).

Note that some applications (i.e. Word, Excel) save files by creating a new file and deletes the old one. So in this case, the cost would be 2 full files.

Also, note that Azure File Sync updates files in the same manner. So even if a file on a server was modifying a file ‘inline’, the cloud would see a full new file. Here is a concrete example:

Consider you have a 1GB file, which an application partially modifies ‘inline’ (meaning, they open the file and modify say 1 MB of it). If you have any VSS snapshots on the server, the write would take an extra 1MB of space on the server (the old 1MB is still stored, to let the data in the VSS snapshot work).

The same is true in the cloud. If you modify 1MB of the file in Azure Files (Share) directly, you will be billed an extra 1MB, since it is needed for the snapshots to work.

With Azure File Sync, you may do the same thing. For example, you modify the 1GB file on the server, but you only change 1MB of it. The server will store an extra 1MB. However when that change sync’s to the cloud, the cloud side will have the 1GB file deleted, and a new 1GB file created. The user would be charged 2GB of data until the cloud snapshots (which contain the old 1GB file) are deleted. The same is true in reverse. If you modify 1MB of a 1GB file ‘inline’ in the cloud share directly, the cloud snapshot cost will be just 1MB. But then when Azure File Sync downloads the change to the server, it would delete the 1GB file on the server, and create a new 1GB file. So the server’s disk space would grow by 1GB if any VSS snapshots are protecting the older version.


The File share snapshot size will also show up in your bill, the way to look at the size consumed by share snapshot is by comparing the billed capacity with used capacity. At the time of this writing, Microsoft is are working on tooling to improve the reporting. Until the tool becomes available and before you wait for the bill to show up, you can use the method described above to calculate the share snapshot size and price. Please make sure to check the pricing page for Standard/Premium Azure Files information here. The Snapshots for 1 GiB/month is $0.24 per provisioned GiB for Premium storage and $0.06 per used GiB for Standard storage.

Azure File Share snapshots provide only file-level protection. Share snapshots don’t prevent fat-finger deletions on a file share or storage account. To help protect a storage account from accidental deletions, you can lock the storage account or the resource group.

Before you take a snapshot and automate the backup for the share snapshot, please carefully consider your share snapshot frequency and retention settings to avoid incurring unnecessary costs.

For a quick overview of share snapshots for Azure Files, please check the following document from Microsoft.

For more information about how to automate file restore from Azure file share snapshot, please check the following article.

Thank you for reading my blog.

If you have any questions or feedback, please leave a comment.

-Charbel Nemnom-

About Charbel Nemnom 559 Articles
Charbel Nemnom is a Cloud Architect, ICT Security Expert, Microsoft Most Valuable Professional (MVP), and Microsoft Certified Trainer (MCT), totally fan of the latest's IT platform solutions, accomplished hands-on technical professional with over 17 years of broad IT Infrastructure experience serving on and guiding technical teams to optimize the performance of mission-critical enterprise systems. Excellent communicator is adept at identifying business needs and bridging the gap between functional groups and technology to foster targeted and innovative IT project development. Well respected by peers through demonstrating passion for technology and performance improvement. Extensive practical knowledge of complex systems builds, network design, business continuity, and cloud security.

Be the first to comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.