Failover Cluster Question - Agent Based Backup query customer domains

[Matthewh]

I have a question about the setup with failover clusters, I am aware that to get this working right you need a backup and replication server installed inside the customers domain or a connection to the customers domain to setup and create the protection groups, the current product that we use for backing up the failover clusters for our customers also uses an agent but it does everything via that agent to our central backup servers.

My question is there any reason why veeam opted to require a direct connection to the active directory server from the backup and replication server rather than tunneling it via the agent that is installed on the machine inside the customers network, it would greatly reduce the complexity and rapidly increase our options for backing up various customers if we could specify and account to use and do a domain query via the agent that is installed on the nodes rather than having to create a backup server inside the customers network or adding connectivity from their domain to ours.

Many customers as I am sure you are aware dont want to create trusts between domains where they dont have to and some are unable to do that, likewise they dont want to install a system that they dont manage or delegate the rights to us to manage that veeam backup server in their environment.

[Dima P.]

Hello Matthew,

My question is there any reason why veeam opted to require a direct connection to the active directory server from the backup and replication server rather than tunneling it via the agent that is installed on the machine inside the customers network

Connection to the AD is required for Protection Groups to find new machines automatically and create required entries for cluster accounts. Since Veeam B&R acts as a central management unit for managed by backup server job type (which is the only option for failover clusters), that's the only way to protect such workloads. Veeam B&R queries the AD and sends the commands to the agents when to start the job (so more or less Veeam B&R acts as a quorum server for the backup agents).

You still can use protection groups without AD integration for non-failover cluster workloads without any issues or create a self-managed protection group and deploy the agent package manually or via third-party tools.

[Matthewh]

Thanks for the answer Dima, my question was more why the Veeam B&R server cannot direct its query via the agent that is running on the virtual or physical machine that is already in the customers domain.

Our existing legacy solution does it this way, you install the agent, point the agent at the backup server/portal and then you can regsiter the virtual identities (active directory cluster name and node names) which we can then take backups of, we dont have to expose the customers AD to our legacy backup product via any means and we dont have to install another backup server inside the customers network to acheieve it.

Our issue is that we want to use veeam as our single backup tool but it seems increasingly unlikely we can do that without greatly increasing the complexity and difficulty of management, having to put a veeam B&R server in each customer domain that we want to take a backup of windows failover clusters is a very limiting factor some customers only have a single cluster that we need to backup and it just doesnt make sense for a single machine.

[Dima P.]

Hello Matthew,

Thanks for the feedback!

For server job and failover cluster jobs with or without AD agents still need the constant direct connection to Veeam B&R, as it controls the schedule and all job settings. For non-cluster machines Veeam B&R is required only to track new machines in the AD during the rescan of the protection groups (i.e. discovery), for clusters we use AD to verify the existence of the cluster account.

For managed by agent job type direct connection to Veeam B&R is not required (agents control their own schedule and job settings), so you can possibly use non-AD protection groups for remote sites in conjunction with managed by agent jobs.

[Matthewh]

Hi Dmitry,

As a service provider this leaves me with a bit of a difficult issue, I have a legacy backup product that we are using for taking backups of our customers failover clusters, this product uses an agent which is installed on the customers machine, as part of the installation process you tell it the backup server IP address and credentials to use for its connection, we as such have a persistant static route using a different network adapter for all the backup traffic.

Any AD queries and the like are directed via this agent to the customers domain, this bypasses the need to install expensive and duplicated infrastructure to backup a pair of virtual machines.

What we are trying to do is move away from the legacy backup product to settle on a single provider, currently we use veeam for backing up everything apart from the failover clusters due to your limitations of requiring direct access to the target domain.

The challenge is that we cant install veeam backup and replication servers inside our customers domain as by design in the majority of cases we have no access to their domain setup, it seems like veeam may not be the most suitable product for a single solution to backup the virtual machine workloads that reside within our domain and the failover clusters that are within the customer domain, I struggle to understand why it cant be configured in such a way to use the agent as a "proxy" for the domain requests with a suitable account within the customers domain rather than needing to install a whole backup and replication environment inside the customers domain?

[HannesK]

while I agree with your idea in general (well, it requires a more complex setup process)... just to be sure: did you try just opening one port to the customer domain controllers? I see no need to place VBR inside the customer domain.

[Matthewh]

Hi Hannes,

In our testing it still does not work with failover clusters and protection groups unless you have a VBR inside the customer domain, we can see attempts from the veeam server to reach the IP addresses of the cluster and the physical nodes from the VBR server for some reason when we have been monitoring the traffic flows.

We opened the port to the domain controller and we can create the protection group but it cant connect to any of the servers within the protection group and fails to push the agent out.

Would it be a case of manually installing the agent on the target machine and if so how do we connect the agent to the cloud connect gateway and the cloud platform?

[Matthewh]

the above is the traffic flows that we found doing packet captures in our test environment, without rules to allow the traffic from the cloud service provider to the addresses of the cluster and entries in DNS the job fails entirely, if we open up the rules it works but is a big security concern for our customers.

[HannesK]

Hello,

without rules to allow the traffic from the cloud service provider to the addresses of the cluster

that sounds expected https://helpcenter.veeam.com/docs/backu ... ml?ver=110. The backup server must be able to connect to the agent computer directly. But that's the same for managed agents without cluster (or I missed something in the picture).

I just tried to point out, that it should work without the requirement that the VBR server is joined to the customer domain.

As you mention cloud connect now... if you want "single port" communication in a secure way with your customers, then I would go for one VBR server per customer and manage them with the Veeam Service Provider console.

[Matthewh]

Hi Hannes,

It does indeed work if we open the doors between us and the target customer for sure but most customers dislike that, then we get stuck in the situation to back up 4 or 6 virtual machines I need to deploy a VBR, Local Repository (cant do transaction log backups to a cloud platform) plus the cloud platform and manage and administer that environment inside the customers domain which in most cases the customer doesnt want us to have access to either.

It basically makes it a very complicated high maintenance solution which is difficult to manage and administer.

Even the legacy platform that we have has a better self service portal (customer can manage and restore their own data with minimal input from us through the website and agent) and the agent based setup does away with a local backup instance entirely as we can utilise the system which is on a RIPE range from within our datacentre without clashing with them using a VRF on the network platform.

The components needed for the legacy product is 1 agent per cluster node/VM and the central server and a storage location only so is a much cleaner and easier to manage prospect as a managed service provider.

Veeam on the other hand neeeds per customer 1 VBR, 1 Local repository, 1 Agent per VM/Node and in the cloud platform, cloud gateways, cloud server, cloud storage repository, for small customers with a specific requirement for transaction log backups/SQL failover clusters veeam becomes a very hard sell.

[HannesK]

Hello,
please remember that VBR is built for virtual platform backup. So except for Windows failover clusters with shared disks, agents are irrelevant in a "normal" design.

For 4-6 virtual machines, one backup machine should be enough. Not sure why you plan the extra repository machine. My rule of thumb is "up to 1000 VMs can be done by one proper hardware server". If you have a small customer, a VM can do it. If a customer has some hundred VMs, then a physical machine would probably be more useful.

I repeat: Veeam components can exist outside the customers active directory domain. There is no need to join any Veeam component to the domain.

Self-service (except for failover clusters) can be done directly on the agent. No need for a web portal. Just use "managed by agent" protection group which installs the user interface and customers can restore directly on the VM.

Agree, there is always room for improvement.

Best regards,
Hannes

[Matthewh]

Hi Hannes,

The use case we have is specifically for SQL failover clusters with a file share element as well, now as I understand it you are unable to take SQL transaction log backups (which is a requirement of our customers to take backups between 15 and 30 minute intervals depending on the customer) without having a local repository, you cannot direct transaction log backups to a cloud repository via the cloud gateway as it has been explained to me.

So we could backup the datatbase itslef but do nothing with the transaction logs at all unless we have a local repository inside the customers network, I understand that none of these components need to be joined to the customers domain but the do need to be inside or have access to the customers domain controllers in order to carry out the queries that your systems require.

As a best practice is it not better to segregate the storage from the backup server itself, I know it can all exist on one machine but if there is an issue or a problem then you loose the entire system whereas if you have a linux hardened repository taking the data then the risk of compromise is reduced.

Having the agent act as the "proxy" for all those requests as its installed inside the customers environment would simplify the installation greatly then the last stumbling block would be the transaction log backups to a cloud backup repository via the agent.

Regards

Matt

[HannesK]

Hello,
thanks for the additional feature requests of log shipping to cloud connect. It's also a known one that comes up from time to time by service providers. Agree, "would simplify"

Best regards,
Hannes

[Matthewh]

I still feel that perhaps the easiest solution for this is to offload the whole workload/AD connectivity element to the agent, if the agent can act as the broker or origin point for the query to the active directory and include the ability to do transaction log shipping via the agent to cloud repository then the whole solution becomes an awful lot simpler than having to duplicate large numbers of servers inside customers environments that then need to be managed and add to complexity and security issues for the customer.

This has become such an issue internally at least that we are starting to evaluate alternative providers that can be a one stop shop to deliver both failover cluster protection via a plugin or agent without creating duplicate infrastructure as well as virtual workload backups.