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