Skip to main content

Hello There,

 

I just wanted to share an issue I had on one of my customer to avoid others the problem:

We setup a standard Veeam Backup & replication Server on a W2019 VM and a Std SQL 2019 on another one to host the DBs from VBR and Enterprise Manager.

The DBA from the customer insisted to setup an alias for the DB server when pointing Veeam to its Database server as it’s their best practice to facilitate migration (He was obviously not aware how easy it is to move Veeam Database). So he setup a CNAME that pointed to the real SQL server.

The setup went well using the CNAME.

 

We created a “management job” to save Veeam by itself, VBR+SQL servers. The job detected the roles and proceeded as normal but failed on SQL VSS processing.

 

We spent a lot of time to validate that permissions were right (the DBA didn't gave us the sysadmin rights on the backup service account, wise guy) and that the service account on the SQL had the proper permissions too for the VSS writers.

 

Long Story short: I finally used the DBConfig utility and changed the CNAME to the FQDN of the SQL server: No more issue.

 

I think it’s close related to the parameters found used in that KB when working with Always-ON https://www.veeam.com/kb2301 

Veeam Guest Processing on its own DB with an alias: Doesn’t work.

 

No big deal but so you know.

Nice one vChris - this is a great share.


Thanks for share. I have also this type of customer requirements. 


That’s awesome, thanks for sharing @vChris!

I moved this one to Blogs and Podcasts section as it fits great there :slight_smile:  


Thanks for sharing! Was a great read!


Comment