Hi!
Today we’re going to talk about file shares and how to protect them. We’ll also look at how Veeam handles the various backup options available within the Veeam Universal License.
File shares can take many forms, so we’re going to look at the following:
- A Physical/Virtual Server
- A NAS/SAN/Storage Device with File Share capabilities
- Azure Files
- Amazon EFS (Elastic File Systems)
Physical & Virtual Servers
Before Veeam introduced native file-share support for Veeam Backup & Replication, you could still backup physical or virtual servers. This was achieved via native hypervisor integrations, or the use of the Veeam Agent, on supported operating systems.
When protecting servers that provide file shares from a traditional Windows/Linux/UNIX operating system, we license each server, without many considerations to the file shares themselves.
There are a few considerations still to talk about:
Did you know? That if you’re presenting your file share on a server cluster, such as Windows Server Failover Cluster, you must license every node of the cluster. For example, a 3-node cluster will consume 3 VUL instances.
Did you know? That if you’re trying to backup a Windows Server with 64TB+ disks, certainly something possible with file shares, Microsoft doesn’t support VSS. There are still a few options here, however.
- If the server is a VM (Whilst VMware & Hyper-V don’t support disks larger than 64TB it’s certainly still possible to combine them into a larger volume WITHIN the OS) you could perform a crash-consistent backup, which would omit leveraging VSS.
- If the server is using a supported storage solution, and is in a supported configuration, you could leverage Hardware VSS with Veeam Agent for Microsoft Windows to work around this issue.
- If neither of these options apply to you, you could leverage Veeam’s native File Share backup options.
File Shares (Otherwise known as NAS Backup)
With the release of Veeam Backup & Replication v10, we saw support for “NAS Backup” become introduced. Within the original release NAS Backup could protect SMB and/or NFS shares, and with support for adding “Managed Server File Shares”, this meant file shares from Windows or Linux servers. Functionality grew with the release of v11 to include “Enterprise NAS Filer” support, this meant that specific storage systems including but not limited to NetApp Data ONTAP, and Dell PowerScale, could be leveraged at an advanced level by Veeam, including native support for storage snapshots.
Licensing File Shares is an interesting concept, it’s been a topic of heated discussion on multiple occasions, and Veeam have been incredibly receptive to the feedback. When the NAS Backup option first became available, licensing was performed in 250GB increments, however when v11 was released, this changed to 500GB increments, meaning one VUL instance = 500GB. But there’s a lot more to the licensing than at first appearance.
Did you know? That if you protect a Windows or Linux server as a file share, you license the server based on the file share sizes, instead of licensing the whole server.
Did you know? That Veeam rounds down in 500GB increments for license consumption. This means that a 999GB file share will consume 1 VUL instance, as it’s counted as 500GB. This also means that a 499GB file share will count as 0GB protected, so it’s free!
Did you know? That if you’re protecting multiple file shares individually, each file share is calculated individually using the above rules. However, if you reference the root of a file share server/device that contains multiple file shares within, the collective capacities are rounded down.
For example: If you have 4x 300GB file shares on a NAS, if you targeted each individually, you wouldn’t incur any licensing costs for these shares, as they’d each round down to 0GB. However, if you protected the entire NAS at its root location, the collective capacity of these would equal 1.2TB (300GB *4), this would still be rounded down to 1TB, and as a result, 2 VUL instances would be consumed. This is a trade-off of saving money on licensing VS ease-of-management.
Did you know? That Veeam calculates the file share based on its highest consumed space within the past 30 days. For example, if I had a file share that consumed 490GB of space, this would be rounded down to 0GB, but if it temporarily increased to 500GB and was backed up at this size, then Veeam would allocate 1 VUL instance to protecting the file share. Afterwards, if the file share reduces in size to 490GB again, after 30 days the VUL instance would be freed.
Did you know? If you protect a file share by multiple backup jobs, the VUL instances required is based not on the consumption of the file share, but on the consumption of the file share multiplied by the number of backup jobs protecting it. For example, a 200GB file share could be protected by 2 backup jobs without incurring a VUL instance consumption. (1x200GB = 200GB, and 2x200GB = 400GB), but if it is protected by a third backup job, a VUL instance would be consumed, as the protected data size for the share would exceed 500GB.
Did you know? That you can protect Azure Files-based file shares via NAS Backup. Either directly targeting the file shares or working with Azure File Sync.
Did you know? That you could backup your Amazon EFS file share via NAS Backup. Target the Linux server that is mounting the Amazon EFS file share and presenting the file share for your backup jobs instead of Amazon EFS.
Azure Files
Exclusive to the Veeam Backup for Microsoft Azure product, and introduced in Veeam Backup for Microsoft Azure v4, is the ability to protect Azure Files-based file shares. This is performed via the creation of policies and can optionally include indexing to enable browsing of files & directories between multiple file share restore points.
Did you know? That currently, Azure Files only creates snapshots of the file shares, instead of independent backups. This means that the deletion of your Azure File Share will result in the deletion of your snapshots too. This also results in a limitation for snapshot support within Microsoft Azure that only 200 snapshots can exist for a file share. This also prevents immutability from being used on this job type presently.
Did you know? That if you leverage file share indexing, a worker node is required. Once the snapshot is created, it is mounted to the worker instance and processed. Should another snapshot be taken before the indexing task is complete, this additional snapshot won’t be indexed at all.
Did you know? That Azure file shares are not licensed based on their consumption, as per the File Share Backup section above, instead they are licensed based on the number of file shares created. If the instance hasn’t been protected by a restore point in the past 31 days, it will release its VUL instance consumed.
Did you know? That if an Azure Files file share is targeted by multiple backup policies, only the highest priority backup policy will process the file share.
Amazon EFS
Exclusive to the Veeam Backup for AWS product, and first introduced within Veeam Backup for AWS v4, is the ability to protect Amazon EFS file shares. This is performed via the creation of policies and can optionally include indexing to enable browsing of files & directories between multiple file share restore points.
Did you know? That Amazon EFS file share backups can only be stored within AWS Backup Vaults.
Did you know? That Amazon EFS file share backups can’t be copied to different AWS accounts.
Did you know? That if you leverage file share indexing, a worker node is required to read the backup data and index it. If a subsequent backup takes place before the indexing completes, the subsequent backup won’t have any indexing created for it.
Did you know? That Amazon EFS file shares are not licensed based on their consumption, as per the File Share Backup section above, instead they are licensed based on the number of EFS file systems created. If the instance hasn’t been protected by a restore point in the past 31 days, it will release its VUL instance consumed.
Did you know? Amazon EFS file shares can be backed up to a backup vault within any supported AWS region. They can also be restored to any supported AWS region too, handy for migrations.
Conclusion
With each platform offering its own constraints, it’s well worth reviewing this list before embarking on a data protection strategy for your file shares. I especially want to highlight some of the current limitations of the public cloud-based file shares and the methods of protecting these, as they can lack the ability to export backup data outside of the public cloud in which they reside, as well as other functionality such as immutability. Whilst the NAS Backup option has the least constraints of these products, the licensing can become quickly expensive without consideration of how best to manage the volumes of data.
As always with these things, there isn’t a clear right or wrong answer. But I hope this helps you next time you need to protect file shares, wherever they are located!
