• Continuous versus scheduled replication
• Efficiency of data transfer
• Block versus file

• Replication configuration flexibility. Organizations are getting more dispersed and more complex all of the time. Common topologies that may be supported include 1 to 1, N into 1, and 1 to N replication, each of which has advantages depending on the problem being addressed.  Some products support only one-way replication, while others may support bi-directional replication.

Multiple different types of storage and operating systems may need to be supported as well. Array-based replication generally only works between storage arrays from the same vendor, while host, application, and appliance-based replication can generally support heterogeneous storage but may impose operating system or application lock-in.  This puts the onus on organizations to find the right product for their environment.

• Overhead. Every replication software product is going to consume resources (memory and CPU specifically) as it does the replication. The issue that organizations need to address is where they want to place that load.

While the answer has historically been on the server or storage array since they have often had unused cycles to spare, as organizations increasingly move towards virtualized environments, excess CPU and memory on these systems are harder to come by.

Appliance-based replication can offer some advantages in high growth environments because of its low overhead, scalability, flexibility, and ability to support heterogeneous environments.

• Creation of recovery points. Replication and data protection are becoming almost inextricably linked as more organizations want to leverage replication for not just disaster recovery and high availability but their day-to-day data protection needs as well. This may include fast application recoveries or using the replicated data as the source for backups to tape.

However to perform these tasks the replication software has to be application-aware so it can support the application-consistent recovery options necessary to provide the fast, more reliable recovery capabilities as well as the ability to offload backups as desired from productions servers.

• Storage consumption. In the same way that all replication software products do not use network bandwidth efficiently, they also do not all use storage space efficiently. This especially comes into play when organizations start to use advanced features available on some replication software products such as continuous data protection.

In these implementations of replication software, all changes are kept for days, weeks or even months depending on the settings. This can consume much more storage capacity than what is in production unless the replication software has some mechanism to efficiently manage the replicated data.

For CDP products in particular, a nice feature to look for that can help reduce storage requirements is a feature called "sparse retention windows" that allow administrators to set policies that establish different levels of data retention granularity as data ages.

• Continuous versus scheduled replication. How frequently the replication software replicates data from point A to point B can vary widely by product. Some replicate continuously and synchronously which means that any time an application writes new data, the write has to complete at both point A and point B before the application can continue processing. This keeps the data in sync at both locations (hence the name synchronous replication) but it can result in degraded application performance if point B is a substantial distance away.

Some replicate continuously but asynchronously. This means the write to point A is completed before the data is replicated to point B. The upside is that this form of replication can support long replication distances between sites without impacting the performance of the primary application. The danger is that the replicated data at point B gets out of synch with point A (albeit only slightly) so some data loss can occur.

Finally some replication software replicates data only at scheduled times - once a day, every 4 hours, every 15 minutes or whatever. Less data may need to be replicated and this method also eliminates the need for application writes to complete at both locations. However there is a greater chance for data loss and for more data to be lost should there be an interruption in replication.

• Efficiency of data transfer. How efficiently the replication software transfers data from point A to point B is a point that is often overlooked. Replication software may not compress or deduplicate the data before it is sent or, if it does, may use only a very rudimentary form of these technologies.

Depending on the amount of data that needs to be replicated and how quickly it needs to be replicated, it is quite possible the replication software may fill existing network pipes with too much data and negatively affect other production processes. This situation may force organizations to purchase an appliance that can optimize this traffic for network replication or obtain a replication solution that provides this bandwidth optimization as part of how it does replication.

• Block versus file. Whether a replication software product supports block or file replication does not make it "good" or "bad" but it is one of the determining factors as to whether or not a product is one that should remain in contention.

Replicating at the block level means that the replication software only replicates blocks of data on the disk so it is mostly agnostic as to what application data is being stored on this disk. While many of these replication software products integrate with specific applications, it is only to provide checkpoints for recovery purposes.

Conversely, file system based replication products are very aware of the data that they are replicating. This allows them to be choosier in the data that they replicate (down to the directory level) but it may preclude them from replicating certain kinds of data such as databases or email data stores.

In a perfect world, organizations will want to select a replication software product that supports both block and file replication so they can implement whatever form of replication that their environment needs.

• Both local and remote recoveries. Organizations need to enable the same or fewer administrators to work more efficiently so they can accomplish more with less effort. To do this, the solution needs to provide a single console that they can use to recover applications and/or application data either locally or remotely
• VSS for application consistent recoveries. To ensure that applications can be recovered rapidly and reliably, recoveries should be performed from application-consistent recovery points.  On Windows, that means the solution must integrate with Microsoft Volume Shadow Copy Service (VSS) to create recoverable copies of the application and its data.
• The recovery of the most common Windows applications. Microsoft Exchange, SQL Server and SharePoint are found in many organizations and considered "mission critical" by them in many circumstances. So out of the box integration with these applications for backup and recovery should be viewed as a prerequisite.
• Any kind of storage that Windows servers can access. Windows applications store their data on almost every type of storage known to include DAS, NAS and SAN. That introduces dependencies and complexities when it comes to doing application recoveries since the Windows recovery solution must account for the data residing on these different types of storage and then be able to recover it.
• Both physical and virtual server environments. More data centers are adopting server virtualization but physical servers are likely to remain an integral part of data centers for the foreseeable future. So any Windows recovery solution must first be able to protect either of these types of environments and then deliver whatever type of recovery is needed, be it physical-to-physical, physical-to-virtual, virtual-to-virtual or even virtual-to-physical.

• Flexible licensing that supports the very granular expansion and contraction of cloud-based services
• Minimal server overhead so it is suitable for both physical and virtual environments
• Scales to accommodate server, storage and infrastructure growth on both the end-user and cloud provider sides
• Multi-tenancy features so multiple clients can securely share the same cloud infrastructure resources
• Heterogeneous support for a wide range of application, server and storage resources

• Recovery. Many organizations are looking to automate DR and implement it in an economical way. InMage gives organizations the opportunity to implement DR plans that not only recover data but can actually recover application services by hosting them in the cloud.  Other interesting "recovery" uses cases revolve around DR testing, something which can now be done without impacting production applications in any way.  
• Test and development. As an alternative to in-house test beds, organizations may choose to meet all or part of their test and/or development needs using cloud-based services, built around the particular application in question, which are provisioned on demand.  If organizations choose to maintain in-house test harnesses, cloud optimized infrastructure still gives them the opportunity to "burst" into the cloud to handle resource utilization spikes without incurring any capital expenditures.
• Production Offloads. This is an interesting and emerging use case where organizations can quickly and easily meet seasonal demand spikes in IT resources, again without incurring any capital expenditure.

This use case certainly applies to companies such as First Data (where I used to work) which handles credit and debit card transactions. Credit and debit card processing companies tend to experience huge volumes at certain times of the year (between Thanksgiving and Christmas for instance) so they have to size their environment for those seasonal loads.

For much of the rest of the year, however, a good percentage of the IT infrastructure needed to meet peak demand may be woefully underutilized. But with an ability to increase the performance of key applications by "bursting" into the cloud for a few weeks or months (effectively leveraging a "hybrid" model), an organization can potentially meet peak demand requirements without having to size their infrastructure for it.  

• Near real time application recoveries performed locally or remotely
• Create consistent copies of application data that can be used as source files for file or folder restores or backup to tape or the cloud for long term data retention without imposing any overhead on production applications
• Non-disruptive testing software upgrades to first see how they might impact production application servers
• Verify that disaster recoveries and application fail overs work as intended
• Recover production applications to either virtual or physical machines

(A)  2x
(B)  3x
(C)  5x
(D)  7x
(E)  10x or more

• The daily change rate of the data on that volume. CDP's purpose is to provide organizations with very granular levels of application recovery. To accomplish that, CDP products capture every application write of data that is new or changed. The key here is how fast the data changes but most organizations will find that their daily change rates for the majority of their applications are in the 2-3% range.
• The retention period of the CDP data. The next question that companies have to answer concerns how long they intend to retain the data under CDP's management. Feedback received from CDP providers like InMage indicates that most organizations retain this data anywhere from 7 - 30 calendar days before it is removed.

• Disk expedites backups and restores
• Disk delivers near 100% backup success rates
• Deduplication reduces the size of backup data stores by ratios of 15:1 or greater

• InMage fixes backup in that it delivers the same high backup success rates that organizations realize when they implement disk as part of the current backup process.
• InMage eliminates "point in time" backups and their associated impacts, reducing data protection operations overhead to negligible levels on both servers and networks.
• InMage reduces backup data stores by only storing changed blocks of data so the amount of disk needed to support CDP is comparable to the storage capacity savings obtained when deduplication is implemented.
• InMage improves recoveries by enabling near-zero recovery point objectives with zero or no data loss
• InMage transforms the backup process by enabling push button like recoveries that occur in 30 minutes or less which can occur either locally or remotely.

• To virtualize their entire environment
• To build a dedicated disaster recovery (DR) site
• To buy any hardware or software
• Dedicate staff to manage and run it
• Take months or years to implement it

• Protect applications on either physical or virtual machines
• Implement a viable DR plan in as quickly as two weeks (or less)
• Recover from any type of disaster regardless of its scope
• Transparently recover individual application(s) within minutes
• Recover application(s) without any data loss

• Most physical machines, particularly Windows and Linux servers, operate at utilization rates in the 20 - 35% range.
• Once consolidated and virtualized, they can run at utilization rates that approach 85% or greater.
• This higher utilization rate leaves fewer resources to run performance-intensive applications like backup.
• Traditional backup approaches can consume 20% or more of the physical server's available resources.
• This problem is compounded if backup jobs on multiple virtual machines (VMs) kick off at the same time.
• Hypervisor-level APIs like VMware Consolidated Backup (VCB) and vStorage are intended to provide low overhead data protection approaches appropriate for virtual machine environments.
• Hypervisor-level APIs lack an application consistency mechanism and can produce only crash-consistent snapshots
• Crash-consistent snapshots are not application-consistent, and therefore introduce two problems:  they may not lead to reliable data recovery and, even if they do, recoveries take longer than they do when application-consistent snapshots can be used  
• Application-consistent snapshots are desirable  for the proper protection and recovery of applications running in virtual machine environments (just like they are for applications running in physical environments and for the same reasons) because they lead to faster, more reliable recovery
• Organizational expectations for near real-time application recoveries (30 minutes or less) are on the rise.

• A central recovery platform that supports both physical and virtual environments.
• Is not tied to any single virtual OS
• Supports heterogeneous applications, servers and storage
• An integrated platform that collects data once but can make it available to multiple different sources for a variety of reasons (recovery, test, development, reporting, data migration, etc.)
• Can move to a differential model that can then make data available wherever and in whatever form it is needed (locally, remotely, block level, file level, or system level)
• Handles application or data recovery locally or remotely by leveraging disk-based recovery and recovery automation to reduce risk and improve recovery reliability
• Supports application-consistent recovery with minimal overhead
• Meets strict RPO and RTO requirements (in the order of minutes)

1. The production applications all run on VMs
2. The source and target physical servers have access to the same networked storage
3. A high speed network exists

• Does physical to virtual (P2V) replication. Organizations can keep their existing production applications on physical machines but recover them in a virtualized server environment - be it a DR or test/dev environment. Using InMage's P2V replication capabilities, organizations can recover physical machines on VMs while enabling test, development and DR VMs to peacefully co-exist.
• Eliminates the need for high-bandwidth network connections and shared storage. These are two distinct drawbacks of solutions like vMotion. While these two issues may be lesser factors when recovering applications locally, these requirements can become cost prohibitive when doing DR remotely. InMage alleviates these concerns by using asynchronous replication which includes options to throttle how much data is sent and when it is sent. In this fashion, organizations can recover applications locally or remotely without incurring huge additional network bandwidth or even storage costs.

• They use InMage's continuous data protection (CDP) feature as their front line method for backup. When backup software makes a copy of data and stores it to disk, it stores it as an image that only the backup software can read and recover. This is less than ideal if you want to re-use the data for other purposes.

Organizations that are fully leveraging the benefits of disk prefer InMage as it stores the data in a format so the application and/or the data it protects are immediately recoverable. This removes the need to introduce the backup software (and backup administrator) into the recovery equation which facilitates simpler and faster data recoveries.

• They test drive running applications in the cloud. InMage does more than make data immediately recoverable locally; it can also replicate the data to other sites (including the cloud) where it is also immediately recoverable. Configured this way, it opens the door for organizations to perform tasks such as more easily test driving applications that they are considering moving to the cloud.

A prime example of this is Microsoft Exchange. Since InMage integrates at the application level with Microsoft Exchange, organizations can replicate Exchange data to the cloud and then recover application consistent images of Microsoft Exchange. They can then run Exchange in the cloud to see how it will work to include failover and failback.

• They create near real time copies of data for testing. Very few organizations that have I talked to or worked for in the past have a well-developed test and development environment for anything but a few mission-critical applications. So when it comes to testing a code upgrade or even an operating system patch on any of their other servers, many system administrators cross their fingers and hope for the best.

InMage creates an entirely new value proposition for these environments. It eliminates cumbersome and time-consuming restore processes because it supports physical-to-virtual (P2V) and virtual-to-virtual (V2V) replication as part of its CDP technology. Used this way, they can temporarily suspend replication to the target and recover the application. They can they use the target as a test bed for installing the OS patch or new version of application software to see how it works before they put their production application at risk.

• A one-to-one relationship. The DR software creates a replication pair. In this configuration, the MSP dedicates a server at its site (physical or virtual) that only receives data from one physical or virtual application server at the customer's site.
• Software licensing. Each server in the replication pair may require a software license which can push the cost of the solution beyond what the customer can afford.
• Management. Managing numerous individual replication pairs becomes complex and tedious. If the DR solution lacks a central console that can manage each replication pair, MSPs have to log into each replication pair individually  to effectively manage it as they scale into the tens or hundreds of replication pairs.

• Business continuity (BC) is the ability for a business to continue all of its operations but especially its critical business functions even in the face of difficult circumstances such as a disaster. An important part of a business continuity plan is recovering and running your business operations at an alternate site. This includes not only DR but also things like how do I get my people there, where do they stay, how do I keep the facility secure, how do I handle communications, etc.  In short, BC can be summarized by the following equation: "BC = IT infrastructure recovery + people + process".
• A disaster recovery (DR) refers to the specific plans and processes that a business puts in motion when a disastrous event occurs be it a manmade (human error, terrorism, war) or natural (earthquake, flood, or hurricane) occurrence. DR is the "IT infrastructure recovery" component in the BC equation and depends on technologies like backup tapes, CDP, replication, etc. to recover at a remote site.