BDRSuite Backup Server/ BDRSuite Offsite DR Server Sizing
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.
|
VMBackup 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 targets
- 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 |
|
- 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.
|
- 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.