We’ve Expanded Our Copy Data Support to SAP HANA

Catalogic 05/17/2017 0 Comments

Our new Catalogic ECX release 2.6 expanded the application support matrix considerably by adding SQL physical hosts, Epic EHR with InterSystems Cache environments, physical server basic file systems (Windows, Linux, AIX) and VMware pRDMs. On top of all these enhancements, we were also tremendously excited to add support for SAP HANA environments.

SAP HANA is an in-memory, column-oriented, relational database management system developed and marketed by SAP. Many of the legacy SAP systems were supported by Oracle and DB2, both of which are also supported by Catalogic for orchestrating DB aware IBM and Pure Storage snapshots. Customers are slowly and steadily migrating to the HANA platform because of the performance improvements afforded by running the database from memory. Storage, however, is the core component of this infrastructure in delivering persistency to data and to support queries that may not have all the necessary data in memory. Combining SAP HANA with Flash storage has allowed customers to achieve several benefits:

  • Substantial increase in performance (of course!)
  • Even higher storage efficiency compared to just HANA’s deduplication
  • Offload at-rest encryption to the storage arrays to avoid HANA’s native encryption.
  • Offload replication to storage instead of log shipping at the HANA level
  • Reduced footprint with lower OpEx cost of Flash compared to spinning disk environments

With the introduction of SAP HANA TDI (Tailored Data Center Integration), customers now have the choice of storage and servers and OS instead of the prepackaged one-size fits all appliance approach. Both our partners, IBM Storage and Pure Storage, have certified storage platforms delivering world-class capabilities to SAP HANA environments. With Catalogic 2.6 and its corresponding OEM versions, we can now deliver application-aware snapshots and recoveries on top of performance and reliability. In a nutshell, our compatibility can be summarized as:

  • Storage: Pure FlashArray (FA, \\M and \\X series), IBM Spectrum Virtualize (SVC and Storwize) and IBM Spectrum Accelerate (XIV) family
  • Servers: Physical and virtual – Intel and Power platforms
  • Operating System: RHEL, SLES and PowerLinux

Here are some key benefits for SAP HANA users:

  • Storage array snapshots complete in seconds what it takes the legacy “Backint” interface to create a backup copy
  • Negligible impact on HANA servers during backup. Queries can run faster even during backups.
  • Completely Agentless. No agents for physical or virtual servers running Power or Intel.
  • Orchestrate app-consistent replication of snapshots for DR by leveraging the underlying storage replication engine.
  • Instant Recovery in case of data loss by utilizing zero-footprint clones from either the primary or replica copy.
  • Flexibility to use Fiber Channel or iSCSI to mount disks during recovery.
  • One-touch recovery back to the original destination by automating the mountpoint handling.
  • Centralized single pane of glass management for Oracle, SQL Server, DB2 and HANA under one umbrella.
  • Monitor RPO compliance through snapshot registration in SAP HANA Backup Catalog as well as Catalogic reports.

As always, let’s wrap up with some screenshots and a link to our demo video. Stay tuned for more storage platform support and additional enhancements covering multi-tenant databases and new features in SAP HANA 2.0 SPS 1.


The first step is to register your SAP HANA servers. The process is simple and agentless. You select the application type, in this case SAP HANA, and provide credentials. That’s it!


Snapshot policies get defined based on SLAs, such as how many snapshots do you want to maintain. One or more policies can then be applied to any workload.


The above screen shows a selected SAP HANA instance, on the left, and the applied policies on the right. It’s as easy and point-and-click to apply protection polices to SAP HANA workloads.


When it comes to recovery, restore jobs are created up front. Assorted options are chosen, pre- and post-script actions can be applied. Once the recovery job is created, it’s as easy as point-and-click to restore data. The same functionality can be used to deploy data sets for dev-test, reporting, etc.  And since everything in ECX is RESTful API enabled, you can also drive recovery and data delivery via code. Self-service options are available as well. We’re all about delivering data when and where it’s needed.

Let us show you around