Azure blob block re-use?

[RossFawcett]

Has anyone actually had the cloud blob storage block re-use work correctly? We've been testing with Veeam v10 with both the RTM and now GA release and whilst it does replicate blocks out with copy mode, we have found that when it comes to do the equivalent of a merge, it basically sends an entire VBK in full up to Azure which largely defeats the point. Our understanding was that the blob storage was meant to minimize the storage transactions and re-use blobs in a similar way to ReFS/XFS.

From a config perspective this is what we have

• Standalone Windows Server 2016 VM (off domain) with Veeam v10 GA
• Backing up two VM's from an ESXi cluster 6.7 with latest updates as of 27th of Feb (our two domain controllers)
• Repository is an SOBR repo, per-vm backup files, move mode disabled, copy mode enabled for capacity/azure
• Primary extent is SMB to another Windows 2016 server with ReFS
• Second extent is the Azure blob (standard setup as per the Veeam doco)
• Retention on the backup job is set to 7 points (basically so we can quickly test it)
• Job is configured as forever forward, no synthetic full jobs (but will obviously rollup/merge when it gets to 7 restore points)

So we ran the primary job till it hit 7 points which was reflected in both the disk repo and the azure repo. When the next job runs we correctly see the on prem run a merge, we see the SOBR tiering job start which sends the equivalent vib, then we'd see a second SOBR tiering job start directly after this, which then starts processing a vbk which it then starts sending up in its entirety. This was reflected in the network usage over the period as we see it hammering the outbound traffic and maxing the interface.

I did rebuild the server completely from RTM to GA (as in deleted the entire VM, reinstalled from scratch) thinking it was a weird RTM bug, but we see the same behavior on GA. I will say however, I did see it work once, however it only did it on the first VM in the job, not the second VM, and having run the job multiple times since then, it has continued to send up a full VBK for every incremental run of the job making the feature kind of unusable.

So has anyone actually had this working correctly with Azure blob storage? I had another post on here which talked about this and was advised it was not expected behavior, and I do have a case open 03987430 which initially was responded to saying upgrade to GA.

[dalbertson]

I’ll dig into your case a bit. Have you updated it since GA?

I can find them in logs of they have been attached to the case but can you tell me what your job settings are? Per-vm, etc.

[RossFawcett]

I updated the case last night after I rebuilt it to the GA release. But it's basically identical the behavior we are seeing, my gripe is really that this should have worked on the RTM release given it's kinda the big selling point of v10.

Job settings

• Single backup job pointing to the SOBR (which has the two extents described above)
• Retention 7 points
• Not using GFS (unticked in the job)
• No guest processing (as we are in test phase)
• Backup tab set to incremental
• Synthetic backups periodically is disabled (unticked)
• Active full backups is also disabled
• Storage is set to generally defaults with hte exception of WAN target as the storage optimisation, compression level is high (minimize WAN traffic + storage, and we have CPU to spare), and encryption is enabled

The SMB storage extent

• Align backup file data blocks is enabled (as the SMB is another win 2016 server with ReFS, it's storage from our existing production Veeam, just a shared folder on it so we can test separately)
• Use per-vm backup files is enabled

At the SOBR level

• user per-vm backup files is enabled (default)
• Perform full backup when required extent is offline is disabled (default)
• Placement policy is data locality
• Capacity tier set to extend to Azure blob
• Copy backups to object storage is selected/enabled
• Move backups to object storage is disabled
• Encryption is enabled here

I can generate new logs and send to the backup ticket, they shouldn't be too large to email as it's all fresh.

[dalbertson]

If you could that would be great. I’ll look at them and see what I can find.