BDRSuite Backup Server/ BDRSuite Offsite DR Server Sizing

Estimated reading: 4 minutes 0 views

BDRSuite Backup/Offsite DR Server sizing involves determining the appropriate hardware specifications and resource requirements for the backup workload. This approach focuses on identifying the amount of CPU, memory (RAM), storage, and network bandwidth needed to effectively run the BDRSuite Backup/Offsite DR Server.

Database Storage

Make sure you have 10% free space available in the DB metadata storage target. For example, if you want to backup VMs with 2TB used data, after storage reduction, approximately 1TB of data will be stored at storage targets. In this scenario, approximately 100GB of free space would be required to store the metadata files.

Storage Repositories

You can use any NAS, SAN, or Directly Attached Storage device to store the backup data. There are no limitations with any hardware vendor. So, we never recommend any specific hardware vendor.

The performance of the backup job depends on the IOPS. So, you will get better backup performance, if you have higher IOPS.

Note: To calculate the required storage space for your environment, use the BDRSuite Storage Calculator

Virtual Machine’s Backup Client Sizing Table

The following tables illustrate how the VMware & Hyper-V backup performance parameters change depending upon the average data transfer rate.

Underlying Assumptions

The estimates provided below are not ‘stretch estimates’; they are safe estimates and are more pessimistic than optimistic. Typical bottlenecks you should look out for are:

Bandwidth bottlenecks
Slowing down of data transfer due to low-performance switches/routers etc.
The hard disk write speeds at the storage target
CPU utilization by other non-related processes running on the BDRSuite Backup Server.

Sizing Tables

BDRSuite Backup Server Configuration

OS	Windows 2012 R2 DC (Physical Machine)
RAM	16 GB
CPU	Intel XEON CPU 2.10 GHz (4 cores)
Network	1 Gbps
BDR Server Version	v5.6.0 U1

Backup Environment

Hypervisor	VMware vSphere
No. of VMs	16 GB
VM data	1 Gbps

Backup Type	VM Data Size	CPU Utilization	Memory Consumed	Total time taken to complete the backup	Transfer rate
Full Backup	2 TB	22 %	3145 MB	383 Mins	803 Mbps
Incremental	55 GB	16.5 %	401 MB	11 Mins	751 Mbps

Note: The above measurements are taken for one backup job with one VM. So, if multiple concurrent backup jobs are active then it will share the memory and CPU. As stated earlier, each backup job will approximately require 500 MB RAM.

It is important to note that there are no inherent scalability restrictions for a BDRSuite Backup Server when it comes to the maximum number of simultaneous backups possible.
If a larger number of backup jobs are simultaneously configured to a BDRSuite Backup Server, then the only effect will be a corresponding degradation of performance in terms of time taken to complete the backup for all the backup jobs.
The maximum number of backup jobs that can be supported by a single BDRSuite Backup Server depends on:
- The bandwidth of the network used
- Time taken for each backup job
For example, the above illustration assumes that backups are typically scheduled during ‘non-office hours’ (hence the 10-hour window); this is not always the case. Especially, if in case the backups can happen non-intrusively in the background while you do your regular work.

Storage Device Throughput And Concurrent Writes

The throughput of Storage devices (IDE/SCSI/SAS/NAS/SAN) is normally benchmarked based on maximum throughput achieved while performing sequential writes into the device.
But when multiple VMs are backed up simultaneously to the BDRSuite Backup Server, then the server will be concurrently writing the different files for different VMs onto the Storage device.

Note: When concurrent writes from multiple threads are being done, the throughput of the storage device determines the BDRSuite Backup Server’s performance.

The reason storage devices do not perform well when multiple threads are writing to it concurrently is that the I/O seek that has to be done between writes from different threads can slow down the performance significantly.
Hence, it is imperative that the storage device used to back up the data is of the highest quality and has the ability to scale and perform well when 100s of different threads write to the storage device concurrently.