Skip to main content

Good day all,

Need some great specs suggestions for creating a suitable VM to run my new backup software. My boss said VM only, nor Bare metal.

What specs are you running in your environment? not the default Veaam sys req online, that is too general. I just need some workable ideas

The answer to this will be “it depends” since you will need to take in to account number of VMs you will back up, data size, Proxy/Repo details, etc.

Using the general specs gives you the best path as you use all of the for VBR, Proxy, Repo, etc. to create a complete VM with enough resources.  I am not a Hyper-V guy so cannot say for sure or would want to throw numbers out there just cause.


Are you creating an ‘all-in-one’ Backup environment (using all Veeam components on the VBR server itself), or are you going to use a more distributed VBR environment (Proxies/Repos as separate components)?

I use a distributed type of setup (no Ent Manager) and have a VBR VM with 4 vCPUs and 16GB RAM. This is inline with System Requirements , at least for the Cores, although I obviously spiked up my RAM. Below should help with sizing a bit:

https://bp.veeam.com/vbr/2_Design_Structures/D_Veeam_Components/D_VBR_server/backup_server.html

https://bp.veeam.com/vbr/2_Design_Structures/D_Veeam_Components/D_VBR_DB/database.html#sizing

Same for me as Chris...I use vSphere, so go with the above with a grain of salt, but the BP Guide generally doesn’t speak about VMW vs HV with regards to sizing.


My model will be the All-in-One. The 4 vCPUs and 16GB RAM sounds pretty ok to me.

Your suggestions?


My model will be the All-in-One. The 4 vCPUs and 16GB RAM sounds pretty ok to me.

Your suggestions?

You will need more than that if the VBR server will be a Proxy and Repo server as well.  Just FYI


@SysEng -

When sizing for the All-in-One model, make sure to add additional compute resources for the Proxy and Repo roles.

https://helpcenter.veeam.com/docs/backup/hyperv/system_requirements.html?ver=120#hyper-v-off-host-backup-proxy-hyper-v-host-as-backup-proxy

https://helpcenter.veeam.com/docs/backup/hyperv/system_requirements.html?ver=120#backup-repository

https://bp.veeam.com/vbr/2_Design_Structures/D_Veeam_Components/D_backup_repositories/#repository-server-sizing

https://bp.veeam.com/vbr/2_Design_Structures/D_Veeam_Components/D_backup_proxies/vmware_proxies#proxy-sizing


Well let me correct myself. I should have really stated scale out lol. Still in planning stage, subject to change

Probably not full blown all in one. 

Here is the structure:

  1. One Veeam Backup Server VM installed on a hyper v host running server 2022 core.
  2. 40 Virtual machines (all servers - db, web srv, other app servers etc) to backup
  3. 1 proxy server vm(external)
  4. Dedicated repo (NAS/SMB) external

 


Well let me correct myself. I should have really stated scale out lol. Still in planning stage, subject to change

Probably not full blown all in one. 

Here is the structure:

  1. One Veeam Backup Server VM installed on a hyper v host running server 2022 core.
  2. 40 Virtual machines (all servers - db, web srv, other app servers etc) to backup
  3. 1 proxy server vm(external)
  4. Dedicated repo (NAS/SMB) external

 

So this helps then with your setup since the Proxy and Repo are external.  You can use 8x16 for your VBR VM and that will be enough.  You can make the RAM 32GB if you find it is constrained but the normal setup will work.


The sizing info I shared still applies, just allocate the needed compute resources to the external Proxy server and Repo server. The VBR server resources I shared initially will be more than sufficient for your size environment. 


Hi, have you got a plan for a second offsite/immutable copy? A NAS might be sufficient throughput for your primary backup but performance is near always lackluster and this could restrict your ability to recover fast enough for business needs. If you are going to use a NAS I’d suggest communicating to it with iSCSI to benefit from multipathing and potentially ReFS/XFS for fast clone support, otherwise use NFS over SMB typically.


It’s hard to give a one-size-fits-all sort of answer, but I do want to note that I had a case open with support last week because I had a backup job to my local Object First repo that would occasionally hang for days before I intervened on preparing the storage.  After pulling logs, it turns out that whenever I looked at my VBR server, it appeared that I had enough RAM allocated, but the logs indicated that I was actually getting down to the low hundreds of megabytes of available memory when jobs were running but it just wasn’t happening when I was looking.  What was once reasonable for my environment, 4 vCPU’s and 8GB of RAM, was no longer after adding several jobs, a lot more data, and more extended features like CDP replication, etc.  I increased to 8 vCPU’s and 16GB of RAM and immediately I was consuming over 9GB.  There was certainly some resource contention there, but I just wasn’t seeing it.  There were a few other tweaks that I had overlooked (like no max number of tasks set on my object repo’s, and upgrading to 12.1.2), but the resource issue appears to have been the major factor.


Comment