This offer really highlights the potential cloud storage has to help companies or local governments get fast and easy access to disaster recovery capabilities they could never afford in the past.  No hardware to buy, just download the software, map the drives and start a copy process.  Robocopy is free and you already have it, so no investment there.  And I’ve used the Nasuni software – I am certainly no system administrator but I was able to figure out how to add files and create snapshot copies, as well as restore from snaps, pretty quickly.  And because the environment is virtual – getting up and running in the event of an actual disaster can be done by spinning up a virtual machine from anywhere, provided you have the proper credentials.

This offer gave me one of those head shaking moments where I sit back and think about just how far technology has advanced in these recent few years – think about what it would have taken just 3 or 4 years ago to create a DR site and actually get back up and running in the event of a disaster - the remote site, hardware (servers and storage), advanced storage arrays capable of creating remote mirrors or host-based replication software, the software licenses and management overhead.  The cost and complexity of creating that type of environment is far beyond what many small to mid-sized companies could afford, never mind what state and local government budgets can pay for.  The cloud changes everything, this can all be bought as a service, in a shared model to lower administrative and capital costs, with near perfect economics (100% utilization).

Other vendors can learn from this example.  Aside from the obvious user benefits, this offer is also a good example of innovative marketing, presenting an offer that can really make a business impact to help users with true business issues – disaster preparedness and, if needed, recovery.  Steve blogged a while back about how technology marketeers are promoting cloud everything without tying solutions to business needs and items that users actually create a budget line item for.  This Nasuni offer is a great example of someone hitting the mark.

You can read Terri’s other blog entries at IT Depends.

Is Data Replication Enough?

When asked about HA/DR planning, many IT managers immediately think about data replication tactics such as tape backup, off-site vaulting, and remote data replication. However, as important as an organization’s data is, it is only a part of the broader requirement for business continuity.  Even if the data is recovered, it is virtually useless if the appropriate application is not up and running. Similarly, applications need to be protected from system failures, human error, and natural or man-made disasters.  This paper examines strategies that help organizations measure the importance of applications (or the impact of their lack of availability) to their business, followed by a discussion of common HA/DR configuration options.

Business Needs

Successfully aligning an IT infrastructure to business needs in the context of HA/DR planning requires far more than executive-level oversight.  Business metrics for success and failure must be specifically linked with the details of both an infrastructure’s current and desired states. It’s the archetypal “do more with less” dilemma, only now with the added challenge to “do it better” as well.  Looking for economic and operational advantage must be balanced with the need to adequately protect data and applications. The highest priority applications to be protected are shown in Figure 1 and can clearly be seen to be at the very heart of any organization.

Protection Balanced Against Business Value

As the saying goes, you cannot manage what you cannot measure, so two things are important before anything else. The first is for a user to know the hardware and software required to manage and deliver IT services; and the second is to know the requirements to protect the business.  Both require financial linkage through measurable objectives to serve the business optimally.  One measure serves to enumerate the value that an application returns to the business when it is running and the other enumerates the expense to the business when it is not. Their values aren’t the same. Generally, the cost of application downtime over time is far greater than the potential revenue the application can create when running.  Therefore, the technologies used for business continuity can be thought of as “protection architectures.”

The first objective in setting the goals of an investment strategy for these protection architectures is to develop a cost justification model for the expenses required to protect each application. If the expense to protect the application is greater than the value the application provides to the business, plus the cost to recover it, then optimizing the protection architecture to reduce the expense associated with protection is in order.

From Value to Architecture

To build appropriate protection architectures, IT managers must know the business value of the applications they are trying to protect and align that with technologies that results in a cost justified level of protection. It is important to make an implicit point explicit here: not every application deserves the highest level of protection money can buy. That seems reasonable, even obvious. However, in countless data centers, there is a desire to deploy a HA/DR plan with a “best that money can buy” mentality, even though that can exceed the practical needs of many applications. Often—whether because of a lack of personnel or simply too many demands placed on the personnel that exist—there just isn’t enough time to think sufficiently about efficiency, which results in many data centers adopting a “one size fits all” strategy.  And not that many vendors are going to complain about users buying more than they could, or should, have!

So, if you wanted to get it right, where would you start?

Pragmatic Analysis and Planning

Step one, without a doubt, is to have a scheme to characterize and balance the value of the applications to be protected against the cost required to protect them. Different applications will have different values, but as they are analyzed, trends will begin to emerge.  That is the time to assign applications a “protection class of service” justifying the protection cost, linked to a reference architecture that contains cost to a known technological approach.  Think of it as a blueprint.

The best way to put some structure around the blueprint is to set some parameters for how you intend to protect each application; setting recovery objectives can do that. Recovery objectives include two major measurements that are used as the foundation for building protection architectures:

1. The Recovery Time Objective (RTO) is the duration of time and a service level within which a business process must be restored after a disaster (or disruption) to avoid unacceptable consequences associated with a break in business continuity.  For example, the RTO for a payroll function may be two days, whereas the RTO for sales order processing may be two hours.
2. The Recovery Point Objective (RPO) is the place in time (relative to the disaster) to which you plan to recover your data.  Different business functions may have different recovery point objectives.  RPO is expressed backward in time from the point of failure.  Once defined, it specifies the minimum frequency with which backup copies must be made.

As the data in Table 1 shows, RPO and RTO objectives can be used as a guideline by a system administrator in order to ensure that an organization is employing the appropriate protection tiers to meet the various application objectives.  The use of protection architectures defines how HA/DR solutions are used to physically and logically protect the applications to meet service levels defined by the RPOs and RTOs.

What to Look for in Optimum HA and DR Implementations

Once a business impact analysis has been completed, it will be apparent that not all applications are equal and that different applications should be mapped to different protection tiers. Of course, if resources were fully abundant and/or free, then everything could have the best possible protection: since that is never the case, the intent of all the planning is to ensure that the available resources are allocated in an optimum fashion to the various applications (from the invariably revenue-impacting “tier-1” through to less vital materials on tiers 3 and 4). The constraints that limit the world from being perfect range from the pragmatic (such as cost, number of sites, and data growth) to the more prosaic (such as process errors, virtualization, and the need for testing).

Even when the business impact analysis has been done well and the resources allocated optimally, there is unfortunately still plenty of room for things to go wrong and throw a spanner in the works of all the apparently wonderful RTO and RPO planning. And users know that there’s not a lot of room for error. ESG research shows the very tight parameters that businesses are working with—53% of the respondents to a recent ESG survey said their organization would suffer significant revenue loss or other adverse business impact if their Tier 1 applications were unavailable for anything from no time up to one hour.[1] And even a slight deterioration in that RTO objective would rapidly make things worse; some small issue that took downtime over one hour (but still less than three) would cause the “significant negative impact” to apply to an additional 21% of tier-1 applications. Not to mention that, by this stage, nearly half (47%) of tier-2 applications would also produce significant adverse impacts for their organizations. And what might the “small issues” be that could cause deterioration in the recovery time?  The range covers awareness of the issue; not having some mix of the right people, configurations, or patches available; and actual error diagnosis.

All of this leads to the realization that effective HA/DR needs to be supported by solutions that can help avoid the negative impacts of small things destroying a plan that was based on good diagnosis and looked great on the whiteboard! Such solutions which can dramatically enhance and protect application availability should do the following:

• Automate the process: while most users will want to be notified that the system is being recovered per whatever plan is in place, automation is a good way to ensure that pressure and mistakes don’t become a cocktail that causes errors to creep in to the HA/DR execution; automation reduces errors and will usually speed the process as well as reducing the reliance on specific individuals and teams.
• Accelerate the recovery: anything that can improve the speed of failover is invariably going to be a good thing. This will, of course, involve automation, but should also include solutions that mean failover is less of a move to something else and more of a switch over to something else that’s already there—this, if you will, is like having the spare tire already fitted rather than having to pull over, jack up the car, and fit it (even though it could be argued that having an available and suitable spare at all is at least some level of DR!). Put another way, the best form of reconnection to a new application and storage is no actual reconnection at all; merely a switch to another available connection.  
• Ensure advance and regular testing: both of the readiness and appropriateness of the response; readiness is testing that the system is functional, while appropriateness is testing that the system is fit for purpose.   The above solutions—in combination with a thorough business impact analysis—will provide an overall “best practice” approach to HA/DR … and help many an IT manager sleep better!

Symantec Offerings

While the purpose of this paper is mainly to inform users of what to look for with HA and DR, Symantec does have an impressive set of solutions to address the needs that have been outlined. While the key components are briefly summarized here, there is considerably more explanation of how they all function in the appendix to this paper:

• Veritas Cluster Server (VCS): this solution adds useful functionality to the basic automated failover requirements—it can move applications to the node that is most able to accept the new workload and can do that at local, synchronous (up to 100km) or asynchronous distances, utilizing either a spare node approach or rebalancing across all available nodes. Because Symantec tends to agnosticism whenever it can, the actual data can be replicated using just about any tool the user wants.
• Veritas Cluster File System: this is what provides the accelerated recovery; the clustering of file systems avoids many of the recovery steps involved in “classic” recovery processes (such as unmounting a file system, deporting and importing disk groups, and remounting the new file system) by, to continue the analogy, having the virtual “spare tire” already mounted.
• Fire Drill (this is in VCS) / Disaster Recovery Advisor: these are the testing solutions. The former can simulate a disaster to ensure that the clustering and failovers will work properly when needed; the latter supports VCS, but is separate and is all about whether the HA/DR configurations are fit for purpose. To use an analogy, rather than testing whether all the fire extinguishers and escape routes work (that’s Fire Drill), it calculates whether the available extinguishers and escape routes are sufficient to cope with a potential fire and the number of people to evacuate.
• Veritas Volume Replicator (VVR): which provides application and storage hardware independent long distance data replication. Volume Replicator offers flexibility to choose any mix of SAN based storage architectures and replicate data over existing IP networks; this enables the implementation of lower cost storage at the DR location, which can result in significant savings.

The Bigger Truth

As is so often in IT, laborious work is required to achieve the payoff of an optimum HA and DR strategy. Knowledge of the applications and their business needs and impacts is first and foremost. And then the art of possibility and pragmatism must be applied to the science of the facts. Choices must be made, especially if the resulting plans are to be done in an “economically optimum” manner. The solutions that Symantec offers can certainly help, especially since the company is agnostic in terms of the applications and server/storage hardware with which it has to work. Having essentially one tool that can cover HA and DR across a wide range of applications and scenarios and distances is an advantage that many users would value and do well to investigate.

However, the most important thing for users is to realize that planning and thoughtfulness are key to this process; the title of this paper refers not only to the “right” HA/DR, but also to “implementing” it. Like any insurance policy, it is not always fun to discuss or to pay for, but also like any insurance policy, it is equally important not just to have one, but to ensure that the one you have is adequate for your needs and that it is going to work properly when needed.

ADDITIONAL NOTES: COMMONLY USED HA/DR CONFIGURATIONS

The following information is designed to add additional technical detail and insight to the business aspects covered in the preceding ESG Brief. The material discusses various clustering and data replication architecture options.

Application recovery solutions are designed to protect mission-critical applications running at the primary data center from a disaster that no longer allows those applications to run at that location. This could be a disaster as simple as a backhoe cutting all of the communications cables outside the primary data center or disconnecting external users from the applications. It could also be as severe as a major natural disaster (earthquake, tsunami, hurricane, tornado, pandemic, etc.) or terrorist activity. Application recovery solutions are designed to automate the process of recovering from a disaster and to ensure that not only is the mission-critical data protected by using replication, but also that mission-critical applications using that data are highly available locally and remotely in the event of a disaster.

Supported Application Recovery Configurations

There are basically two types of configurations in the application recovery model: Metro Clusters and Global Clusters. The difference is in how a failover is treated when going from one site to another. Is there a degree of control involved or is it fully automated? Both methods support local failover within the site.

Metro Clusters extend a single cluster between multiple sites and act at all times like a single cluster. The operator can configure failover ordering to always failover between systems located within the primary site before failing over to systems located at the disaster recovery site. However, when an outage affects all servers at one site, a failover to the second site will occur automatically. The single cluster solution is typically deployed in a metropolitan area, with full synchronous mirroring or replication and very reliable communications links between sites. In such cases, the company is essentially expanding the concept of high availability to include more than one data center. Assuming that all the infrastructure components are solid and that a business need exists to have full automated failover to a remote site, this is a very viable solution.

The following sections provide more detailed information on various cluster configurations.

Metro Clusters

Metro Clusters are single clusters that have been extended to more than one site. A Metro Cluster behaves exactly the same way as a cluster in a single site in terms of failover behavior. The underlying data transport mechanism between the sites provides for slightly different configurations in terms of the storage and how data from the primary site is “copied” to the disaster recovery site. The data can be replicated using application-based, host-based, or array-based replication. Metro Clusters can provide metropolitan area disaster recovery.

Metro Cluster with Replication

A Metro Cluster with Replication is a single cluster spread across two physical locations. This configuration eliminates the single point of failure represented by a single data center as it assumes independent power and communications at each facility. The Metro Cluster provides extended area high availability, which gives it the capability to provide disaster recovery automation at metropolitan distances. The extent of separation between the two data centers depends on the risks that the company wants to protect its environment from, but is limited at the margin by the requirement for synchronous replication. This typically is metropolitan in nature—less than 80 kilometers (50 miles). The nodes within each data center share storage at that data center. There is no shared storage between data centers, nor is there an extended SAN between the data centers. A Metro Cluster uses data replication to assure data access to all nodes at each data center. In a Metro Cluster configuration, if an application or a system fails, the application is restarted on another system within the current primary site or zone. If the entire primary site fails, the application is automatically restarted on a system at the remote secondary site (which then becomes the primary). In the event of a storage failure at the primary site, the cluster will detect that there has been a failure and will perform the operations necessary to prepare the storage at the disaster recovery site for production use and then restart the application using that storage.

Synchronous data replication keeps the copies of data at the two data centers synchronized. Asynchronous replication cannot be used for a Metro Cluster due to the potential for data loss during an automatic failover between sites.  Replication can take place at the application, host, and storage levels. Application-level replication products, such as Oracle Data Guard, maintain consistent copies of data between systems at the SQL or database levels. Host-based replication products, such as Veritas Volume Replicator, maintain consistent storage at the logical volume level. Storage or array-based replication products such as EMC SRDF or Hitachi Data Systems TrueCopy maintain consistent copies of data at the disk or RAID LUN level. Supported distances between data centers for synchronous replication are approximately 80 kilometers (50 miles) or less. The Metro Cluster configuration provides both local high availability and disaster recovery functionality in a single cluster.

Notes Figure 1: Metro Cluster with Replication

A Metro Cluster configuration is appropriate in situations where dual dedicated cluster interconnects are available between the primary site and the disaster recovery secondary site, but there is no shared storage or SAN interconnect between the primary and secondary data centers. To understand how a Metro Cluster configuration works, consider the example of an Oracle database configured in a Veritas Cluster Server HA/DR Metro Cluster. The configuration has two system zones:

• Primary zone (zone 0) comprising nodes located at the primary site and attached to the primary storage
• Secondary zone (zone 1) comprising nodes located at the secondary site and attached to the secondary storage

Oracle is installed and configured on all nodes in the cluster. Oracle data is located on shared disks within each Metro Cluster zone and is synchronously replicated across Metro Cluster zones to ensure data concurrency. The Oracle service group (a service group within Veritas Cluster Server is the smallest unit of failover—it contains all of the resources that a mission-critical application needs to come online) is online on a system in the current primary zone and is configured to fail over in the cluster.

Notes Figure 2:  Metro Cluster with Replication Failover Example

In the event of a system or application failure, Veritas Cluster Server HA/DR attempts to fail over the Oracle service group to another system within the same Metro Cluster zone. However, in the event that Veritas Cluster Server HA/DR fails to find a failover target node within the primary Metro Cluster zone, Veritas Cluster Server HA/DR automatically switches the service group to a node in the current secondary Metro Cluster zone (zone 1). Veritas Cluster Server HA/DR also redirects clients by bringing up the application IP address(es) at the zone 1 data center. The Metro Cluster with Replication configuration requires Veritas Cluster Server HA/DR to be installed on each server at each location and supports the use of VCS HA/DR Fire Drill for automated testing.

Metro Cluster with Mirroring

The Metro Cluster with Mirroring is a single cluster that spans two or more physical locations, similar to the Metro Cluster. The storage at one location is mirrored to the other using a data replication technology. Mirroring is a synchronous process. Unlike Metro Cluster with Replication, the storage at both data centers is connected using an extended SAN. Effectively, the user is configuring a RAID 1 mirror between two arrays at different sites. All data is written simultaneously to both mirrors. Reads can be configured to be serviced by the site where the application is currently running. The separation between the data centers has a practical limit in terms of performance of about 80 kilometers (50 miles). A Metro Cluster with Mirroring can also be configured using the concept of zones to set failover ordering to always attempt failover locally first.

Notes Figure 3: Metro Cluster with Mirroring

A Metro Cluster configuration is appropriate in situations where dual dedicated cluster interconnects are available between the primary site and the disaster recovery secondary site and there is an extended SAN connecting the shared storage between the two sites. The storage at one site is configured so that it will be mirrored to the second site.

For failures not involving storage, a Metro Cluster with Mirroring will have the exact same failover behavior as the Metro Cluster with Replication.

Global Clusters link two (or more) independent local clusters to form a global failover relationship for specific applications. Failover between local systems in either cluster is fully automatic. Failover between sites (i.e., clusters) requires operator confirmation. Enabling confirmation gives operators the ability to ask “what should I do?” in the event that local failover protection can no longer protect the mission-critical applications, and a decision has to be made around whether to perform an application recovery at the disaster recovery location. An operator can thus indicate:

• “Yes,” we will incur a site failover. The local disaster is not expected to be resolved in the near future—or more specifically within our RTO limits—and it makes sense from a business perspective to bring all of the mission-critical applications up as quickly as possible at the disaster recovery site. In cases where an asynchronous replication technology is employed, this decision essentially accepts that the company will be coming up on somewhat out-of-date data.
• “No,” we believe that the disaster will be resolved shortly, within our RTO limits, and therefore we will not incur a site failover. It is less disruptive to stay at the primary site, even though the site is down, than it is to incur a site failover to the disaster recovery site, and then another one to come back to the primary data center once the disaster has been resolved.

The decision to place an operator in the decision path with global clustering is usually recommended as it allows the business to assess the severity of the disaster with respect to the RTO goals of the mission-critical applications and then act accordingly. Manual disaster recovery failover control also eliminates the risk of faulty communications between sites, triggering an automated response. In many situations, site-to-site communications are provided by an outside vendor and may not always be as reliable as desired.

Global Clusters

A Global Cluster is a collection of 2-4 clusters in separate locations linked together to enable intelligent application recovery over any distance, i.e., globally. There is no shared storage between the clusters in a Global Cluster. Each cluster within the Global Cluster is connected to its own shared storage. A Global Cluster has a single primary cluster (i.e., site), and up to three secondary clusters (sites). The storage within the Global Cluster is replicated, either synchronously or asynchronously, from the primary cluster to each of the other secondary clusters. Typically, asynchronous replication over the wide area network (WAN) connecting the data centers is used, but synchronous replication can be used for shorter distances (less than 80 kilometers/50 miles). Local clustering provides local failover for each site or building. Metro Cluster configurations offer protection against disasters affecting very small geographic regions. Large-scale disasters such as major floods, hurricanes, earthquakes, and acts of terrorism can cause outages for an entire city or region. In such situations, a company can ensure global availability by migrating applications to sites located a considerable distance apart. Over the past few years, the best practice regarding the minimum distance separating the primary and disaster recovery data centers has grown from 50 to over 200 miles. In a Global Cluster, if an application or a system fails, the application is migrated to another system within the same cluster. If the entire cluster fails, the enterprise can make a business decision as to whether or not to move operations to one of the alternate disaster recovery sites. If the decision is to move to a specific disaster recovery site, the application is automatically restarted on a system in the cluster at that disaster recovery site(s).

Notes Figure 4: Global Cluster

Now consider the example of an Oracle database configured in a Veritas Cluster Server HA/DR Global Cluster that connects two clusters together. Oracle is installed and configured in both clusters. Oracle data is located on shared disks within each cluster and replicated across clusters to ensure data concurrency. The Oracle service group is online on a system in cluster A and is configured to fail over globally, on clusters A and B. Veritas Cluster Server HA/DR continuously monitors and communicates events between clusters. Inter-cluster communication (ICMP-based) ensures that the Global Cluster is aware of the state of the global service group at all times.

Notes Figure 5: Global Cluster Failover Example

In the event of a system or application failure, Veritas Cluster Server HA/DR fails over the Oracle service group to another system in the same cluster. If the entire cluster fails, Veritas Cluster Server HA/DR alerts the operator and provides an opportunity for action. The operator may declare a “disaster,” which indicates that the primary data center has been lost, (at least as far as the application is concerned—this might perhaps be the result of a localized power outage) in which case operations are migrated to the disaster recovery data center automatically. Or the operator may declare an “outage” and decline to allow failover in cases where local restoration of service will happen in a short (or at least acceptable) period of time. In either case, a business decision must be made regarding whether or not a failover is in the enterprise’s best interests, considering RTO limits and what is known about the particular disaster. The Global Cluster configuration requires Veritas Cluster Server HA/DR installed on each server at each location and supports the use of VCS HA/DR Fire Drill for automated testing.

Replication Support in Metro and Global Clusters

Clustering technologies need to support a wide variety of replication products to completely automate the process of replication management and application startup at the remote site without the need for complicated manual recovery procedures involving storage and application administrators. The clustering solution should provide all the necessary logic to completely control the underlying replication configuration, whether that replication operates:

• At the storage array level (e.g., EMC SRDF)
• At the database level (e.g., Oracle Data Guard)
• Synchronously or asynchronously

Depending on the type of failure, this control may involve reversing the direction of the replication (otherwise known as role reversal, role swap, dynamic swap, or personality swap) or simply moving the data and applications back when the original site comes back online. This solution should also include the capability to select automatic or operator-confirmed site-to-site failover.

ESG research respondents ranked “improving disaster recovery capabilities” as #1 for data protection spending priorities in 2010. In another study of all IT spending priorities for 2010, “business continuity and disaster recovery programs” ranked eighth, while, within virtualization priorities, “making use of virtual machine replication for DR” ranked #4.

In a 1:1 P2P scenario, DR assets are mostly dormant, consuming valuable IT resources (staff, data center footprint, power/cooling, and added CAPEX for infrastructure costs). The expense of maintaining DR assets often becomes the limiting factor in what applications and data are protected. And, if my organization doesn’t have a second site or data center to use as a target for my clone, a DR strategy can’t get off the ground at all.

Enter virtualization.

Clearly, IT organizations are seeing the benefits of taking advantage of P2V and V2V DR scenarios. These approaches greatly reduce the cost and complexity associated with DR infrastructure. Virtualization reduces the cost of hardware at a secondary site and eliminates resource consumption. The portability of virtual machines also means that failback can occur to the original location or to a new one—to a virtual machine or a physical system with dissimilar hardware.

Enter the cloud.

Nowhere to replicate to? Amazon is a good destination. “Rentable” compute (EC2) and storage (S3) for use as a DR target are readily available with a credit card. Provision what you need, when you need it.

Double-Take Software can facilitate the process. The company offers continuous host-level replication of physical or virtual machines to a secondary host—located in the same data center or to a WAN-connected site (including the cloud). Double-Take Cloud delivers real-time replication between source system and a Double-Take Cloud Repository hosted at Amazon.

Why is this a big deal? Tremendous cost savings. With an approximate cost of $100 per server per month, the vendor claims 88% savings in DR TCO with Double-Take Cloud over a more traditional DR scenario.

Read more of Lauren’s blog entries at Data Protection Perspectives.

A couple of areas that tend to be overlooked are 1. employees and 2. partners and suppliers. Does your organization’s BC/DR plan include procedures for employees? Perhaps the recent threat of the Swine Flu or its politically correct H1N1 name have prompted organizations to take a closer look at the workforce and identify those personnel responsible for mission critical functions.  Some have taken steps to ensure that these employees could continue to do their jobs–even if forced to work from remote locations for long periods of time.  But what about an organization’s partners and suppliers–how well are they protected and how fast could they recover? How would you find out? In either case,  finding out this information could result in quite lengthy and manual processes.  Wouldn’t be fun the first time you did it and probably wouldn’t get much easier every time after that.

I recently talked with SunGard about some new software modules from their Continuity Management Solutions that are specifically designed to address these needs. Their Vendor and Workforce Assessment modules will allow organizations to quickly create online surveys that can be deployed to all employees and vendors via e-mail. Results are collected and provide insight into gaps that exist and need to be corrected. Examples of these gaps include an employee that doesn’t have a laptop and can’t work from home during severe weather or a supplier that has inadequate protection plans that could jeopardize your organization’s ability to deliver goods or services. Once set up, it could be done on an annual basis to ensure accuracy and that the proper remediation has taken place. Or it can identify a continued weak link in your supply chain that needs to be replaced.

If your organization doesn’t know how well your partners are protected, you may want to consider checking out this software–which can also be consumed via software as a service.

Read Bob’s other blog entries at Data Center Continuum.

ESG surveyed over 500 IT professionals in companies ranging in size from 100 employees to more than 20,000. Nearly 50% of midmarket companies (100-999 employees) report more than 10 TB of total data volume and nearly 50% of enterprise organizations (1,000 employees or more) cite more than 100 TB. And, over 50% of respondents are experiencing growth rates of 20% or more per year. Pretty impressive. When you do the math, it means that data volume is doubling every two to five years.

Organizations are aware of the pickle this puts them in. When asked about their primary challenge with their organization’s data protection processes and technologies, respondents prioritized (by a fair margin) “keeping pace with the capacity of data to protect.” Part of their keeping pace strategy is (no surprise) inserting disk in the backup data path (80% of organizations do this) and implementing snapshot or continuous data protection (in fact, over 50% of respondents said they’d choose one of these to replace file-level backup!).

The “I’ve got more data than I can deal with” issue also created a huge spike (over 200%) in deduplication adoption when comparing our 2008 survey with today’s. More enterprises (45%) are adopting deduplication than midmarket companies (29%), and midmarket companies are more likely (43%) to implement deduplication in backup software than hardware solutions (23%) or a combination implementation (35%) (i.e., implement software solutions for some workloads and hardware solutions for others).

Again, lots of information. Lots of insight. Stay tuned for more … unless you’re a registered end-user or subscribing client. If you are, you can access ESG’s 2010 Data Protection Market Trends report right now.

Read more of Lauren’s blog entries at Data Protection Perspectives.

Click here for the PowerPoint slide.

Click here for the full ESG Research Report: 2010 Data Protection Trends. ]]> http://www.enterprisestrategygroup.com/2010/04/top-areas-of-data-protection-investment-for-2010/feed/ 0 http://www.enterprisestrategygroup.com/2010/04/current-data-protection-process-and-technology-challenges/ http://www.enterprisestrategygroup.com/2010/04/current-data-protection-process-and-technology-challenges/#comments Fri, 30 Apr 2010 20:28:10 +0000 kevin http://www.enterprisestrategygroup.com/?p=16540

Click here for the PowerPoint slide.

Click here for the full ESG Research Report: 2010 Data Protection Trends. ]]> http://www.enterprisestrategygroup.com/2010/04/current-data-protection-process-and-technology-challenges/feed/ 0 http://www.enterprisestrategygroup.com/2010/04/2010-data-protection-trends/ http://www.enterprisestrategygroup.com/2010/04/2010-data-protection-trends/#comments Fri, 30 Apr 2010 18:42:57 +0000 Garrett Doherty http://www.enterprisestrategygroup.com/?p=16038 In order to assess the current state of the data protection market, ESG recently surveyed 510 North America-based senior IT professionals representing midmarket (100 to 999 employees) and enterprise-class (1,000 employees or more) organizations.  All respondents were personally responsible for evaluating, purchasing, or managing data protection technologies—such as backup and recovery software, data replication software, and disk or tape storage systems used for secondary data storage—for their organization.

The survey was designed to answer the following questions:

• What are the primary data protection challenges that organizations are currently facing?
• Which areas of data protection will merit the greatest level of investment in 2010?
• How confident are organizations that their data protection applications and processes are adequately protecting their data?
• Which types of data protection technologies and processes are currently in use? How will this change going forward?
• What impact does the business value of data have on data protection applications and processes?
• How satisfied are organizations with their current data protection technologies and strategies?
• What types of storage solutions are currently used to support data protection requirements and how will this change over time?
• How pervasive has data deduplication usage become over the last several years?

Survey participants represent a wide range of industries including manufacturing, financial services, communications and media, health care, retail, government, and business services.

For more information on the contents and findings of this report, please download the executive summary below.

ESG Research Report 2010 Data Protection Trends Executive Summary

Click here for the PowerPoint slide.

Click here for the full ESG Research Report: 2010 Data Protection Trends. ]]> http://www.enterprisestrategygroup.com/2010/04/reasons-organizations-would-replace-current-backup-solutionvendor-with-a-third-party-online-backup-service/feed/ 0 http://www.enterprisestrategygroup.com/2010/04/double-take-amazon-form-disaster-recovery-cloud-with-double-take-cloud/ http://www.enterprisestrategygroup.com/2010/04/double-take-amazon-form-disaster-recovery-cloud-with-double-take-cloud/#comments Thu, 22 Apr 2010 20:06:49 +0000 Garrett Doherty http://www.enterprisestrategygroup.com/?p=13587 Enterprise Strategy Group analyst Lauren Whitehouse said the difference is Double-Take/Amazon combination enables on-demand computing for disaster recovery.

via Double-Take, Amazon form disaster recovery cloud with Double-Take Cloud.