We are just validating the DXi-V5000 as a potential replacement in our global backup strategy for our remote sites. We are using consequently Veeam Backup & Replication v11 to manage this.
Today we have dominant Windows based remote proxies to our hypervisors and store there either on ReFS or NTFS the primary backups. To achieve secondary offsite backups, we are using either central StoreOnce appliances remotely via their native Catalyst protocol, ScaleOut repositories towards AWS S3 (not Glacier yet), or local StoreOnces replicating to central ones.
The DXi-V5000 appealed itself recently, and we try to find out, how far we can go to use it later, either as community or paid version. Depends on sizing and support needs.
I just performed a couple of steps, am happy so far with the results, however handful points are appeared, and I wanted to use the community here to kickoff a discussion.
Any kind of feedback is highly appreciated!
PS: To be fair, I forgot to mention, it is a great product anyway, and the approach to open it for small use cases, is making the solution truly sexy to look at.
Hi Nico -- thanks for the post! I'll try to research your Veeam specific questions but unfortunately our Veeam people are out for the week. For other issues:
thanks for your prompt reply.
About the odd message, I understood, to make any replication state on the target system available to an attached VBR instance, I need to "recover" a received snapshot. That works as expected!
In the moment, I want to cleanup the recovery jobs, aka "Delete Job Info" of the selected snapshot recovery job, it throws the error. I uploaded a screenshot to document it a bit more.
Thanks for the comment about the link speed, I understood it is a minor and cosmetic error, as the link speed of the vNIC is 10GBit, while the vNIC is configured as Paravirtual. I tried also VmxNet3, but same result. I ignore that for the moment.
About the other points, we scheduled for tomorrow a meeting with a consultant of Quantum, maybe we got some traction from there as well.
Keep the post updated from my end...
I'm passing the screenshot on but I may not have an answer until Monday on the Veeam issues. I know you'll get good help from the consultant as well. I will that person know what I am doing as well.
Been talking to some people about this, and this is what I got back:
The modern versions of Veeam cannot install as we are “integrated” with Veeam.
Veeam (on standard linux systems) will install a resident data mover and open a port/listener for jobs. We do not do this. Our VDMS integration loads a temporary data mover to accomplish the same thing. The reason Veeam does this on standard linux systems is to support “immutability”. The DXi does the same thing via secure snapshot (one of our included features). The message during repository configuration should not be alarming.
The S3 scaleout backup repository should support good performance when migrating to S3 with the DXi as the gateway (this avoids an unnecessary hop to a Veeam server for a gateway). The network path should be analyzed to ensure that the data is being transferred directly from the DXi to the S3 cloud storage and not otherwise. This can be done by monitoring the Veeam server network to ensure the data is not landing there prior to transfer to S3. But as I understand your S3 target is on prem, so not WAN to worry about.
Also -- I've been thinking about our VDMS option. It takes quite a bit of memory. Does your VM have considerably more memory than the minimum?