Data Box Errors Question

Question

I am trying to copy VEEAM data to my offsite backup repository, which I sadly chose Azure for. I have worked with the VEEAM people and while i got the backup copy job to run and put the files on the SMB share, it seems that the Data Box is still very unhappy. My environment at Azure is a VM with a large managed disk attached. I have a VPN to it, and my VEEAM does its offsite copies there. I have one huge file server that will never transfer in that manner (14+TB of backup) so I ordered a Data Box to seed my backup. I got the box in, read all the directions, and using the SMB share I created a backup copy job in VEEAM etc. All that went well, and the copies are on the Data Box. The issues seem to be that I: Did not use one of the pre-existing (e.g. StandardSSD) file shares, VEEAM made it's own named after the copy job. I guess I can fix that manually by moving the copies to the "StandardSSD" folder? Hopefully I don't have to reconfigure my backup copy job but it seems like folders are verbotten and the job would make one anyway? Maybe a call to VEEAM for that one but as for the Data Box, I got other errors such as:

Everything I find in the docs says "VHD or VHDX" but these are VEEAM backup files (.vbk, .vib, and .vbm files) .... am I missing something basic here? Is the Data Box not how this should occur? The VEEAM docs were all full of crap for blobs (I believe my setup uses a Managed Disk?)) and using the REST API but the box I got (the 80TB standard, not the Disk or Heavy options) only showed NFS or SMB as connectivity options. I am so freaking lost with this BS. This is beyond stupid to me. Any guidance would be greatly appreciated. Thanks in advance.

Answer 1

@BPC-3472 I'm glad that you were able to resolve your issue and thank you for posting your solution so that others experiencing the same thing can easily reference this! Since the Microsoft Q&A community has a policy that "The question author cannot accept their own answer. They can only accept answers by others ", I'll repost your solution in case you'd like to "Accept " the answer.

Issue : I'm trying to move my VEEAM data to Azure, where I have an offsite backup repository. I followed the VEEAM advice and got the backup copy job to work on the SMB share, but the Data Box is not happy. I have a VM with a large managed disk in Azure, connected by VPN, and that's where VEEAM sends the offsite copies. But one of my file servers is too big to transfer that way (over 14 TB of backup) so I ordered a Data Box to seed it. I set up the Data Box, read the instructions, and used the SMB share to create a backup copy job in VEEAM. That went well, and the copies are on the Data Box. But I think I have some issues: I didn't use an existing file share (like StandardSSD), VEEAM made its own with the copy job name. Can I fix that by moving the copies to the "StandardSSD" folder? Will that affect my backup copy job? It seems like it doesn't like folders and it would make one anyway. Maybe I need to talk to VEEAM about that, but for the Data Box,

Solution: Using Azure Data Box as a destination for individual backup files (.vbk, .vib, and .vbm) generated by Veeam Backup and Replication is not recommended for now. This approach, involving Azure Data Box as an SMB share, is unsupported. It can lead to complications during the seeding process and data transfer to Azure Blob storage. Azure Blob storage follows an object-based data layout, distinct from Azure Data Box's file-based structure. Consequently, Veeam Backup and Replication may encounter difficulties recognizing or accessing the data correctly in such a scenario.

To access the Azure Blob storage, you need to use the REST API. Set up your device with the required configuration and note down the service endpoint details.

To use your Azure Data Box as a backup repository, you need to configure it properly and then add it through the Azure Data Box repository wizard in the Veeam Backup and Replication infrastructure. Follow the steps for seeding as well

For seeding purposes, it is advisable to employ copy mode in the scale-out backup repository, instead of move mode. This precaution is essential in case of the rare event that an Azure Data Box encounters damage or goes missin

---

Please remember to "Accept Answer" if any answer/reply helped, so that others in the community facing similar issues can easily find the solution.