Ideal server build for Veeam Backup and Replication 8

[unsichtbarre]

I was just contemplating what the ideal or "Best Practices" build for a Veeam Backup and Replication server. Obviously, certain compute and network variables such as RAM, CPU and IP(s) will vary by need, but certainly there must be some common baseline? I am currently working on our internal Veeam server build document for Veeam 8 and would appreciate any suggestions. THX!

Here are some of my Veeam server procedures for comment or addition:

• Windows fully patched and up-to-date
• Automatic Updates disabled
• 2 CPU/vCPU (minimum for very small deployment)
• 8 GB RAM (minimum for very small deployment)
• 60 GB HDD (minimum for very small deployment/Replication only)
• Always use a Domain/local Service Account with the right to Log on as a service (never a local/Domain Admin!)
• Static IP
• Hosts file where local/remote DNS not possible
• Use VMFS 5+ Volumes formatted GPT in Windows as Repositories (I have been avoiding RDM since VMFS 5 supports native volumes of 62TB)
• Create each new Disk/Repository on an unique SCSI controller (1:0,2:0,3:0) and set to Independent/Persistent
• Use the VMware Paravirtualized SCSI driver (pvscsi) for Veeam installed as a VM
• SQL Express installed with Veeam
• Veeam Configuration Backup on a repository external to Veeam Server
• Connect to vCenter using a dedicated Service Account (Service Account may be AD/Windows Local or SSO/PSC; the significance is that one be able to distinguish tasks in vCenter initiated by Veeam)

[jgreenberg]

I would also be interested in the recommendation on the SCSI driver type for hot add-drives. Is there a specific configuration in Veeam that I need to configure to force hot-add disks to utilize a specific virtual SCSI controller?

[unsichtbarre]

I would also be interested in the recommendation on the SCSI driver type for hot add-drives. Is there a specific configuration in Veeam that I need to configure to force hot-add disks to utilize a specific virtual SCSI controller?

You mean as if: "My veeam server VM uses LSI Logic SAS, but my guest VM is VMware Paravirtual, will my Veeam VM be able to read the guest disks?"

[Vitaliy S.]

Hardware resources are indeed very important when building a backup infrastructure, you can follow our system requirements document as a baseline to build your own server. Once you do this, you can start looking into other components of your infrastructure (reported as bottlenecks) to improve it further and have decent backup job performance rate.

P.S. one thing that I wouldn't recommend doing is storing your backups on the VMFS volume. Check out this topic for more clarifications > Don't Store Backups on VMFS...But why not?

[Andreas Neufert]

Placing Backups on VMFS Volumes is definitive no best practice. The idea is to not allow a single software error destroy you source and backup target at same time. If you expeience a VMFS error or misconfiguration your backups are as well affected. So my recommendation is to place only the backups on pRDM devices or InGuest iSCSI disks.

Best Practice is to Format with /l setting.

SCSI type should be selected based on VMware best Practices.
For HotAdd processing mode, you should add at least one compatible SCSI controller for your used SCSI controller at the VMs you wanna backup.

If Veeam Explorer for SQL or Sharepoint are used with Databases bigger than 10GB you should implement a non Express Version.

You will find a v8 Best Practices document in the next weeks on the Veeam Website.

[Andreas Neufert]

I would also be interested in the recommendation on the SCSI driver type for hot add-drives. Is there a specific configuration in Veeam that I need to configure to force hot-add disks to utilize a specific virtual SCSI controller?

Whatever your Storage vendor recommends together with your used Operating System.

[unsichtbarre]

Hardware resources are indeed very important when building a backup infrastructure, you can follow our system requirements document as a baseline to build your own server. Once you do this, you can start looking into other components of your infrastructure (reported as bottlenecks) to improve it further and have decent backup job performance rate.

P.S. one thing that I wouldn't recommend doing is storing your backups on the VMFS volume. Check out this topic for more clarifications > Don't Store Backups on VMFS...But why not?

I can definitely see provisioning a raw LUN and connecting to it with iSCSI/FC for storing backups. I used to do this as standard (and RDM) prior to VMFS 5, and may revisit that procedure on your recommendation!

Reading the referenced post, I noticed that most of the statements seemed to pertain to VMFS3. I wonder if the topic is worth revisiting on VMFS 5? I guess it boils down to:

• are you more protected with a journaling filesystem (NTFS) nested in a distributed journaling filesystem (VMFS 5), or simply a journaling filesystem (NTFS) on a raw LUN?

[Gostev]

VMFS3 vs. VMFS5 makes zero difference in regards to statements made. Why would anyone want to purposely make their backups hard to get to in case of infrastructure disaster? If anything, this choice will have a huge impact on your recovery time.