Link

Veeam Backup Repository Design

Best Practice

  • Ensure you comply with the 3-2-1 rule
  • Physical Repositories are recommended where possible, ideally combined with proxy role using backup from storage snapshots.
  • Calculate 1 core and 4GB RAM per repository task slot. The recommended minimum for a repository is 2 cores and 8GB RAM.
  • Virtual proxies should have anti-affinity rules applied to ensure separation.

Repository Server Placement

The Veeam Backup Repository is highly flexible in where it can be located as the primary copy can be held either with the production data or in secondary site (on/off-site backup).

The key recommendation is to follow the 3-2-1 rule.

  • 3 copies of the data (Production, Backup & Backup-Copy)
  • 2 different media
  • 1 copy off-site

Repository Server Sizing

In mid-sized or enterprise environments, the recommended amount of CPU for a repository is 1 core per concurrent configured task slot on a repository server. Configure at minimum a 2 core and 8GB RAM repository server to allow the operating system to be more responsive.

It is recommended to configure a minimum of 4 GB RAM per core. The same amount of resources are needed for gateway servers. Also, consider that VM recovery processes (Instant Recovery, FLR and others) require sufficient resources.

When sizing task slots on a repository you have to understand when and how many task slots are consumed. Any write process will consume a task slot. So backing up 10 VMs in one job using per-job backup chains will only write one file (VBK/VIB) in the end - so it consumes one task slot.

Running the same backup job with per-VM backup files will create one file per VM and thus can leverage up to 10 tasks slots (when available).

Backup Copy Jobs, Agent Backups and Plugin Jobs do also consume task slots and should be considered.

Note: A task at the repository level is consumed differently than tasks at the proxy level. If “per-VM backup files” is enabled on the repository, each concurrently processed VM will consume one repository task, while each virtual disk of this VM will consume one proxy task (typical ratio is 3 disks per VM). On the opposite, if “per-VM backup files” is disabled, a single backup job will consume just one repository task regardless how many VMs are being processed by the job. But the number of consumed proxy tasks will stay the same (one task per each virtual disk).

The repository core requirements can be calculated from the proxy core requirements, see the Backup Proxy Design for details.

If the core requirement for the proxy is 16 cores for the incremental, the cores for the repository will be 5 based on a 3:1 disk to VM ratio (rounded up). To calculate the RAM this is then multiplied by RAM requirement of 4GB per core which results in 20GB.

When your calculation result is a very small (virtual) server please consider additional resources for OS overhead (1 Core/4GB RAM additional should be enough). Normally sizings tend to be at minimum 4 Cores/16GB for virtual servers or physical servers with >10 Cores and 64GB of RAM where enough resources are available for the OS anyways.

When using the Windows ReFS file system the recommendation is to add 0.5 GB RAM per TB of ReFS storage. However, you don’t have to scale this indefinitely. 128GB of RAM are often sufficient for task, OS and ReFS requirements if the total ReFS volume size of the server is below than ~200 TB. Depending on the ReFS size or task requirements you may want to add up more memory but there should be no need to go over 256 GB.

Physical or Virtual?

In general we recommend whenever possible to use physical machines as repositories, in order to maximize performance and have a clear separation between the production environment that needs to be protected and the backup storage. It is also recommended to combine this with the proxy role if backup from Storage Snapshots is possible. This keeps overheads on the virtual environment and network to a minimum.

Virtual Repository Considerations

If you choose to use a virtual machine as a repository or gateway server, keep in mind that the storage, the associated transport media and the network will be heavily occupied.

Best practice is to avoid using the same storage for backups that is used for the virtualized infrastructure, as the loss of this single system would lead to the loss of both copies of the data, the production and the backups.

The available network and storage bandwidth of the hypervisor needs to be considered when using a virtual repository.

Also take into account that multiple virtual repos may be running on the same physical hypervisor and its links, so you also need to consider using vSphere DRS (anti-)affinity rules to keep those repos away from each other.


References


Table of contents