Comprehensive & Scalable Disaster Recovery Solutions

If you're basing your existing disaster recovery plans around tapes that you're shipping back and forth between your local sites and one or more offsite storage facilities, then you already know that using tapes for recovery leads to days' worth of data loss, recovery times that can take from days to weeks, and recovery reliability issues that (for whatever reason) mean you can't always get back the data you need.

Asynchronous replication can be used to structure disaster recovery plans that eliminate tape handling, support recovery operations that allow you to recover from very recent data states (at most several minutes old), and shorten recovery time frames to minutes or hours. Replication uses disk as the recovery media, addressing recovery reliability problems associated with tapes and tape handling.

Recovering data provides a foundation for disaster recovery, but not a comprehensive solution. Data is useless without applications up and running to use that data, and DR plans must cover both. If your application recovery plan is based on manual recovery efforts that require sophisticated administrative expertise, you are introducing risk into your recovery plans unnecessarily. By using automated application recovery (when full application recovery is required), you rely on tested processes that are proven reliable, that do not depend the skill of the administrator, and that will bring your applications back to life faster than complex, manual efforts.

InMage leverages several foundation technologies, including continuous data protection (CDP), asynchronous replication over IP, application-specific failover/failback processes, and WAN optimization technologies to provide a comprehensive DR solution that covers both applications and data. Because of the way InMage captures data from applications being protected, may of our customers can replace multiple existing software footprints (backup agents) and products (conventional clustering), simplifying their existing environments while lowering CPU utilization, maintenance headaches and support costs.

When InMage is set up purely as a DR solution, it streams changes in protected application data immediately to a local target (the InMage CX) and then from there immediately to a remote repository target (a server with attached disk storage). The InMage repository at this remote site is kept current with changes to production data at the local site(s), and when data recovery is required, allows administrators to immediately access the desired data, send it across the WAN back to the local site, where it is copied over to the production server that needs it. Many customers add a local repository target (again, a server with attached disk storage), using InMage's 1 to n replication capability to maintain the local repository as well as the remote one. The local repository supports even faster recovery capabilities since recoveries do not have to traverse the WAN when they're required. By maintaining two repositories, customers take advantage of faster recovery for the most common, object-level recovery requests, but have data available remotely for recovery as well if the primary site is destroyed or otherwise incapacitated by a catastrophic event.

To support application recovery, InMage supports several options. InMage can restart any application service at any location where a repository exists. Productized recovery capabilities which prepare the selected AppShot (or recovery point), start the application and any related services, mount the AppShot, and then update AD and DNS entries are available for key enterprise applications, but can be enabled for literally any crash-tolerant application (an application which employs reliable logging or journaling). Customers can set up configurations that can perform the application failover/failback in several ways:

  • Primary site to remote site and back
  • Primary site to local site and back (a shared nothing alternative to conventional clustering products)
  • Primary site to either remote site or local site and back, depending on the nature of the disaster being recovered from

Potential Concerns With Using Replication for DR

In providing for DR, companies may have certain concerns. Here's how InMage addresses these:

It's too expensive, that's why we're still using tapes.
What we've found in many of our customers is that tapes impose a lot of costs that may not be readily evident. How much does it cost in operator time to administer tape-based backups each day? What is the impact to production operations during the periods that backups are running? Do you have the right personnel to reliably handle tapes in remote locations? What are the costs when those tapes are not reliably handled? How much does it cost your company when you go to do a recovery from your remote site, and you have lost 4 days of business transactions and the recovery takes another 5 days? Even at their best, tapes only provide for data recovery. How much time and effort does it take to manually recover applications at a remote site in the event of a disaster? Do you have to rebuild front-end infrastructures because you are not protecting any of it with your backups? Is recovery time and reliability very dependent on who's actually doing the recovery? Do you know how much it costs your company per hour when critical services are down? If you do, it's very easy to look at how much lengthy recovery times have cost your company in the last couple of years, and compare that to the cost to deploy InMage. Relative to tapes, InMage will eliminate backup impacts to production environments, drop data loss on recovery and recovery times from “days to weeks" to "minutes to hours", and improve recovery reliability considerably. It will save a lot on administrative time that today is required for tape handling. It can be used to implement DR, eliminate backup agents on production servers, and replace conventional clustering products all on a single platform. When all that is taken into account, InMage will save you considerable money.

Array-based replication that requires the same type of storage array in source and target locations is very expensive, and does not support heterogeneous storage. Appliance-based replication does lower the entry price point relative to array-based replication, while at the same time providing support for asynchronous replication and heterogeneous storage. But appliance-based configurations generally require that appliances are deployed in pairs; appliance-based replication replicates appliance to appliance, and if an appliance fails, then everything stops.InMage uses a unique hybrid recovery architecture that supports block or file based asynchronous replication, heterogeneous servers, storage, and storage architectures, and supports entry level configurations that require only one local network target. This local target (the CX) is running InMage  software on any Intel-based, 2 CPU server, but it is not an appliance in the general sense of the term; the CX acts as a way station for data, it is not storing it. InMage supports heterogeneous storage, preserving investment in existing hardware and software, and providing maximum flexibility for adding new hardware into the configuration over time.The combination of technologies we are using requires very little bandwidth, thanks primarily to the synergy between block-based data capture and transmission, CDP, and various WAN optimization techniques like TCP optimization, bandwidth shaping, and compression. These features support a very low entry price point for a single solution that covers both application and data recovery, both remotely (for DR) and locally (for backup).

My network bandwidth is limited, and may not be able to support replication.
Let's address this question in two parts: impacts on LAN bandwidth, and then impacts on WAN bandwidth. The local hop between production server source(s) and the CX is where InMage is using CDP. Writes are asynchronously sent across the LAN as they occur, so we completely avoid the "pig in the snake" problem: we're not trying to shove all updates since the last backup across the LAN at the same time, we are dribbling them across as they occur. This takes up very little bandwidth at any one point in time, and for all except the most write-intensive applications will hardly be noticeable relative to other LAN traffic.

The remote hop between the CX and the remote repository target leverages block-based, asynchronous replication as well as a number of other WAN optimization technologies that reduce that amount of data that needs to be sent across the network to support very granular recovery operations. InMage uses WAN acceleration techniques like TCP optimization and compression which, when combined with the fact that we are only ever sending data changes (after the initial sync operation), result in limited bandwidth requirements to support even large applications. In addition, the CX employs bandwidth shaping algorithms that implement quality of service policies relative to other traffic across the WAN, allowing administrators to control the impact InMage traffic has on other applications that use the network.

I've already deployed a conventional shared disk clustering product locally, can I leave that configuration in place and just use your product to set up disaster recovery and eliminate backup impacts?
In a word, yes. InMage transparently accommodates failover/failback between local cluster nodes without losing anything in recovery granularity, speed, or reliability.

Host-based replication doesn't scale well and imposes too much overhead on my production servers.
We agree with you, which is why we developed our unique, hybrid recovery technology. We are not host-based replication. We off-load most of the processing associated with our solution to the CX; the data tap is merely splitting off writes as they occur, a process which requires very little CPU on the production server source(s) even for write-intensive applications. This "host off-load" model allows us to deploy much richer functionality than you would ever find in a host-based replication solution, because all the resources used to drive that functionality are in the CX, not on the production server source(s). This design allows us to scale gracefully without imposing any additional overhead on production server source(s) as configurations grow, regardless of whether that growth is in numbers of servers or storage capacities on each server.