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:
The 1G NIC shown in GUI -- since this is a virtual port in VM that can cause confusion between GUI and Linux.
If this is a physical 10G NIC port mapped into the VM, the V5000 likely does not treat the link speed as it should. Known issue, We're addressing it. But it does not matter for functionality or actual speed.
In terms of snapshot, was it a replication snapshot or a secure snapshot? I haven't seen that error. it is true that VTL isn't supported in the V5000, of course, but that's an inappropriate error. Can you give any more details as to how it happened?
Thanks again, and I'll look at Veeam questions when I can. Veeam is one of the products most commonly used with DXi so we have a lot of customers using it in the field and we have a good relationship with Veeam as a company so if we are lacking something we can identify the issue resolutions.
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?
I appreciate you response!
As a tentative summary and each's bullet points status
So, in a nutshell, may you please review the Italic and Bold portion above and feedback?
Thanks and regards,
Great to hear from you again. Sorry I didn’t answer your questions the first time, but let me try again. I’m not a Veeam expert unfortunately but fortunately we do have some on staff.
So I think these are best addressed together.
You should be able to use “hotadd” transport mode. That’s all dependent upon the Veeam B&R ESX/datastore availability and the DXi doesn’t matter. A Veeam proxy can’t be installed on the DXi, but your configuration of Veeam + ESX and datastore access should allow for hotadd.
Apparently it’s best to have a VM proxy on the ESX server that has access to all relevant datastores. Then that has to be configured within Veeam. That’s a common configuration.
So the VM Proxy can directly mount the datastore that contains the VM (VM to be backed up) vritual disks and send data directly to the DXi.g
Does this help?
basically, it confirms, it should work in a hotadd mode. I need to say, my test environment runs in our data center, where we are usually work with a storage integration, so with our Veeam backup server and its proxies, which are all physically, we fetch the backups directly from the primary storage snapshots.
As this is hard to tweak, and also not representing our real use case for the DXI V5000, I will pick a remote site and deploy an appliance there, to have better real life conditions for another test run.
Btw, I noticed also in the file system (/var/log/Veeam) some well known log files... ;-)
I will keep you posted on the result of the remote site testing.
I don't think this is a very complete response but I didn't have much time today. so I'm passing on what I got but didn't have time to delve into it further. I apologize for that. I'll try again if I can. But does this help:
DXi could be a secondary copy location for the primary backups. That way you have a deduplicated copy of the backup on V5000 and could replicate efficiently offsite further increasing protection!
In my lab environment I do not have primary storage that has integration with Veeam (for direct snapshot) so i cant really test this scenario in-house. But this could be a great option.
no worries at all. Next validation step is on my side. Of course, my clear aim is to consolidate any competitor's deduplication appliance AND the current primary backup targets, running on Windows. Not for big size sites, but the DXI is seen as the clear option to work in micro or midi sites as THE backup target.
Additionally, AND if we got a deal with Quantum about an onprem Active Scale, we are extremely excited to use it as performance tier within an ScaleOut repository.
The true only missing feature from Veeam is the PowerNFS / MountServer support for all Linux based appliances, being the source of an Instant Recovery (Running a VM from a backup source directly). But thats somehow on the Veeam roadmap, however not scheduled.
Just one thing ... the DXi supports instant recovery from a deduplicated share already (direct). It works well.
when we do instant recovery the DXi serves up the data independently of the Veeam server. The Veeam server will only record changes to data and apply IF the VM is migrated to production
Ufffh...This sounds amazing!
And right in time, as I am working to deploy a new DXI instance to a real remote site.
When I am get you correctly, I need only to make sure, the repository for the DXI has been set without a mount server. And with that, Veeam will still present the Instant recovery from the DXI based repository.