Azure File Sync data backup with Veeam NAS backup capabilities

More and more questions come up from customers, such as whether they can back up Azure File Sync data with Veeam and how to do it. The short answer is “yes we can!” But it’s a good idea to check the different configuration options.

The most common question is about Azure File Sync with “Cloud Tiering.” Veeam Backup & Replication v10a brings support for the “Cloud Tiering” feature.

Azure File Sync configuration options

In the background of Azure File Sync, there is an SMB share hosted in Azure. All files are synced to this share via HTTPS. The share hosted in Azure can be configured to be reachable over the internet as a normal SMB share on TCP port 445 (Figure 1). Of course, only legitimate IP addresses should be allowed to access the share. 

Figure 1: Synchronization of local file server with Azure File Sync

There are two options how Azure File Sync can be used.

  1. File synchronization (like Microsoft OneDrive but without versioning)
  2. File synchronization + Hierarchical Storage Management (Cloud Tiering)

If customers only use file synchronization (option 1), then backup can be done normally by using image-based backup. This could either be virtual machine-based backup with Veeam Backup & Replication or physical machine backup with Veeam Agent for Microsoft Windows. Technically, Veeam NAS backup capabilities are also an option, but economics usually prevent that option. All files are stored on the local file server with option 1.

With option 2, old files that are not accessed anymore can be moved to the cloud (cloud tiering). Moving unused, old files to cheaper storage aka “hierarchical storage management” has existed for decades. Offloaded or tiered files are shown in Windows Explorer with 0 bytes “size on disk” (Figure 2) and a small X-icon to show users that the file tiered. From a technical perspective, they are reparse points. Veeam Backup & Replication 10a has a new feature to handle these Azure File Sync reparse points.

Figure 2: No disk space usage of files that were tiered to cloud

While tiering can be interesting from a cost perspective, it causes headaches for migration scenarios when the file server does not have enough disk space for the tiered data. The positive side-effect of not having enough local disk space is, that ransomware stops at the point when the file server is filled to 100% disk space. I would not rely on this kind of “protection.” As cloud tiering does not prevent ransomware attacks, a proper backup concept is still required.

Backing up cloud tiered files

With version 10a, a Veeam customer can back up cloud-tiered SMB shares like any other SMB share (see Figure 3). The cloud tiering is transparent for the backup administrator. The only thing he might notice is, that it takes longer due to possible bandwidth limitations.

Figure 3: Back up files that were tiered to Azure

The first configuration step is to add the file share to the inventory in Veeam Backup & Replication (Inventory -> File Shares -> Add File Share). Figure 4 shows the result in the console.

Figure 4: A file share in the inventory

The second and last step is to create a File-Share backup job. Select the share you want to back up (Figure 5) and configure where to store the data and the backup schedule.

Figure 5: Add file share to backup job

It is also recommended to have a copy of the backups in a secondary location to meet the 3-2-1 Rule.

Figure 6: Copy backups to secondary target / location

That’s all to back up a file share that is configured with Azure File Sync Cloud Tiering. Veeam Backup & Replication handles the reparse points or stub-files (mentioned earlier) in a special way. It can back up the files without requiring free disk space to download the files to the fileserver.  That’s important because traditional “copy & paste backup” would recall all files to the file server and fill up the disk there.

Summary

Backing up data from Azure File Sync is no problem with Veeam Backup & Replication 10a. Just do a backup from the SMB share as you would do for other SMB shares.

Exit mobile version