With the introduction of Postgre SQL as the “embbeded” database in Veeam Backup & Replication 12, several new deployments now use the default database in the same machine of Veeam Backup Server.

I don’t want to consider in this post all the pros and cons of the embedded approach.

But it’s fully supported and can can also to an interesting number of protected workload (tested with more than 1000).

But in this deployment scenario there are some possible points that must/can be considered.

Resource sharing

By default, the Postgre SQL installed automatically with Veeam Backup has already some settings to limits CPU and RAM to limit the contentions of those resources.

If you change the CPU/RAM settings of your Veeam Server, remember to use the cmdlet Set-VBRPSQLDatabaseServerLimits to adapt those settings, as explained in this documentation page.

The easiest way is just run the cmdlet from the Backup Server:

This command will generate a postgres.auto.conf file in the data folder of Postes SQL installation. Do not edit this file manually!

For the storage contention, a simple way could be put the database on a dedicated disk (remember also to consider a dedicated disk for the Veeam Backup Catalog).

Service Dependecy

Without the database, the Veeam Backup Server cannot work at all.

For this reason could be useful put a Windows service dependecy that is not added by default:

A fast way to add it (avoiding to edit manually the registry) is using PowerShell. The two properties that have to be considered areDependedServices (automatically created) and the ServicesDependedOn:

Considering that the Veeam Backup Server service is named VeeamBackupSvc, the syntax to add the dependecy is:

Set-ItemProperty 
  -Path "HKLM:\SYSTEM\CurrentControlSet\Services\VeeamBackupSvc" 
  -Name DependOnService 
  -Value @("Winmgmt","RpcSs","postgresql-x64-15")

Funny that the Set-Service cmdlet does not have a specific option to add it in a fast way.

Note: another way is use the sc command.

Another aspect to be considered is the recover in case of service interrution. By default, the database has no recovery option set at service level, but you can change them:

The type of recover, of course may depend by your policy and choosing to restart the entire machine could be rude… but if service does not restart after several retry, maybe it can an option.

Embedded or external?

However, since v12 is the first version to support PostgreSQL, it is still recommended to use Microsoft SQL Server (maybe external) when you backup more than 5000 VMs.

Refer to the flow chart below for the best choice matching your environment.

Also, if you have implemented High Availability as discussed in Database placement section and you have no licensing concerns, there is no hard requirement to migrate to PostgreSQL. Finally, if you are in a complex environment with multiple Veeam Backup & Replication servers and Veeam Enterprise Manager, consider that all of them must use the same Database Engine.

Andrea Mauro

Virtualization, Cloud and Storage Architect. Tech Field delegate. VMUG IT Co-Founder and board member. VMware VMTN Moderator and vExpert 2010-24. Dell TechCenter Rockstar 2014-15. Microsoft MVP 2014-16. Veeam Vanguard 2015-23. Nutanix NTC 2014-20. Several certifications including: VCDX-DCV, VCP-DCV/DT/Cloud, VCAP-DCA/DCD/CIA/CID/DTA/DTD, MCSA, MCSE, MCITP, CCA, NPP.