Skip to main content
  • EN
  1. Veeam server v12.3 installed in VMware virtual machine with Postgresql as VBR database                 48vcpu’s,64 GB Ram,200GB C Drive
  2. have 3 windows physical proxy servers with same configuration of below                               32 cores x 2 sockets= 64 logical processors ,256 GB Ram 
  3. Repository -HPE storeonce deduplication Appliance with 2 storeonce units  connected over       FC(Fibre channel)   500 TB + 600 TB = 1.1 PB                                                                 we have created catalyst stores of 100 TB +150 +250 on unit-1 / 300+300 TB on unit-2.
  4. Vmware infrastructure is like we have 1vcenter contains 112 physical ESXI hosts all are in same network including vbr,proxies,repositories.
  5. we have plan of creating 1000 vm jobs ,1vm per 1 job,but as of now we configured 500 vm jobs.                                                      
  6. most of the jobs are from 500 jobs are targeted to 2 catalyst store of unit1 250 +unit2 300 TB
  7. since past 1.5 months we are facing issues like by 10pm weekly once or twice VBR services are getting stopped unexpectedly& we found the cause in windows events stating low memory issue for that we have raised support case they suggested to do optimization of vbr pgsql database ,AV exclusions in VBR,proxies and we dont have any external antiviruses installed in those systems but we did Windows AV exclusion done,and some registry entries for pg sql connection time increase,did registry entries for heap memory issue as mentioned in https://www.veeam.com/kb1909 but still facing same issue after that again support suggested to do pgsql config file replacement as per 
    You can download from here https://storage2.veeam.com/v1/support?name=File_07825613_7b31552897.zip 

Hello ​@hemanth  Welcome to the Veeam community! 

If you are already working with Veeam support and you are in right track. Based on your environment details, here are a few recommendations from my side:

  • It looks like you currently have 1 VM per job, which will significantly increase the configuration database size and log growth. I would recommend consolidating VMs into fewer jobs (around 10–20 VMs per job) while keeping per-VM backup chains enabled.

  • Limit concurrent tasks to a reasonable number per repository and proxy.
    Each backup task typically consumes about 1 vCPU and ~600 MB RAM on the proxy, so you can size and plan the number of simultaneous tasks based on your proxy’s total capacity and OS overhead.

Terms & ConditionsAccessibility statement