Azure file Sync - Nas Backup

[cristiano.cumer]

I need a clarification regarding backing up shares where we are using Azure File Sync.

In the release notes for Veeam 10a, support for Azure File Sync is mentioned, but without much detail, and I couldn’t find any further information in the documentation. There is an old blog post https://www.veeam.com/blog/azure-file-s ... ackup.html that also doesn't address my question directly.

I would like to process those shares using:

• NAS backup
• Agent backup

My question is: what happens with files that have been moved to Azure Files via Azure File Sync — i.e., files for which only a stub (0 bytes) remains on the local file share — in the case that those files had already been backed up before being reclaimed on the server?

Will those files be recalled during the backup process? Will they be accessed directly from the Azure Files share? Or, ideally, will they be skipped entirely since they were already backed up?

Thanks!

[david.domask]

Hi Cristiano,

Our Release Notes for when we added the feature I think explains it fairly well as does the blog post you mentioned:

KB:

NAS backup

Azure File Sync support with cloud tiering awareness for file backup jobs. Processing a file share with Azure File Sync enabled will now correctly back up files not present in the local cache. Such files will be backed up directly from Azure, without downloading them back to the file server.

Blog:
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.

So data that needs to be backed up will be retrieved without needing the local disk space, and only changed files since the last run will be backed up, that is, actual changes to the file.

[cristiano.cumer]

Thanks David,

So data that needs to be backed up will be retrieved without needing the local disk space, and only changed files since the last run will be backed up, that is, actual changes to the file.

The part "only changed files since the last run will be backed up, that is, actual changes to the file" was not entirely clear from the release notes. We would like to offload most of our cold data to Azure, but still perform backup of the "hot" files with VBR without incurring in the Azure egress fees, and form your response that seems to be possible.

Does the windows agent backup works the same way?

[david.domask]

It's close, but as written, the backup job will grab files with changes. Old cold data that hasn't changed and is archived won't be backed up again unless changes are made to the actual file. So it's about the last modification time of the file.

Windows Agent backup works either at the block (volume) level or at the file level -- for block level, we don't interact with the files on the filesystem directly and instead backup at the volume level, thus the files won't be recalled from Azure.

For file level, that will try to access the files like a normal file system action, and will trigger the recall from Azure.

[cristiano.cumer]

Hi David,

now it's really clear. Thank you for the detailed explanation

[cristiano.cumer]

Hi David,

I did a small test, and files are recalled every time I perform a NAS backup even if they weren't modified. That shouldn't happen right?

[david.domask]

Hi Cristiano,

If the file had changed since the last backup, the agent will pull directly from Azure without recalling the file to the file server itself as noted in the release notes above.

Are you saying the job backed up files that have not been changed since the last backup? The purpose of the feature is to ensure that the files are not recalled to the server and instead read directly from Azure, but the behavior of what gets backed up remains the same, it's based on changes to the files since last backup.

[cristiano.cumer]

Hi,

yes the files where recalled and backed up again even if they are not changed. I suspect Windows defender is the culprit, I will do some more tests.

Thanks

[cristiano.cumer]

I have opened a support case regarding this #07760833. I can confirm once offloaded files are backed up again even if there is no other modification, using additional space on the repository.

[cristiano.cumer]

Support told me this is the expected behavior. So, stating that Azure file Sync is supported by Veeam since v10a seems misleading to me. The recalls are going to cause egress fees and also consuming additional storage usage.

[david.domask]

Hi Cristiano,

Just for avoidance of doubt, you're saying that once the tiering happens, all the tiered files are backed up each job run regardless of any changes/modifications?

That doesn't sound like correct behavior; I've asked Support to please review the situation further, but if you can confirm my understanding of what you're observing.

Similarly, are you sure the files are recalled locally to the File Server? Or when you say recalled you mean that the unchanged files were backed up again? Just want to ensure there's not a semantic confusion occurring here.

[cristiano.cumer]

Hi David,

thanks for the feedback. No, files are backed up just once after tiering.

this is what I'm observing:

- I activated the azure file sync without tiering on a directory that is also backed up via Veeam B&R NAS. That worked as expected w/o side effects on the backup side
- once the first sync to azure was finished I activated a date based tiering leaving only on the last two years of files on the windows server
- when I activated tiering, on the subsequent backup 3.5 TB where processed / 3.1 TB read and 2.5 TB transferred. Those 2.5 TB were effectively added to the backup repository. Before tiering the usual pattern was 3.5 TB processed / 3 GB read and / 3 GB transferred. The files weren't actually recalled, in that the integration works, files are passed directly to Veeam B&R.
- on subsequent backups the situation in went back to the pattern I was seeing before the tiering was activated.

Two are the main problems on the recall/transfer of tiered files:

- azure egress fees
- backup repository space consumption, in this case Wasabi, because the same file is now stored twice even if the content is the same

I guess that Veeam B&R NAS treats the stub file as a different/new file and performs a new backup of the file. A complete integration should be aware that the file is the same (same modified date, same file size) and skip it.