#Veeam Backup Server: workgroup or domain?

0 Flares Twitter 0 Facebook 0 LinkedIn 0 Email -- 0 Flares ×

Often, during the design of Veeam infrastructures for customers, we have to choose how to authenicate into the Veeam Backup Server.

IT guys in complex companies ask always for all their server, and also their databases, to be authenticated towards a central directory. Beeing Veeam a Windows based software, this means MS Active Directory. Same request comes for the backend database used by Veeam.

Personally, I always said no to this requests, and also internally in our datacenter we configured the whole Veeam Infrastructure  with a dedicated workgroup, and all the Proxies and Repositories are called by their IP addresses and not by DNS names.

the reason is straight simple: being Veeam the tool to recover from a problem or a damage of other services, I DO NOT want Veeam to depend on other services (maybe corrupted themselves) to operate.

So, we usually do:

– no dns but all proxies and repositories registered by their IP address

– Veeam database locally installed on the Veeam Backup server, since space and performance requirements are low, so the SQL Express installed during the setup is enough

Obviously, IT guys will object this is a lower security level than the one offered by a Active Directory integration. Right, but the ultimate goal of Veeam Backup is to restore Virtual Machines. We do not want to be unable to restore lets say Active Directory right because its services like dns and Active Director are unavailable; it’s a paradox we would like to avoid.

2 thoughts on “#Veeam Backup Server: workgroup or domain?

  1. I partially disagree with your lack of trust in DNS and database systems.

    First of all, almost all the clients I support have multiple redundancies in their local sites and remote sites (so they have multiple sites and multiple DCs/DNS systems per site). Almost 100% of my clients also run AD integrated DNS, so it gets the benefit of the HA/replication of AD.

    So, with that in mind, in these environments there is no reason to distrust DNS, One must ensure that DNS clients are setup with local site and remote site DNS (or via GSLB). This will mitigate any name resolution issues.

    Moving on to authentication: If there are multiple sites and AD is in other sites, there is also no need to worry about authentication via AD. I do agree there should always be local authentication documented.

    So all failure modes should be taken into consideration as usual, and typically AD and DNS are not something a client is concerned with. Static DNS and DCs can be done, but it makes migrations in the future off of those systems more challenging, especially when IPs are going to be changed. I am not saying what you proposed would not work, but is not preferred in my experience.


  2. Hi Daniel,
    thanks for your deep reply, it allows me to further explain my post.
    I’m not saying DNS is to be refused, but in some kind of customers,expecially the small ones where the infrastructure lacks some levels of redundancy, the problem of loosing DCs can also reflect to Veeam operations.
    I agree with you that the best choice is to duplicate and add resiliency to DCs/DNS and be sure also Veeam che gain from central authentication. But it’s not possible in all the environment we face everyday.


Comments are closed.