New install architectural question about backup proxies and Direct SAN

[jmbi]

We're new to Veeam and in the process of working through our installation. We're going with more of an appliance route with an HPE Apollo system with a bunch of CPU, memory and disk for a split environment of about 300 VMs + O365 backup. I have a grasp on pretty much everything short of the backup proxy piece and how data flows through it and how it should exist on the network in our specific case.

We leverage HPE/Nimble Storage SANs in both our colocation facility and our corporate office and replicate between them, it's a sort of hot/hot site scenario. I've watched a couple videos on backing up from Nimble replicated storage snapshots and just using Direct SAN backup as well.

What I'm thinking is our "appliance" in our HQ could act as he proxy since it's a physical system and a pair of it's NICs could sit on the iSCSI network for the Direct SAN backup. What I don't fully understand is in our colocation facility, do I need a backup proxy over there to facilitate anything from a replicated snapshot standpoint? Or we also have several Windows guest initiated iSCSI volumes in our virtual environment which I know will require the Veeam agent to backup. Will there need to be a backup proxy for that as well?

I have a very very high level view of the way that infrastructure is configured that might help explain the situation.

[HannesK]

Hello,
and welcome to the forums

and a pair of it's NICs could sit on the iSCSI network for the Direct SAN backup

yes, the proxies need connection to the iSCSI network. That cable is currently missing as far as I see.

it's a sort of hot/hot site scenario.

could you explain that? Is it an active / active stretched cluster with synchronous mirror and transparent failover (I don't believe so because you only have 200MBit)?

do I need a backup proxy over there to facilitate anything from a replicated snapshot standpoint?

I'm not sure whether backup from replicated snapshot is the best way. I would backup the active VMs on each side (that's how I understand your hot / hot) and then run a backup copy job to the other side. But yes, you want to have a proxy in the location where you do the backup. Otherwise you would send the traffic via the 200MBit link.

the "physical" VMs (the ones with physical iSCSI volumes) do not use the proxy role. All processing is done by the agent itself. Your Apollo servers will only be used as backup repository.

Does that help?

Best regards,
Hannes

[jmbi]

Great information, this is very helpful!

It is not a stretched cluster. Two separate vCSAs in enhanced linked mode. And active /active, in this case, just means the two sites are in use with live VMs, different servers in different environments. For example we have domain controllers in both environments, and we may prefer one site for a specific type of server over another. We replicate the active volumes from each site to the opposite site in case we need to recover from a site loss. Our RTO isn't critical so we don't have any sort of active failover mechanisms in place at this point, only replicated storage snapshots from site to site.

We only have a single HPE Apollo system in our HQ, so it is THE backup server/repository.

So the remaining question really surrounds leveraging the replicated storage snapshots that reside on our HQ SAN, where the live volume was in the Colo. Or if we should leverage the backup proxy. The problem with the backup proxy in our colo, is that we have no repo in our colo which is fine, but since we already replicate storage snapshots to our HQ I thought we might be able to leverage those in our overall architecture to eliminate some of the 200mbit traversal.

[HannesK]

yes, the low bandwidth is a "pro" argument on backing up from replicated snapshots.

the proxy is only needed on the backup site. so the Apollo server can do the job.

[jmbi]

It sounds like you may have some "cons" for backing up replicated snapshots.
What would be downsides be?

[HannesK]

no downsides. actually it's a pretty smart idea you had

[jmbi]

Would I need a proxy in the colo environment for recoveries? Or would I be able to use the HQ proxy for recovery purposes?

[HannesK]

for file / application restore, no proxy is used.

for full VM or disk restore it would be faster, yes (but there is no "need"). In that situation the data would be send compressed between the repository and the proxy. a virtual proxy using hot-add that is only used for restores is probably the best option.

[jmbi]

HannesK you have been incredibly helpful in assisting how this will be architected!
I've been working on it today and the integration with the Nimble array has been amazing, it can even to file level recoveries from VMs in snapshots the arrays had even before the initial setup!
This is going to be a revolutionary change in how our backups are performed.

Thanks again for all your assistance!