Storage Boards Cleanup
To make it easier to find information about HPE Storage products and solutions, we are doing spring cleaning. This includes consolidation of some older boards, and a simpler structure that more accurately reflects how people use HPE Storage.
Around the Storage Block
Showing results for 
Search instead for 
Did you mean: 

HPE RMC Performance Benefits vs. Traditional Backup ISVs: Why Is RMC the Faster Solution?



HPE RMC 4.0 signifies a new paradigm for backup and restore speed.  Let’s see how RMC delivers on this promise with real-world performance testing.  

With the advent of all-flash storage systems in the data center and the continued dramatic growth of data volumes, traditional backup approaches are likely to reach their limit or at least are prone to become a bottleneck for RMC Performance_blog.jpgIT operations. HPE storage has brought a solution to market that optimizes the backup and restore operation by directly ‘coupling’ HPE StoreServ 3PAR to HPE StoreOnce systems. One of the promises of this new backup/restore paradigm is improved performance compared to the traditional approaches using backup ISVs. In the following, let’s see how HPE Recovery Manager Central (RMC) fulfills these promises.

Recovery Manager Central (RMC) is a data protection solution which moves block level HPE StoreServ 3PAR volume snapshots from the array to a HPE StoreOnce Catalyst backup appliance. Traditional server based backup software products back up data by reading from the source system using the available interfaces for backup. These application/system protection APIs take various different forms based on the data being protected: Microsoft volume shadow copy, the SQL writer interface for Microsoft SQL Server, the Oracle Recovery Manager Application interface or the SAP backint interface for SAP HANA.

Recovery Manager Central uses HPE StoreServ 3PAR technology to read fixed data blocks from the disk array and that data is then delivered using available SCSI pathways (FC or Ethernet). Therefore, RMC is not limited by application APIs. Due to its built-in deduplication capability and the snapdiff integration, it can deliver backup data in a very efficient manner. The HPE StoreOnce appliance is able to create a virtual full from the deduplicated snapdiff data that it receives. Of course, with RMC’s application integration it does ensure that the application goes through a quiescent phase (the application is made “ready” for backup) in order to ensure consistency for recovery.

Let’s dive in to show the performance difference between RMC and traditional backup ISVs.

As the purpose of this investigation is to show the performance difference between RMC and traditional backup ISVs, an infrastructure setup was chosen that allowed the respective solutions to perform without infrastructure bottlenecks. Below is a graphical representation of the environment. Care was taken to perform an apples-to-apples comparison in order to provide measurement results close to those that a real production environment would see under similar circumstances. Backup and restore tests were conducted across a variety of applications including:

  • File Systems
  • Virtual machines on ESXi 6.5
  • Microsoft SQL Server 2014
  • Oracle DB 12c R2

RMC Performance Diagram 1J.jpg

In the following, we present a selection of tests results. Each test included multiple backup runs with application data being modified (3% change rate) between runs.

The below chart shows the backup speed for Virtual Machine backups across five subsequent backups. The initial backup run performance is irrelevant in real life as with RMC you would only have an initial (seed) run once. All subsequent runs are virtual fulls. RMC shows a backup performance lead of about 4-to-10x.RMC Performance Diagram 2J.jpg

  • Blue Line: traditional backup ISV
  • Red Line: traditional backup ISV with advanced VM backup functionality
  • Orange Line: RMC for VMware (RMC-V)

Let’s look at the backup statistics for an application backup: MS SQL Server in this case. The difference is not as drastic in this case but still RMC shows a performance lead of about 3-to-4x.RMC Performance Diagram 3J.jpg

  • Blue Line: traditional backup ISV
  • Orange Line: RMC for SQL (RMC-S)

Having looked at backup performance, now let’s compare some restore numbers.

In this study, we are comparing performance for a FULL restore operation.RMC Performance Benefits Table 1J.jpg

In this scenario, RMC shows a 3x lead when it comes to restore performance. For a file system restore, the following could be observed. RMC Performance Benefits Table 2J.jpgAgain, RMC shows a lead when it comes to restore performance and therefore RPO. In this case by a factor of close to 7x. Being able to reduce backup windows by 7x can obviously make a huge difference in IT operations.

So why is it that we see higher restore performance using RMC compared to traditional backup ISV schemes?

And why does RMC allow shorter Recovery Point Objectives (RPO) than backup software in most situations? Let’s look at the file system example provided above:

  • Backup ISVs will attempt to avoid multi-stream restores for a filesystem because restoring using multiple streams could potentially cause data corruption due to overwrites and the ability for each stream to cross another’s path.
  • The other reason is that when an ISV needs to restore data, it must work via a pre-determined media interface, e.g. a media server. The need to go via this route requires that the media server requests data from the backup media, which the media will then send to it. Then it is the responsibility of the media server to forward that data onto the relevant recovery recipient. RMC does not suffer from this limitation as the data is forwarded, in a predictable manner, to the storage array with the same amount of streams that it was backed up as.

So, ultimately, RMC’s speed advantage comes from:

  • A shortened – direct – data path without constraints imposed by the media server and/or application-specific backup interfaces
  • Multi-streaming (transparent to the application/user)
  • Capability to leverage the 3PAR snapdiff information to provide full backups at the speed of incremental backups

So if you have backup windows that are out-of-bounds or the need to shorter restore times to hit RPO targets, then considering a change in backup methodology from a traditional approach to a flash-optimized and tightly integrated scheme might be a sensible thing to do – especial as RMC licenses are included with your HPE StoreServ 3PAR purchase.

Find out more about HPE RMC 4.0


Tilman Walker_HPE Storage.jpeg

 Meet Around the Storage Block blogger Tilman Walker, Manager, Technical Marketing Engineering, HPE Storage.




  • 3PAR
  • data protection
  • flash storage
  • RMC
About the Author


Our team of Hewlett Packard Enterprise storage experts helps you to dive deep into relevant infrastructure topics.


Has anything in RMC 4.0 improved the hba pass through requirements of both the sql servers and the rmc virtual machine? While the HBA passthrough on the virtual machine is dealable, the one that requires the sql servers themselves have pass through hbas as well as direct attached luns in a virtual environment nearly impossible to use in traditional vmware environments where disks are split out of datastores. This was the killer in our environment for usage of RMC3 for sql.

Is there a plan for direct connectivity between 3par and storeonce appliance instead of requring a proxy in the RMC virtual machine? 



Dennis Faucher

Thank you for the article. Are there any differences in Catalyst use that would make the Traditional ISV slower than RMC? 


Dear Jon & Dennis,

thanks a lot. I really appreciate your comments and questions. Let me try to answer them here:
1) RMC v4.0 and pass-thru
No changes rgd. pass-thru with respect to RMC on ESXi. However, we do now support RMC(-x) being deployed on Hyper-V and that does not face the same restrictions. This really boils down to hypervisor functionality. 

2) RMC-S 
As you state, RMC-S requires the MSSQL VM to either use RDM or iSCSI/FC direct. RMC-S today does not support a SQL VM using SQL volumes on a datastore. The product management team is investigating the feasibility of adding this functionality. 
Our recommendation today is to use RMC-V whenever the SQL Server is virtualized on VMFS. You will need to use the VMtools to quiesce the application, of course, and logs will have to be truncated manually (scripting). A restore would happen via RMC-V ERT (element recovery technology). RMC-V ERT can be used in combination with the *free* Veeam Explorer for MSSQL to allow more granular restore operations. We can provide detailed slides on this in case of need. 

3) HPE StoreServ 3PAR to HPE StoreOnce direct path
We are investigating options for having a direct connection between 3PAR and StoreOnce. 

4) RMC performance vs. traditional backup ISV
In all the configurations that we have tested (and there were numerous across a broad range of applications), RMC always showed higher backup and restore performance compared to traditional backup ISVs. Reasons are - as stated in the blog:
- RMC optimizes the data path (3PAR--RMC--StoreOnce)
- RMC provides multi-streaming operations even for environments (like file systems) where traditional ISVs would not support it and/or setup would be more cumbersome
- RMC implements a unique 'snapdiff' functionality. Before a backup job starts, RMC gets the snapdiff information from 3PAR. It then only transfer the delta data and StoreOnce re-assembles pointers to create a virtual synthetic full. Traditional backup ISV might have delta tracking capabilities but not the tight product integration that RMC/3PAR provide.

 Hope this helps and provides more clarity. 


Tilman Walker

28-30 November
Madrid, Spain
Discover 2017 Madrid
Join us for Hewlett Packard Enterprise Discover 2017 Madrid, taking place 28-30 November at the Feria de Madrid Convention Center
Read more
See posts for dates
HPE Webinars - 2017
Find out about this year's live broadcasts and on-demand webinars.
Read more
View all