DRM FAQs

 

1.What are the various Disaster Recovery processes that must be accounted for when deploying and managing a DR solution?

A DR solution that is typically deployed between a primary production site and a DR site goes through various states of usage. The various states are shown in the diagram below.

• Normal copy – Production is up and offering services; data is getting replicated to the DR site.

• Failover – Production sometimes goes down in an unplanned manner, causing a disruption in services. Failover is the process of bringing up the application on the DR site.

• Failback – Once the cause of the outage at the production has been fixed, primary production is ready to offer services again. The process of migrating services from the DR site back to the primary production site is referred to as failback

• Switchover – This is part of a DR drill where production at the primary production site is brought down and the application at the DR site is brought up.

• Switchback – Once the application at the DR site has been tested, it is migrated back to the primary site and services from the primary are restored. This is referred to as a switchback.
 

2. How is DRM automation different for using a run book automation tool?

Run book automation typically provides the ability to schedule and run scripts in a pre-determined sequence. The run book automation framework has no prior knowledge of the underlying topology, dependency, and current health of the subsystem on which processes are executed.

In contrast, DRM automation goes through a discovery phase where all the subsystems of a DR solution, their relationships, and the dependency between the primary and DR systems are mapped. DR process automation uses the information gathered during the discovery stage to run its automation. There is a clear separation of the DR process logic that implements the recovery or drill steps and the instance of systems that it is executed on. Therefore, changing some of the subsystem information, such as the host IP address, can be automatically accommodated.
 

3. What is Recovery Management Database (RMDB)?

DRM goes through a discovery phase where all the subsystems of a DR solution, their relationship, and the dependency between the primary and DR systems are mapped. This information is stored in the RMDB. The DR process execution logic uses this information to sequence steps and synchronize execution of the logic. Architecturally, RMDB is implemented as an extension of CMDB.
 

4. How is DRM different from enterprise management solutions?

Traditional enterprise management solutions are used to keep the production systems up and efficient. This includes monitoring, performance, and routine operations on production servers and applications. Sanovi DRM is the only DR-focused solution that integrates with primary and DR components, maps their relationship and co-relates events, automates the DR process, and also monitors DR health, all of which needs knowledge of primary and DR systems.
 

5. What are DR solution signatures?

As part of solution deployment, Sanovi DRM discovers the primary and DR infrastructure, including platforms, applications, and replication technologies. Sanovi DRM compares discovered subsystems and their relationships against known and best-practices DR solutions, such as Oracle protection using EMC SRDF, IBM DB2 using HADR, or SAP using MaxDB. Sanovi DRM offers several pre-packaged DR solution signatures that enable easy and quick deployment and DR process automation that is tested and ready to use.