InMagetag:,2007-09-06:/142010-07-27T17:18:55ZInMage provides a single, integrated solution that handles both local and remote recovery for both data and applications in heterogeneous, open systems environments. Technologies under the hood include CDP, asynchronous replication, application failover/failback, and WAN optimization – all managed from a single management GUI.Movable Type 4.17 Considerations When Choosing a Replication Software Product (Part 2 of 2)tag:inmage.dciginc.com,2010://14.16962010-07-27T10:00:00Z2010-07-27T10:00:00ZLast week I took a look at the first three factors to consider when choosing a replication software product. This week I wanted to finish my thoughts around that subject and discuss the final four factors that should be part of any evaluation of replication software.Jerome M. Wendthttp://sales.dciginc.com/about/jeromemwendtbiography.html The first three factors as I discussed last week were:
Continuous versus scheduled replication
Efficiency of data transfer
Block versus file
Here are the final four factors that every organization should consider when evaluating any replication software solution:
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.
Organizations should not view it as a requirement that a single replication software product possess all seven of these attributes in order to consider it appropriate for use in their environment. However, the more of these features and options that the replication software product possesses, the more flexible it will be and the more likely it is that the replication software will meet whatever needs your organization has now or in the future.
Part 1 - 7 Considerations when Choosing a Replication Software Product ]]>
7 Considerations When Choosing a Replication Software Product (Part 1 of 2)tag:inmage.dciginc.com,2010://14.16752010-07-19T10:00:00Z2010-07-19T10:00:00ZReplication is becoming an ever more important component in the protection and recovery of applications. Anecdotal evidence already suggests that 50% or more of all SAN and NAS storage systems ship with some form of replication software while many more organizations use replication in its other forms (application, appliance or host-based). But regardless of what form of replication software that organizations buy, they are many times unaware of the subtle ways in which replication software products differentiate themselves.Jerome M. Wendthttp://sales.dciginc.com/about/jeromemwendtbiography.html Replication software is the same in that all four forms of it - appliance-based, application-based, host-based and storage array-based - share the trait of replicating data from one device to another. But this is where the similarities can end and differences begin.
Each replication software product possesses unique characteristics. This may make one offering more suitable for some implementations and less than ideal or even completely unusable in others. Therefore it is imperative that users understand how the underlying replication software (in whatever manner it is implemented) functions so they can select the proper one for their organization.
In this first of two blog entries, I will look at seven factors that every user should consider when evaluating any replication software solution:
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.
Check back next week for the last four considerations when choosing a replication software product!
Part 2 - 7 Considerations when choosing a replication software product. ]]>
What a Windows Recovery Solution Should Look Liketag:inmage.dciginc.com,2010://14.15122010-06-07T17:00:00Z2010-06-07T17:00:00ZOne of the principle struggles within organizations in the first decade of the new millennium has been solving Windows backup issues. Now that a new decade has arrived the problem has changed as organizations turn their attention to how they can recover their Windows application servers in a time frame and manner that meets their requirements. But to identify such a solution they first need to define what such a recovery solution should look like.Jerome M. Wendthttp://sales.dciginc.com/about/jeromemwendtbiography.htmlorganizations turn their attention to how they can recover their Windows application servers in a time frame and manner that meets their requirements. But to identify such a solution they first need to define what such a recovery solution should look like.
In the last few years much of the angst surrounding the backup of Windows systems has abated. The introduction of disk into the backup process has been a godsend in that it has removed backup as being one of the more problematic processes in the data center.
But new expectations and requirements have emerged in its wake. Users and application owners are less tolerant of application outages of any kind, much less extended outages. Server virtualization is driving up the number of application servers that need protection. Fewer people are available to dedicate time to orchestrate application recoveries. Disaster recovery plans are no longer optional but expected. Upgrades of production applications need to occur without a hitch.
It is for reasons like these that more organizations are less concerned about backup and instead focusing on recovery. As they do, they are asking the question, "What should a Windows recovery solution look like?"
There is no simple answer to that question but the following list is a good starting point in terms of what features to look for in a Windows recovery solution. It should support:
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.
In addition to these features, organizations that have already adopted server virtualization or plan to head down that path should also verify that the Windows recovery solution introduces minimal or no overhead on the virtual machine. Further, if organizations have other critical applications hosted on Windows such as Blackberry Enterprise Server, Oracle or SAP, they will want to verify that the Windows recovery solution integrates with the appropriate application snapshot APIs, allowing it to support application-consistent recovery options.
It is those organizations that are ready to look beyond backup and at a Windows recovery solution that should look at InMage. InMage delivers the type of reliable data protection solution that organizations have come to expect for their Windows application servers but more importantly contains these new features that organizations need as they look to implement their Windows recovery solution of tomorrow.
The introduction of disk into the backup process has solved one of the more nagging problems of the last decade. But now with the backup problem well on its way to being solved, it is time for organizations to take the next step and identify solutions that facilitate and automate the recoveries of their Windows applications.
Organizations that are ready to leave backup in the past should therefore look towards InMage. The features it offers already define what the next generation of Windows recovery solutions will be expected to deliver in the coming decade. But what makes InMage so intriguing is that organizations do not have to wait until the end of this decade to achieve these types of Windows application recoveries as InMage can offer them today. ]]>
Burst into the Cloud with InMage's New Cloud-Optimized Infrastructuretag:inmage.dciginc.com,2010://14.14252010-05-12T18:30:00Z2010-05-12T18:30:00ZOne of the key concerns that businesses have is how providers of the cloud will handle and respond to spikes in application demands. It is these questions that InMage's newly announced cloud-optimized infrastructure is designed to answer.Jerome M. Wendthttp://sales.dciginc.com/about/jeromemwendtbiography.html
announced cloud-optimized infrastructure is designed to answer.
Despite the relative newness of the concept of the cloud, businesses like it a lot. Business managers are less concerned about where their applications and computing resources reside and far more concerned about optimizing how they run while driving down costs.
One IT Business Alignment Manager at a large energy company recently even went so far as to say, "I do not care who provides my infrastructure for my mission critical applications. I just need visibility into the cloud; control of my response time, I/O, throughput, availability, latency and security; and, the flexibility to adjust those resources based upon my business priorities and changing workloads."
The cloud is emerging as the ideal way to deliver on his objectives. The trouble with most cloud infrastructures is that right now they only do a few things well. For instance, they primarily aggregate hardware resources and make it possible for different applications to securely access and share these resources.
However they do not do a good job of answering this IT Manager's concerns about providing him with visibility into how the resources in the cloud are utilized nor do they give him the flexibility and ability to respond to his changing application needs. As a result, many see the potential benefits of the cloud but are waiting to put mission critical applications and data into the cloud.
For cloud providers to gain the trust they need to succeed, they must introduce technology that dynamically monitors, controls and manages the applications and data that is in the cloud. Specifically, this technology must enable different applications from different companies with various priorities and workloads to effectively respond to spikes in demand from any one of these applications. Without this ability, these spikes may negatively impact a specific application's performance and even have a ripple effect that affects other applications in the cloud.
This ability to bring up specific application resources within the cloud on demand using virtual server technology is a technique known as cloudbursting. Cloudbursting responds to changes in application demands by enabling cloud providers (private or public) to automate the movement of applications and their data to where there are resources available to meet their changing demands.
This is what InMage's cloud-optimized infrastructure delivers. To do so InMage leverages its foundation technologies like continuous data protection (CDP), application snapshot API integration, asynchronous replication, automated application recovery (failover/failback), integrated WAN optimization, storage capacity optimization, and disk-based recovery.
But what makes InMage unique in this emerging cloudbursting space is that it adds application migration into the mix, supporting the ability to easily provision application services, not just hardware resources, on demand in the cloud. Cloud providers leveraging InMage's cloud optimized infrastructure can now create services around new use cases that definitively differentiate themselves from their competition. This in turn gives end users new options with cloud based services not previously available.
InMage defines cloud optimized infrastructure along a set of key new features:
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
A cloud optimized infrastructure is built around the ability to provision storage, network, and virtual server resources and leverages application failover/failback capabilities for simple application service provisioning or recovery. There are three main use case scenarios that this potentially enables for cloud providers:
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.
All of these uses cases could potentially be done today but there would be a significant amount of manual involvement provisioning resources and setting up application services. InMage makes that possible by enabling "push button" application migration and/or recovery.
What's important for cloud providers to realize is that there are both data and application issues that need to be taken into account to leverage cloudbursting in this way, and InMage is one of the few players in the industry today that has the technology to make that a reality. As part of the cloud infrastructure foundation, InMage is equally applicable to private, public, and hybrid cloud environments, providing both end user organizations and cloud providers with some new options in leveraging and/or providing cloud-based services. ]]>
Take off Those Rose Colored Deduplication Glasses and Look at Data Protection Anewtag:inmage.dciginc.com,2010://14.12992010-03-29T10:00:00Z2010-03-29T10:00:00ZThese days it seems that all someone has to do is use the word "deduplication" in conjunction with a data protection product and that data protection product magically looks "better". But what organizations have to be careful to do is not allow deduplication to color their view of what they hope to accomplish with the implementation of disk-based data protection. Rather organizations need to look at data protection from a different viewpoint that it is not tainted by deduplication and allows them to fully leverage the flexibility that disk-based backup provides.Jerome M. Wendthttp://sales.dciginc.com/about/jeromemwendtbiography.htmlorganizations have to be careful to do is not allow deduplication to color their view of what they hope to accomplish with the implementation of disk-based data protection. Rather organizations need to look at data protection from a different viewpoint that it is not tainted by deduplication and allows them to fully leverage the flexibility that disk-based backup provides.
I agree for the most part that deduplication makes current data protection processes better. Deduplication facilitates the introduction of disk into their current backup process by making disk economical to deploy as data reduction ratios of 20:1 or greater can be achieved.
This 20:1 data reduction ratio is critical since this allows disk to cross the cost of tape threshold so organizations can now cost justify the deployment of disk. As a result, the other advantages of disk come into play: faster backups and restores; backups and restores that complete with near 100% success rates; and, significant decreases in the amount of time that organizations spend troubleshooting failed backup jobs.
But it is at this point that organizations need to take off their deduplication colored glasses and ask the following question regarding deduplication: "What does deduplication change about current backup processes?"
Not much else aside from what has already been mentioned above. Backup is still a point in time process that generates server, storage, and network resource spikes when it is run. Depending on where it is run (source or target), deduplication may make things better than they are today, but as data sets continue to grow, you'll eventually run into the same problems with backup windows, RPOs, and resource spikes.
Many vendors are already talking about the growing need for more "continuous" data protection approaches. One of the big benefits to these types of technologies, which include replication and continuous data protection (CDP), is that they significantly reduce resource spikes by spreading the capture of daily changes out across the entire day.
Data is expected to grow at rates of 50% - 60% a year or more for most enterprises, so this is a salient point to consider when developing backup strategies. Data growth rates make the use of deduplication technology a tactical, not a strategic, play. It is for reasons like this that it behooves organizations to look at disk-based data protection from a totally different viewpoint than one filled with deduplication's glow.
But you do still have to consider storage hardware costs when deploying disk as a backup target, so here is a perspective to consider. Suppose one did not have to deduplicate data but could get 90 - 100% of the data reduction benefits and storage hardware cost savings that data deduplication provides, the same near-100% backup and recovery success rates, the same decreases in time managing backups and the elimination of backup windows.
In addition, one would also get a number of other benefits of critical importance in data protection:
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
Disk-based data protection software from providers like InMage makes this change in viewpoint possible. Not only does it deliver all of these new benefits, it consumes approximately the same storage capacity as data deduplication.
A previous blog that I wrote on this subject illustrates this point. When the same set of production data is protected over a 30 day period is in one case protected using traditional backup software with data deduplication and in another case protected using InMage's CDP software, data deduplication is at best 10 - 20% more efficient than InMage CDP. Considering the declining price of disk and the powerful new benefits that InMage CDP affords, that is a small price to pay.
Data deduplication is a powerful new technology but many organizations are being blinded by the relatively few recovery benefits that it provides. This is causing them to miss out on the real opportunities that disk-based data protection technologies like InMage can provide.
InMage CDP puts the world of disk-based data protection in a totally different light as it changes more than just how organizations should view the protection and recovery of their production data. It should open their eyes to the entirely new possibilities that storing their backup copies of their production data on disk create. ]]>
Deliver High Speed CDP with SATA Disk: Here's How It Is Donetag:inmage.dciginc.com,2010://14.12842010-03-22T10:00:00Z2010-03-22T10:00:00ZThere is a perception among enterprise organizations that in order to deploy continuous data protection (CDP) technology, they also need to use high performance disk in conjunction with it. But enterprises probably should re-assess that assumption. The emergence of new and better CDP architectures such as what InMage offers enables organizations to deliver high speed CDP while using slower performing SATA disk drives. Jerome M. Wendthttp://sales.dciginc.com/about/jeromemwendtbiography.html
InMage offers enables organizations to deliver high speed CDP while using slower performing SATA disk drives.
The belief that CDP software needs high performance disk stems from its early generations of this software. This software sat in the application server's data path and needed high performance disk for two reasons.
First, the application generated a large number of write I/Os so the CDP needed high performance disk to keep up with the traffic. Second, and maybe more importantly, enterprises expected to recover the application on the disk used by the CDP solution. In order to ensure the application had the same performance characteristics it did in production, high performance disk was used.
So what has changed from an architectural perspective in CDP software that would no longer cause these assumptions to hold true? In the case of some products, not much has changed and these assumptions still hold true.
However in the case of InMage, it introduces a CDP architecture that minimizes the need for high performance disk drives. Rather than trying to write the data to disk as application write I/Os occur, InMage creates a two tier architecture.
On the first tier, InMage dumps the data directly to a cache that is on the InMage appliance. Only once it is cached there does it get replicated directly to InMage's second tier, the target which acts as the retention log and holds the data.
This two tier architecture of InMage enables enterprises to protect high performance applications while using low cost, high capacity disk on the back end. InMage accomplishes this by completely decoupling the speed of the disk of the target from the performance requirements of the other appliance that captures the data.
Granted, the performance of data capture is impacted by speed of the cache on the InMage appliance. However the cache in the InMage appliance's main memory already runs faster than any high performance disk.
So is there ever a need for high performance disk in the InMage architecture? There is, but it is only under a very specific application recovery condition. That condition is: if an organization wants to generate an image of that application, mount that image and run it as it is in production.
This situation primarily presents itself when an organization fails an application over to a disaster recovery (DR) site. In this circumstance, the primary site is gone and you want to bring up an application like Microsoft Exchange and expect to run it at the DR site until you get your production site back online. In this case, disk speed matters as it will likely impact Exchange's performance once it is recovered.
Even in this circumstance, there may be ways to protect Exchange without having to put all of its data on high performance disk. The main determinant as to whether or not you need high performance disk is how long the organization can tolerate Exchange operating at less than optimal levels.
If the organization can tolerate a few hours of subpar Exchange performance, you may still be able to use SATA disk to recover Exchange. This configuration permits an initial, fast recovery of Exchange on SATA disk even as InMage concurrently copies the Exchange data to higher performing disk. Once the copy is complete, Exchange can then be failed over to the higher performing disk.
Organizations need to re-examine any assumptions they may have that they can only implement CDP for write intensive applications using high performance disk. InMage's two tier architecture minimizes or even eliminates this need by giving organizations the flexibility to use slower performing disk even with their highest performing applications. In so doing, organizations can extend the benefits of CDP to the applications that really need it without breaking the bank in order to accomplish it. ]]>
The Truth about CDP's Storage Capacity Requirementstag:inmage.dciginc.com,2010://14.12792010-03-16T10:00:00Z2010-03-16T10:00:00ZHere is what determines how much storage a CDP product needs. CDP initially needs an allotment of storage capacity that is equal to the size of the volume on which the data resides that is being protected. This is needed so the CDP product can make a copy of all of the blocks on the production volume. However, the wild cards in how much storage the CDP product requires are based not the size of the production volume but two other variables.Jerome M. Wendthttp://sales.dciginc.com/about/jeromemwendtbiography.html
(A) 2x (B) 3x (C) 5x (D) 7x (E) 10x or more
I'll get to the correct answer in a moment but a common misperception is that when using CDP to protect your application data, you need a lot of storage in order to implement it. This is not necessarily the case.
Here is what determines how much storage a CDP product needs. CDP initially needs an allotment of storage capacity that is equal to the size of the volume on which the data resides that is being protected. This is needed so the CDP product can make a copy of all of the blocks on the production volume. So if you are protecting 100GB of application data to start, CDP will also need to start with 100 GBs of storage capacity.
However, the wild cards in how much storage the CDP product requires are based not the size of the production volume but two other variables. They are:
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.
So to answer the multiple choice question above, the most correct answer is (A). CDP requires roughly a 2x storage capacity required for most environments assuming a 30 day retention period.
If you compare CDP to the use of deduplication under the same circumstances, the results are almost the same. Using either CDP or deduplication over a period of 30 days to back up a 100GB data set with a 5% change rate (assuming 4 fulls and 24 incrementals per month with a 20:1 dedup ratio) both products require roughly 150GB of raw storage capacity.
Even more encouraging, CDP can become even more storage efficient going forward. Most organizations only need the granular level of recovery that CDP provides for 24 - 48 hours. After that period, retention policies can be established that decrease the granularity of retained data over time.
For example, organizations can opt to keep full granularity for the first 48 hours, retain one application-consistent recovery point every four (4) hours for the next 72 hours, and then retain one application-consistent recovery point per day thereafter to the end of the 30-day window. Application-consistent recovery points can then also be used as the source from which to create the occasional low cost tape-based copy of data to meet compliance requirements without negatively impacting production servers.
Arriving at the truth as to how much storage capacity CDP products like InMage need does not turn into a guessing game. Documenting how CDP works and then taking into account how factors like daily change rates and retention periods impact its total storage consumption make it much easier to understand and illustrate its true value proposition. In so doing, organizations can dispel some of the myths around CDP's costs and subsequently take advantage of the recovery benefits that it provides. ]]>
A Disk Backup Target Can be Much More than a Glorified Form of Tapetag:inmage.dciginc.com,2010://14.12692010-03-04T11:00:00Z2010-03-04T11:00:00ZThe introduction of disk and deduplication into the backup process over the last few years has certainly helped to minimize existing backup problems. Organizations using these technologies have found that their backup success rates now approach 100% and that they no longer have to continually troubleshoot backup problems. But while these technologies may fix existing backup problems, they relegate disk to a glorified form of tape and do not serve to fundamentally transform the recovery process.Jerome M. Wendthttp://sales.dciginc.com/about/jeromemwendtbiography.htmlthey relegate disk to a glorified form of tape and do not serve to fundamentally transform the recovery process.
The introduction of disk and deduplication into the backup process has been largely received with open arms by the end-user community. This is evidenced by a recent IDC survey which reveals that over 60% of respondents are either in the process of implementing deduplication or have plans to deduplicate their primary, backup or archive data in the coming year (2010).
The impetus behind organizations implementing these two technologies as part of their backup processes is largely driven by the following three factors:
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
Yet what organizations may not realize is that disk and deduplication just minimize existing backup problems - they do not actually "solve" them. Simply backing up data to disk and then deduplicating it does nothing to change the "point in time" approach to backups that is the real cause of most backup problems.
They will probably manage backups the same way they do now. Weekly and monthly they do full backups and on weekdays they do differential or incremental backups. In this sense, disk and deduplication address current symptoms, they do not really get to the heart of the problem.
This is the opportunity that organizations potentially overlook. Using disk as backup target opens entirely new doors for recovery that are simply not possible when tape is used as a backup target. But introducing disk with deduplication as it is commonly done now relegates disk to this role of a glorified form of tape.
Organizations may also fail to consider that they will still have some of the same struggles with recovery using disk with deduplication that they have now with tape. For instance, they will still have the overhead associated with needing people and processes to recover the application data back to the production host.
These are typically manual processes that require the backup administrator to be available and involved with the recovery in order for it to occur successfully. Further, the administrator's ability to recover data is limited to the last good copy of data, which is probably from the previous night's backup and may take a few hours or longer to restore.
These last few points are critical for organizations to understand. Will the business tolerate waiting for the administrator to become available and do the restore? Even if the individual is available, how long can the organization wait for the restore to complete before the business is negatively impacted? Minutes? Hours? Days?
Experience says that after 30 minutes has passed, tempers start to flare and operations are adversely affected. So depending on the scope of the recovery required, it is far from guaranteed that a recovery from disk using the current backup and recovery model can deliver on this new recovery expectations and it almost certain that the recovery cannot be automated now or in the future.
This is where continuous data protection (CDP) technology from InMage comes into play as it "fixes" current backup problems while simultaneously transforming the backup process.
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.
2010 may shape up as "The Year of Deduplication" when the majority of organizations take the plunge and concurrently implement disk and deduplication. But 2010 may also become "The Year of Disillusionment" when they find out that they have addressed short term backup symptoms but have not really solved the problems. High data growth rates will bring those problems inevitably to the forefront again in the future.
Organizations looking to avoid this post-deduplication letdown can do so with InMage which fully takes advantage of disk's characteristics. Like traditional backup software uses disk, InMage also uses disk to expedite backups, increase success rates and even eliminate backup windows. But more importantly, InMage treats disk like disk instead of just a glorified form of tape so organizations can do more than just address backup symptoms. They can actually lay the foundation for transforming their backup processes to actually solve the problem. ]]>
Point, Click, Recover: Cloud-based DR has Arrivedtag:inmage.dciginc.com,2010://14.12472010-02-02T11:00:00Z2010-02-02T11:00:00ZAt the conclusion of a recent call I had with Rob Tellone, the CEO of vBC Cloud, he asked me, "What do you consider the difference between business continuity (BC) and disaster recovery (DR)?" I gave him my definition of each but then went on to explain to him that on the business side of the house no one really cares about the definition of either BC or DR. At the end of the day, all they care about is how quickly and cost effectively IT can bring the affected parts of their business back online regardless of the scope of the incident.Jerome M. Wendthttp://sales.dciginc.com/about/jeromemwendtbiography.html
vBC Cloud, he asked me, "What do you consider the difference between business continuity (BC) and disaster recovery (DR)?" I gave him my definition of each but then went on to explain to him that on the business side of the house no one really cares about the definition of either BC or DR. At the end of the day, all they care about is how quickly and cost effectively IT can bring the affected parts of their business back online regardless of the scope of the incident.
As simple as recovery sounds, bringing a business back online has proved incredibly elusive as barriers to doing it run the gamut. It may require a dedicated off-site location, proper hardware and software and people properly trained to run and manage the site. Then even for those organizations that take all of these steps, they still may not be able to recover all their applications. If you combine that with today's tighter budgets and lower tolerances for any type of outage, it's clear that companies have to reconsider how they've been addressing this challenge.
Case in point is a Fortune 500 data center at which I recently worked. It had thousands of AIX, Linux, Sun Solaris and Windows servers in production and there was no way it could possibly recover all of them despite having a dedicated off-site DR facility. All it could recover was the most mission-critical applications and, even then, those could take up to a week to recover.
Everyone in the company who was in the know knew that to successfully do a recovery, the stars had to almost perfectly align. They hoped they had selected the right applications to recover, all of the application data required to do the recovery would need to be accessible, and the people needed to do the recovery had to drop everything else they were doing to come in and perform the recovery. Then even if this all went off like clockwork, it still took days to do this base line recovery. This was more than enough time for the business to potentially fail, anger current customers and shake investor confidence.
The disconcerting part is that this organization's DR plan was better than most. This was a financially stable organization staffed by a relatively sophisticated IT staff putting in place the best solution that it could afford at that time.
This brings me back to the conversation I had with Rob at vBC Cloud. Over the last year and a half while at the helm of vBC Cloud, he has been working to build a cloud-based DR offering that does NOT require organizations:
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
Rather, vBC Cloud has taken software from a number of providers including the likes of InMage and done its own custom programming to streamline the deployment and implementation of its software. Now vBC Cloud can deliver to its customers either DR or BC in the form of software as a service (SaaS). As a result, vBC Cloud enables its subscribing customers to:
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
IT continues to wrangle over the definition of BC and DR but all that business owners ultimately care about is recovering some or all of their applications as quickly, inexpensively and effectively as possible. Until recently, achieving this type of recovery was simply not feasible.
vBC Cloud's decision to leverage cloud computing and combine technologies from providers like InMage, 3PAR, VMware and others is resulting in dramatic changes in how companies think about performing application recoveries. So whether they are recovering a file that was corrupted 10 minutes ago, an application server that had a hardware failure or recovering an entire data center that is a smoking hole, vBC Cloud provides organizations access to a DR and BC solution that makes application recovery in the cloud a point-and-click operation. ]]>
The New Server Virtualization Imperative for 2010: Application Consistent Recovery with Low Overheadtag:inmage.dciginc.com,2010://14.12262010-01-05T11:00:00Z2010-01-05T11:00:00ZServer virtualization was one of the hot technology trends in 2009 and there is every reason to believe it will remain that way in 2010. But as this trend broadens to include the virtualization of mission critical applications like Microsoft Exchange and SQL Server, new considerations come into play. Most notably, organizations must identify a data protection solution that can deliver application-consistent recovery points, bring applications quickly back online and do so without negatively impacting the performance of the physical host.Jerome M. Wendthttp://sales.dciginc.com/about/jeromemwendtbiography.html Gartner Inc. recently commented that it expects that fully 50% of workloads will run inside virtual machines by 2012 which represents nearly 58 million of deployed machines. So as this trend accelerates, it is only logical to assume that more mission critical applications such as Microsoft Exchange and SQL server are bound to be virtualized.
A recent article on FedTech lends credence to this conclusion. Departments within government organizations such as the Air Force, Navy and Federal Deposit Insurance Corp. (FDIC) are already in the midst of virtualizing applications like Exchange. Reduced hardware costs, less floor space, and lower power costs coupled with Microsoft's increased willingness to support Exchange on Microsoft Hyper-V and other virtualization platforms means applications like Exchange are ripe for virtualization in the next few years.
It is as more mission-critical applications are migrated to virtual environments that rapid reliable recoveries become more important. The virtualization of these applications may create new data protection and disaster recovery (DR) challenges that organizations have not fully taken into account prior to virtualizing these applications. Consider:
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.
Organizations should not underestimate the growing intolerance that their current customers, internal or external, have for outages of any length, especially when a mission critical application like Microsoft Exchange or SQL Server is concerned. While they can certainly count on some goodwill and understanding among their end users should a disaster strike, a recent Applied Research study quantified just how much goodwill they should expect and found that only about 60% of them will tolerate an extended outage . While the exact definition of an "extended outage" is elusive, most will agree that 24 hours now qualifies as an extended outage and it is safe to say that in regards to mission critical applications, any outage over 30 minutes probably fits this definition. So what those responsible for delivering data protection and DR services for these applications should find disconcerting is that based upon the real world feedback that this study gathered, 40% of customers who experienced an "extended outage" left their provider in favor of someone else who was not having the same problems.
It is for these types of reasons that it behooves organizations to seek out a solution like InMage that provides application-consistent recovery points in a manner compatible with the requirements of virtual machine environments. InMage integrates with native application snapshot APIs, using a very low overhead filter driver to drive the creation and marking of application-consistent recovery points, and works in exactly the same way across both physical and virtual machines. This simplifies data protection operations by providing a consistent set of processes to manage recovery across the entire enterprise. ]]>
Disaster Recovery is Definitely a "Start Small but Think Big" Application when it comes to Virtualizationtag:inmage.dciginc.com,2009://14.12072009-12-09T11:00:00Z2009-12-09T11:00:00ZEven though Gartner Research says that server virtualization is not yet widely implemented (only 16 percent of workloads currently run on virtual machines according to Gartner), Gartner does point to a more virtualized environment in the very near future. It expects that fully 50% of workloads will run inside virtual machines by 2012 and represent nearly 58 million deployed machines. But as this transition from physical to virtual occurs within data centers, traditional disaster recovery (DR) software, procedures and techniques are not positioned to migrate so cleanly into this newly virtualized environment.Jerome M Wendt and James Koopmannhttp://sales.dciginc.com/about/index.html
says that server virtualization is not yet widely implemented (only 16 percent of workloads currently run on virtual machines according to Gartner), Gartner does point to a more virtualized environment in the very near future. It expects that fully 50% of workloads will run inside virtual machines by 2012 and represent nearly 58 million deployed machines. But as this transition from physical to virtual occurs within data centers, traditional disaster recovery (DR) software, procedures and techniques are not positioned to migrate so cleanly into this newly virtualized environment.
To date it has been large companies that have been the quickest to deploy virtualization to reduce server sprawl, data center floor space, and power consumption. However smaller companies (100-199 employees) are now getting the server virtualization message and are expected to rapidly close the gap. Tom Bittman, a vice president and analyst at Gartner who covers servers and storage, says, "By 2010, smaller companies will have a higher penetration of virtual machines deployed than the Global 500."
To get started with server virtualization, he advises small as well as larger companies, to "start small but think big". Companies should first start small with a specific project and then broaden the virtualization plan to encompass more projects, existing systems, and operational processes.
Using this methodology companies can reduce risk while building a foundation that creates a sustainable environment and delivers a targeted reduction in TCO. However, to roll the 'think big' component into the plan requires that a company identify projects where they can safely "start small" but then use their successes in that area as a starting point to expand and improve 'big' data center processes. Disaster recovery software is a good example of an application that organizations can pick to start. More often than not, each application server has its own tweaked and siloed DR scenario that will encounter issues when migrated to a virtualized environment as it got this condition because each application server had its own dedicated CPU, memory, storage and networked storage resources and maybe even its own system administrator.
Server virtualization changes all of that. The days of having full access to a physical server's CPU, memory, storage, and network resources are giving way to the more controlled virtual environment that share resources in an effort to maximize computing resources.
Because this is occurring, users must let go of tightly coupled DR implementations, services and processes that today define DR for many applications on physical servers so they can move into the shared resources of a virtual environment.
This gets dicey. Virtualizing existing applications means that they may now run on shared network, server and storage hardware resources that are different than what they are used to operating on. Further, it is no guarantee that they will all be virtualized on the same server virtualization OS (for example, they could be virtualized on VMware vSphere, Citrix XenServer, or Microsoft Windows Servers 2008 Hyper-V) as an article that appeared this past Monday on SearchServerVirtualization.com confirmed.
Performing DR in virtual environments further complicates the situation. DR as it stands now in physical environments is frequently a fragmented mix of software products, including backup software, replication software, high availability software, and failover software. Each has its own recovery processes that call for individual applications to run on their own dedicated physical machine(s).
This mix of DR products coupled with the new challenges that trying to manage DR in a virtualized environment create makes DR a logical candidate as an application that organizations should look to standardize on and simplify in their virtualized environment. However, because physical servers will likely never go away in many environments, organizations should identify software that provides DR for both virtual and physical environments.
To accomplish this, DR software should possess the following characteristics:
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)
InMage is one such software-based solution that meets these complex new requirements that the recovery of physical and virtual environments imposes on organizations without becoming complex to manage itself. InMage includes a collection of next generation data protection technologies such that it delivers a "4 in 1" disaster recovery solution (backup, high availability, fail over, and replication) that recovers data and applications either locally or remotely for both physical and virtual machines.
The increasing penetration of virtual server technology into today's data centers is changing the computing landscape and driving a new set of recovery requirements for all size companies - enterprise as well as small business. Yet a mistake organizations can easily make is to implement server virtualization and just move existing recovery processes into it. If they do, they will quickly discover this is less than an optimal solution as it can generate too much overhead for virtual servers that are pre-configured to run at or near capacity.
Organizations need a comprehensive DR solution that runs the gamut - it must support physical and virtual machines; protect both data and applications; provide local and remote recovery and can "start small" while enabling them to "think big". What they will find is a very short list of solutions that satisfy these broad criteria for recovery for both physical and virtual environments and almost none that can do it simply, offer a centralized recovery management platform and can do it cost-effectively. InMage stands out as notable exception to this current DR reality that all size organizations must eventually confront as they go virtual. ]]>
Creating Test, Dev and DR Environments that can Co-Exist without the Complexitytag:inmage.dciginc.com,2009://14.11982009-11-25T14:00:00Z2009-11-25T14:00:00ZDisaster recovery (DR), testing and development environments have historically been closely linked whether or not anyone liked to admit it. Organizations would construct test and development environments and then use them for DR purposes if needed; or, they would quietly repurpose computer gear purchased using DR funds for testing and development. However the trick is getting both of these distinct but separate business processes to share this same environment without creating new levels of complexity.Jerome M. Wendthttp://sales.dciginc.com/about/jeromemwendtbiography.html Every organization plays this game of mixing its test, dev, and DR environments from time to time at some level. An organization may have a budget for testing and development but limited or no funds for a DR environment so the test and dev environment doubles as a DR environment when the situation warrants. Or conversely the organization has monies for servers, storage and networking gear for a DR environment which it invariably ends up using to test and develop its applications some or all of the time.
While this sounds like a practical use of equipment and funds, it works marginally well at best. Any time a test and dev environment has to be used for DR, backups of the test and dev environment ideally should first occur and configuration settings saved. Whether or not these tasks happen depends on the urgency of the DR event (exercise or real) and how organized the administrators of the test and dev environment are. Too often, backups of test and dev servers never occur and configuration settings are not preserved resulting in a multitude of problems when it comes time to reconstruct the test and dev environment.
Some would argue that the advent of server virtualization fixes this historical problem. This is partially true. In the case of DR, server virtualization makes it easier to recover production applications at a DR site by using VMware features like vMotion. Recoveries of production applications can occur on the same physical server that host test and development virtual machines (VMs) without impacting pre-existing test and dev VMs.
However for this scenario to succeed, vMotion makes at least three assumptions that do not always hold true:
The production applications all run on VMs
The source and target physical servers have access to the same networked storage
A high speed network exists
So while features found in server virtualization address some of these historical problems associated with mixing test and dev with DR, it still is only a partial solution.
Organizations need to recognize that test/dev and DR environments are inseparably linked. However they must treat and manage them as distinct processes while still sharing the same underlying physical resources for the simple reason that organizations have inadequate funds to justify expenditures on both types of environments. To accomplish this, they must deliver on the distinct requirements of each process while avoiding the complexity that can result when sharing the same underlying physical infrastructure.
Server virtualization is certainly a part of this equation but it is only a part. It also needs data protection and DR software such as what InMage Systems offers. InMage directly addresses an organization's DR problems but it also indirectly solves this issue of helping companies combine their test and development environments within their DR environment without compromising the integrity or reliability of either one.
It does so in the following two key ways:
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.
InMage also creates new avenues to help in the testing and development of applications. Since InMage has access to any copy of production data at any time, it can take snapshots of this data and present it to test and dev VMs with zero impact to production applications.
Once this data is presented, organizations have a lot of flexibility in terms of what they can do with the copies. They can be virtual copies for fast creation, they can be presented to physical servers if higher performance is needed. Organizations can even create multiple copies of the same snapshot. They can then modify this copy, throw it away, and re-create the same exact starting point as many times for optional uses.
For example, organization might use these copies of production data as source data for testing, simulate software upgrades or patches on production servers or even test drive how the application would run in a virtualized environment on other types of server hardware.
It also gives DBAs new flexibility for getting access to copies of data for testing. Normally they have to contact the backup or storage teams for copies of production data and coordinate with them to get this data. InMage eliminates this requirement as they can obtain these copies of data without directly involving either of these two teams each time.
Organizations have an ongoing need to successfully complete application testing and development while also delivering reliable and dependable DR solutions sharing the same infrastructure. Only now is it possible for these environments to successfully co-exist and deliver on these requirements but this does not happen by accident. It is only by using server virtualization in conjunction with technologies like InMage that companies can successfully deliver on these objectives without creating new levels of cost and complexity ]]>
CDP Makes the Value of Disk-based Data Protection Self-evidenttag:inmage.dciginc.com,2009://14.11842009-11-09T11:00:00Z2009-11-09T11:00:00ZThis past spring a debate erupted on BackupCentral.com between a user complaining about not getting new features in his backup software as part of his annual maintenance contract and his backup software provider wanting to charge extra for it. The user was, in his words, 'faithfully paying his annual 20% fee for maintenance' and now wanted the backup software's new Advanced Recovery option as part of his support costs.Jerome M. Wendthttp://sales.dciginc.com/about/jeromemwendtbiography.html
debate erupted on BackupCentral.com between a user complaining about not getting new features in his backup software as part of his annual maintenance contract and his backup software provider wanting to charge extra for it. The user was, in his words, 'faithfully paying his annual 20% fee for maintenance' and now wanted the backup software's new Advanced Recovery option as part of his support costs. But as I read this, I found myself wondering, "Why is his management balking at spending this extra money if the value of backup software and the new features it provides are self-evident?"
Let's assume for the sake of argument that this user goes ahead and pays his annual 20% maintenance fee plus the extra money for the new Advanced Recovery feature he wants. In this case, he can continue to successfully backup data to disk and, with the new Advanced Recovery feature, achieve zero-impact backups and full backup images reconstituted from previous backup images.
That's great but he already senses that his management will balk at this proposal because it views backup software as a cost to the business. If it didn't, he probably would not be fretting about whether or not he should ask for the extra money to pay for the Advanced Recovery option.
This user's concerns get to the heart of why the value of backup and recovery remains somewhat elusive to organizations even today. Companies justify it based on its ability to do recovery but even in situations when it is used, file or application recoveries are infrequent and disaster recoveries are rare and, until recently when disk was thrust into the mix, they really did not have the assurance that it worked reliably at all.
In today's economic environment, backup software's shortcomings are exacerbated. Organizations are looking to get more value from every dollar they spend and backup software is not exempt from this scrutiny. Backup software's drawback is that it still remains difficult to document what other tangible benefits it provides beyond the ones already mentioned.
Part of the problem is that many organizations still view backup and recovery from a tape-based recovery perspective. But with backup to disk a growing trend, it is opening up new use cases beyond just faster backup and recovery. The trick is taking advantage of these new options.
However some organizations have already cracked this code and are leveraging software from InMage Systems that better utilizes disk in the data protection process. In so doing, they are deriving new value from their backup data. For example:
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.
Users asking for more funds for new backup software features are likely fighting a losing battle as their management is already struggling to see backup software's larger value proposition. These individuals are better off looking for new solutions that take better advantage of disk while opening new avenues for the business to save money, reduce risk or generate revenue. If in these circumstances, InMage is one such product that can do more than just deliver on its primary use case of disaster recovery but meet these three new objectives as well. ]]>
New Multi-Tenancy Feature Makes DR Software a Viable SaaS Optiontag:inmage.dciginc.com,2009://14.11642009-10-15T14:00:00Z2009-10-15T14:00:00ZSoftware as a Service (SaaS) is on almost every company's radar screen as a cost-effective means for outsourcing applications that are not core competencies of their IT staff. Yet while outsourcing more applications sounds great in theory, applications such as disaster recovery (DR) that organizations are looking to outsource must support certain characteristics. Specifically, the software needs to support options like partitioning and data security that are inherent in a feature like multi-tenancy.Jerome M. Wendthttp://sales.dciginc.com/about/jeromemwendtbiography.html DR is high on the priority list of applications that companies are looking to outsource. Aside from the cost benefits that outsourcing DR to a SaaS provider offers and the new opportunities for recovery that it can create, the individuals that I speak with want to outsource DR so they can eliminate the hassles it creates now.
But one of the challenges of outsourcing DR to date has been finding a managed service provider (MSP) that offers a DR solution that scales to support multiple organizations, keeps each organization's data store secure and remains manageable even as it scales. DR software has been particularly challenged in this area. DR software needs to bring applications back online quickly and with as little human intervention as possible. To do this, a DR software solution obtained from an MSP must maintain separate, secure online data stores for each of the client's applications so it can recover them.
Many MSPs offer DR services but historically DR solutions are plagued by three distinct scaling problems, including:
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.
That's what makes the recent multi-tenancy enhancement to InMage Systems Scout 5.1 RX Enterprise Dashboard significant. Scout has always offered the ability to do many-to-one replication from multiple application servers (physical or virtual) to a single target (InMage Scout CX). This architecture creates a many-to-one relationship which eliminates the need for dedicated servers at the MSP's site, easing installation and lowering software licensing costs. It also makes it easy to manage data protection and recovery operations for different customers whose data is hosted on a single CX separately and securely.
What is new in 5.1 is an enhancement that allows MSPs to centrally manage multiple InMage CX server instances from the InMage RX Enterprise Dashboard. Rather than having to log into each CX system to monitor and manage data hosted on it, Scout now gives the MSP visibility into how all of the CX servers are performing and then the flexibility to individually manage each CX instance from within a single pane of glass.
SaaS is a logical course of action for organizations to pursue and DR as a service is one that makes sense for them to outsource. But doing this cost-effectively and then having the confidence that it will work when they need it calls for them to select an MSP that can provide the software that meets the specific requirements of a SaaS model.
InMage's introduction of multi-tenancy into the Scout 5.1 RX Enterprise Dashboard so it can manage multiple CX servers form a single management console should give organizations added reason to select InMage and those MSPs who offer it as their preferred DR solution. This multi-tenancy enhancement coupled with Scout's existing many-to-one replication capabilities and economical software licensing model further re-enforces why DR software is becoming a viable SaaS offering that organizations can confidently deploy. ]]>
An Automated Disaster Recovery Solution is the Lynchpin to a Viable Business Continuity Plantag:inmage.dciginc.com,2009://14.11422009-09-24T10:00:00Z2009-09-24T10:00:00Z"Business Continuity" and "Disaster Recovery" are two aspects of IT and business planning and process management that no organization can afford to get wrong. So it is somewhat disconcerting that a recent article reports that the majority of businesses do not yet have a disaster recovery plan or business continuity process in place or, if they do, they do not regularly test it.Jerome M. Wendthttp://sales.dciginc.com/about/jeromemwendtbiography.html
reports that the majority of businesses do not yet have a disaster recovery plan or business continuity process in place or, if they do, they do not regularly test it. But of greater concern is that many users still fail to understand the differences between business continuity and disaster recovery and how these processes should be individually implemented and managed.
The lack of understanding about these two processes was brought into focus by a recent blog that appeared on the Storage Monkeys' website. The challenges that users face according to this blog is that vendors have a proclivity to refer to any type of IT mishap as a "disaster" and that once this occurs they need to begin a "disaster recovery" exercise using a "business continuity" solution. Mixing this terminology is resulting in users becoming confused about the two terms and even prompted the blogger to educate himself about the differences between "business continuity" and "disaster recovery".
"Business continuity" and "disaster recovery" processes are related to one another but only in the sense that "disaster recovery" is a subset of "business continuity". These two processes are summarized as following:
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.
Here is where the confusion often arises. Replication software vendors routinely claim to offer business continuity solutions but replication software does not have anything to do with solving the people and process components of the BC equation. All replication software addresses is IT infrastructure recovery and maybe even more specifically application recovery.
However because so much of an organization's total disaster recovery plan depends on recovering applications first, recovering applications quickly is critical to recovering the business as a whole. So whatever an organization can do to automate application recoveries when a disaster occurs can directly impact whether or not a business survives when a disaster strikes.
Granted, a business can never account for every possible disaster that might occur and put in place a solution that automates recoveries for every scenario. But a business can account for more disasters than it might think. Fires, floods, human errors, power outages and tornados are all examples of minor and major disasters that can be addresses partially or in whole addressed by putting in place a solution like InMage Systems Scout that can help businesses quickly recover should a disaster strike.
Understanding the differences between business continuity and disaster recovery is critical to quantifying where businesses are at in their recovery planning. But once businesses understand that disaster recoveries are a subset of business continuity and application recoveries are even a subset of disaster recovery, then it becomes critical for businesses to identify solutions that automate applications recoveries should a disaster actually occur. Solutions like InMage Systems Scout can serve as the lynchpin to delivering a viable business continuity plan for the entire organization and move them come closer to delivering on this ideal ]]>
HDS Gives IT Managers New Choices for Hardware Agnostic CDP, Replication and Recovery Softwaretag:inmage.dciginc.com,2009://14.11162009-09-01T10:00:00Z2009-09-01T10:00:00ZA single software product that can deliver continuous data protection (CDP), replication and automated application recovery for heterogeneous open system environments is still an anomaly in today's world. Most software that does CDP, replication or application recovery may do one of these functions well but rarely can it do all three well or deliver the breadth of functionality that enterprise IT managers desire. However today's announcement that Hitachi Data Systems (HDS) will co-brand and resell InMage System's Scout as part of its worldwide storage solutions offerings is a tip-off that such a solution exists and is ready for prime time in enterprise midrange shops.Jerome M. Wendthttp://sales.dciginc.com/about/jeromemwendtbiography.html
announcement that Hitachi Data Systems (HDS) will co-brand and resell InMage System's Scout as part of its worldwide storage solutions offerings is a tip-off that such a solution exists and is ready for prime time in enterprise midrange shops.
IT managers of midrange systems (Linux, Windows and UNIX) in enterprise organizations are well aware that they are facing new requirements to better back up, replicate and recover the data on these systems. However rarely do they have the budgets to deploy separate products to deliver each of these features or the staff to manage them if they do implement them. Then even in circumstances where these individuals are aware of solutions such as InMage Systems Scout, their corporate cultures may dictate that they work directly with enterprise technology providers like HDS.
It is this combination of factors that makes today's announcement between HDS and InMage significant. One of the biggest impacts it has is that it further helps to validate that InMage Systems' Scout is enterprise ready as HDS is both a conservative company and a storage provider that sells primarily into enterprise accounts.
HDS's willingness to co-brand and resell InMage sends a clear signal to enterprise IT managers that HDS has internally tested and found InMage worthy of the HDS brand and that Scout is ready for the rigors of enterprise workloads. Further, for those IT managers that may have been interested in InMage's technology but concerned about InMage's worldwide support capability, HDS's co-branding of InMage takes that concern off of the table as HDS clearly provides staying power that InMage by itself did not have.
Adding InMage Systems' Scout to HDS's solutions portfolio now opens up a number of new solutions possibilities that IT managers probably have not considered, especially if they are not familiar with Scout. This relationship provides:
A proven heterogeneous replication option that HDS can use either across their own product lines or to gain access to competitive accounts. Centralizing the management of CDP, replication and recovery across disparate midrange operating systems continues to be a lingering pain point for enterprise IT organizations. Now that HDS has entered the scene with InMage, this no longer needs to be the case.
InMage Systems' Scout works with an organization's existing network, server and storage infrastructure that requires minimal or no changes to it in order to deliver these benefits. Using this new solution from HDS gives IT Managers new found flexibility to centrally implement and manage recovery solutions across their existing environment whether or not they are current HDS users.
Further, HDS's addition of InMage gives IT managers not accustomed to working with HDS new reasons to evaluate them. Since InMage works in conjunction with any storage system, these IT managers can now add HDS to their list as an enterprise software provider.
An entrée for HDS into next generation data protection technologies for DR. Up to this point, IT managers really could not look at HDS from the perspective of providing a comprehensive, common way to protect all of an organization's applications. That changes with the addition of InMage to HDS's solutions portfolio.
Next generation data protection technologies that are new to HDS include CDP, heterogeneous asynchronous replication, application failover/failback, WAN optimization, and recovery automation. Automating recovery is especially critical as more enterprise server infrastructures look for simplified ways to test the failover and failback of virtualized servers and the applications that they host.
IT managers in enterprise organizations know they need to tap next generation data protection technologies to provide rapid, reliable recovery of an increasing number of application environments - not just for mission-critical environments. InMage System's Scout provides HDS customers with exactly that. So with HDS's announcement today that it is adding Scout to its portfolio of storage solutions, enterprise IT managers now have a new option available to them from a storage provider that has a strong history of bringing stable, proven solutions to enterprise customers. ]]>
40% of InMage Systems Customers See a 200% Return on Investmenttag:inmage.dciginc.com,2009://14.10832009-07-23T10:00:00Z2009-07-23T10:00:00ZRecent feedback from InMage Systems' existing customer base indicates that 100% of them use its Scout software for disaster recovery. That probably comes as no surprise to anyone familiar with Scout or its heterogeneous recovery capabilities. But what may come as a surprise to some is that nearly 40% of these existing Scout users are seeing a 200% return on investment (ROI) in Scout because of how it can be used in multiple ways in a company's IT infrastructure.Jerome M. Wendthttp://sales.dciginc.com/about/jeromemwendtbiography.html40% of these existing Scout users are seeing a 200% return on investment (ROI) in Scout because of how it can be used in multiple ways in a company's IT infrastructure.
Achieving a 200% ROI on any investment is only possible when organizations find some way to leverage a product or software they are using for one purpose for some other critical business need. This is exactly what is occurring within the ranks of InMage Systems' customer base. While they initially purchased and deployed Scout to solve their internal business requirements for disaster recovery, 40% of InMage Systems' customer base is leveraging it as a front end to their existing backup infrastructure.
The motivation behind using Scout for multiple purposes is two-fold.
First, InMage's customer base is trying to solve existing backup problems for their physical servers. Many of them were backing these servers up to tape and experiencing backup window, data loss on recovery, recovery time, and/or recovery reliability problems. Given its continuous data protection foundation, Scout eliminated backup windows, enabled them to meet very stringent RPO/RTO requirements, and gave them excellent recovery reliability (based on the fact that Scout leverages disk-based recovery media).
Second, organizations are almost universally looking to virtualize their server environments to reduce upfront capital expenditures along with cutting ongoing operational power and cooling costs. But as they virtualize servers, they find that traditional backup software agents place a heavy burden on the virtual machine's host physical server during backup times so they are actively looking for new, much lighter weight options to backup and protect these servers.
This is where InMage Systems' existing customers are realizing their 200% ROI from Scout and, in the process, solving their aforementioned backup problems. In addition to using Scout for disaster recovery they are now leveraging it to complement their existing backup infrastructure while replacing backup agents on many of their physical and virtual servers.
They are able to achieve this because Scout uses a filter driver (as opposed to an agent) to capture writes in real time as they occur, sending them across the LAN to an InMage CX (highlighted below). All of the functionality to manage data retention for both local and disaster recovery uses resources on the CX, rather than on the production servers, freeing up significant resources on the production servers.
This is what makes it possible for InMage's customers to remove backup agents from their application servers - they are no longer required to get at the data - and see this doubling of value of their investment in Scout. Once the copied data is on the CX, an AppShot (application-consistent recovery point) can be created, mounted on a recovery server target (which can act as the common backup "workhorse" for a number of different servers) and a backup to tape can be performed - all without introducing any overhead on the server - physical or virtual.
AppShots are retroactively created to represent any previous data state for a given server. The end result for administrators is that they have more headroom left on their production servers, pay less on licensing fees and maintenance for backup agents, get better recovery capabilities than they had before, and minimize tape handling.
Since all near-term recoveries can be performed directly from disk by Scout, customers move to a scenario where they may only create a tape backup once a week or once a month as a second line of defense. Using Scout they now get both better backup and disaster recovery for half the price.
Organizations are always looking for better, faster and more economical ways to do more with less and these tough economic times are putting a new exclamation point on doing exactly that. However, 40% of InMage Systems' existing customers are finding out that by leveraging Scout for backup in addition to disaster recovery, they can bring disk into their backup infrastructures, improve their backup success rates and then deliver faster, more reliable recoveries both locally and remotely. This combination of features and ROI should resonate with anyone in any organization. ]]>
Recovery Should Not Displace Backup as the Next IT Headachetag:inmage.dciginc.com,2009://14.10582009-06-29T10:00:00Z2009-06-29T10:00:00ZMost organizations recognize that the introduction of disk into the data protection process is fundamentally changing the landscape of how data is protected. But what organizations are failing to entirely grasp is how disk fundamentally alters how applications can be protected and recovered. Disk can minimize the impact of data protection on production applications while providing shorter recovery times and improving recovery reliability. It is as organizations come to this realization that they also begin to grasp how recovery can displace backup as the next IT headache.Jerome M. Wendthttp://sales.dciginc.com/about/jeromemwendtbiography.htmldisk fundamentally alters how applications can be protected and recovered. Disk can minimize the impact of data protection on production applications while providing shorter recovery times and improving recovery reliability. It is as organizations come to this realization that they also begin to grasp how recovery can displace backup as the next IT headache.
Backup has been a problem within organizations for so long that most IT managers are just relieved that troubleshooting last night's backup issues is no longer at the top of their daily "To Do" list after they deploy disk. But now that their data is protected, the bigger issue of managing the timely recovery of their applications takes on a whole new life.
Organizations may use multiple means - backup software, replication software and clustering software - to protect and recover mission critical applications while primarily using backup software to protect applications not deemed "mission critical".
Yet where they fall down is in providing a single, common mechanism to recover key enterprise applications such as Microsoft Exchange, SQL Server, SharePoint and Oracle. Organizations may now rely on backup software to recover some of these applications, replication software to perform recoveries for other applications and clustering software for yet another set of applications.
So what emerges over time is that the money and manpower that organizations once spent troubleshooting backup problems is now redirected towards managing the recovery of their applications using these different software tools. This adds both cost and complexity back into the infrastructure.
A better approach for organizations to take as they look to redesign their backup infrastructure is to adopt a broader mindset that is based on "Consolidated Recovery" and then select a solution that supports that approach. While I have previously defined some of the characteristics that a consolidated recovery solution should possess, the most important aspect to keep in mind is that regardless of the solution deployed, it should NOT result in recovery displacing backup as the next IT headache.
It is for this reason that organizations looking to solve their backup issues without creating new recovery issues should take a hard look at InMage Systems' Scout software. It provides organizations with a common software platform that they can use to protect and recover these different applications. For example, using Scout organizations can:
Centrally protect and recover these different applications using one software-based tool. This feature of Scout eliminates the need for organizations to configure backup software to recover one type of application, replication software to recover another and clustering software to recover yet another. Because Scout continuously replicates data and constantly creates application recovery check points as part of its replication process, organizations can use just one product instead of many to protect and recover all of their applications.
Cost effective recovery of "Tier 1" and "Tier 2" applications. User expectations for the recovery of their applications are rising - and not just for mission critical applications. Users do not want to wait hours for IT to recover an application server just because IT classified a server as "Tier 2". From the end-users' perspective, if they are using an application and it goes off-line for whatever reason, they stop working. So to those users the application is mission critical even if IT may not classify it that way.
Using Scout, IT can extend the same level of near-real time recoveries to multiple different applications with minimal increases in costs since only one software platform, not multiple, are needed. Further, Scout may actually lower IT's support costs while improving service levels. IT staff no longer need to monitor each application server to determine if and when they need to reclassify a "Tier 1" as "Mission Critical" since all applications protected by Scout are afforded the same high levels of protection and recoverability.
Improve your data protection and recovery methods while showing an ROI. Using multiple data protection products create real, ongoing hard dollar OPEX costs in the form of licensing fees. Backup agents can be removed from production servers since Scout is now effectively collecting data necessary to support any recovery operation. If you still want to dump data to tape, you can back up disk-based images created by Scout, effectively off-loading production servers. By consolidating on Scout, organizations can lower software agent costs and minimize the impact of agent maintenance operations. As they protect and recover more applications with Scout, the savings should continue to increase.
The growing adoption of disk for use in the data protection process is fundamentally changing how organizations think about backing up their data. However organizations are failing to fully realize how eliminating their backup problems is creating new recovery challenges that current data protection technologies do not address, address only in part or are so expensive that organizations can only offer these high levels of recovery to a small subset of their application servers. Only by implementing software such as InMage Systems' Scout that takes all of these factors into account can organizations begin to solve their backup and recoveries once and for all by consolidating backup and recovery under one roof. ]]>
It's Time to Contemplate Consolidated Recoverytag:inmage.dciginc.com,2009://14.10422009-06-10T10:00:00Z2009-06-10T10:00:00ZBounce the phrase "consolidated recovery" off of most individuals in IT and you are just as likely to get a blank stare as a good answer as to what it means or how to accomplish it. Most IT staff keeps so busy on a day to day basis just managing their assortment of backup, clustering and replication products that they never get much beyond focusing on the protection and recovery of each application. So for them to contemplate the consolidation of protection and recovery using just one methodology has more than likely not even crossed their minds.Jerome M. Wendthttp://sales.dciginc.com/about/jeromemwendtbiography.htmlthe consolidation of protection and recovery using just one methodology has more than likely not even crossed their minds.
Most organizations have different tiers of protection and recovery simply because that it is the conventional wisdom of how they should approach data protection and recovery. For example, organizations use:
Backup software to protect applications that can typically withstand longer outages (two (2) hours or longer) and/or are tolerant of recoveries of application data that is hours, days or even weeks old.
Storage system-based replication software to replicate data from one storage system to another (usually located at another site) for applications that they need to recover in minutes to hours
Clustering software that is either operating system based such as Windows 2003 Microsoft Clustering Server (MSCS) or Windows Server Failover Clustering or replication software that is part of an application such as Microsoft Exchange's Standby Continuous Replication (SCR) or Cluster Continuous Replication (CCR). These clustering and/or replication technologies provide recovery of the application and/or application in minutes or tens of minutes.
So if such a product did exist, it would have to satisfy all three of these different approaches to data protection and recovery. Each one addresses a specific business need that would not disappear if they were consolidated. So some key attributes that such a product would need to possess include:
Be cost effective. This is probably the biggest point in the minds of end-users. The primary reason that organizations continue to use tape instead of disk is that backup is viewed as an expense and right now the last thing any organization wants to do is spend more money on backup. Since this product would need to protect everything from lowest tier to the highest tier application server, it needs to be sensitive to the cost constraints of these lower tier application servers which make up the bulk of servers in most organizations.
Simple to install, configure and manage. IT needs less complexity, not more, and while a consolidated recovery product sounds great on the surface, if they have to baby sit it all day long, what does IT gain? Whatever the new product looks like, it cannot require more time to manage and ideally should require a lot less while delivering the benefits of these other solutions.
Create a point in time snapshot of their application data. At a high level, this is what backup software does on a daily basis even though rarely does anyone refer to it this way. Organizations will continue to need a static point-in-time copy of their data so they can recreate what their environment looked like at that point in time should a data corruption occur or they are subjected to an eDiscovery search when they need to substantiate who knew what and when.
Replicate data locally or remotely irrespective of the application or operating system. As organizations continue to move up the stack in their application server tiers, some applications will require near-immediate recovery (within 30 minutes to an hour) either locally or remotely. So the product must provide asynchronous replication and support data recovery anywhere they need it when they need it.
Provide near-real time failover. Clustering software is often put in place based on the assumption that it provides real-time failover. While this is true in some cases, if more organizations look closely at how the clustering software on their mission critical servers is configured, it is likely configured in Active-Passive mode where if one node fails, the other takes over the application processing within minutes at best and can take more than an hour in many environments.Any new solution should therefore meet these requirements of recovering an application in minutes or tens of minutes locally or remotely.
There are obviously other requirements that such a "consolidated recovery" product would need to have. But from these points, one can begin to get a picture of what a product that delivers "consolidated recovery" would need to look like. In short, it has to deliver on the best elements of backup, replication and clustering software without requiring all of the associated costs and management overhead that managing them individually entails now. In a forthcoming blog, I will take a look at how InMage Systems' Scout is already positioned to deliver on this emerging concept of consolidated recovery. ]]>
Achieve Faster, Cheaper and Better Recoveries Using Asynchronous Replicationtag:inmage.dciginc.com,2009://14.8812009-05-19T10:00:00Z2009-05-19T10:00:00ZSynchronous replication may be viewed by users as the "Gold' standard when it comes to achieving the highest levels of application availability for business continuity and disaster recovery. But as I previously discussed, using synchronous replication for business continuity and disaster recovery can actually take longer and cost more for organizations to remotely recover applications than if they use asynchronous replication. Now organizations can use asynchronous software like InMage Systems Scout to deliver the same or better results as synchronous replication at a substantially lower cost.Jerome M. Wendthttp://sales.dciginc.com/about/jeromemwendtbiography.html
discussed, using synchronous replication for business continuity and disaster recovery can actually take longer and cost more for organizations to remotely recover applications than if they use asynchronous replication. Now organizations can use asynchronous replication software like InMage Systems Scout to deliver the same or better results as synchronous replication at a substantially lower cost.
To deliver synchronous type results using asynchronous replication software, Scout does the following:
Uses continuous data protection (CDP) to track all changes to application data. One of the knocks on asynchronous replication is that it may only replicate the delta changes over a specified period of time. When configured this way, the software does not track every write nor does it constantly send changes to the target but only replicates changed blocks at intervals (say every 15 minutes) as defined by the user. Scout uses CDP so it functions just like synchronous replication in that maintains write-order fidelity by capturing and replicating all changes to application data. This ensures organizations can roll forward or roll back to recover to any point-in-time, not just a specified a periodic point in time.
Is application aware. To recover an application at a remote site requires application integration so that data at the target site is kept in a consistent and recoverable state. Scout integrates with applications such as Microsoft Exchange, SharePoint and Oracle so that organizations can fail over and recover those applications at a remote location.
However Scout "one-ups" synchronous replication in three important ways:
Organizations can keep their existing data center infrastructure in place. Synchronous replication if done on a storage system can require organizations to first purchase like storage systems for the source and target site, migrate all of their production application data to the new storage system and then license the synchronous replication software. This can run into the millions of dollars to configure. Using Scout, organizations can keep their existing infrastructure (servers and storage) in place and replicate between dissimilar systems at the source and target sites. Not only does this eliminate the up-front costs but it speeds the deployment of the solution.
Offers checkpoints for point-in-time recoveries. The downside of using synchronous replication that no one likes to talk about is that it replicates both good and bad data. So if a corruption occurs or bad data is loaded into a database at the production site, it is automatically replicated to the target so organizations still may need to resort to recovering the application data from a backup. Using Scout and its CDP technology, even if data corruption occurs or bad data is loaded, organizations can roll back to a known good point-in-time and recover their data without needing to resort to some other recovery mechanism (snapshots or backups).
Can recover the application faster. This almost seems like a paradox that one can recover an application faster using asynchronous replication than synchronous but it may hold true in most environments. The only way a recovery will occur faster using synchronous replication is if all components including the server, network and storage are in sync. If only data on the storage system is being synchronously replicated, organizations still need to bring up servers at the remote site, move the IP addresses to the new servers and then hope you have a consistent point in the replicated data from which to recover. Since you have to do all of this anyway, Scout enables organizations to accomplish all of this without all of the associated server, network and storage expenses.
Synchronous replication is a great technology and is certainly needed to satisfy some application requirements. But organizations need to take a hard look at the benefits they expect to receive when deploying synchronous replication and the benefits that they actually will receive. Products like InMage Systems Scout have significantly closed the gap between what synchronous and asynchronous replication software delivers. The features that Scout delivers are now so substantial that most organizations will realize all of the benefits (and more!) of synchronous replication by using Scout while simultaneously lowering their costs and improving their time to recovery for more of their corporate applications. ]]>
Separating Fact from Fiction when Using Synchronous Replication for DRtag:inmage.dciginc.com,2009://14.8632009-05-05T10:00:00Z2009-05-05T10:00:00ZSynchronous replication is a technology that organizations often view as synonymous with the highest levels of application availability. In fact, a SearchStorage article entitled WAN Mirroring and Replication written a little over a year ago even makes the assertion that organizations using synchronous replication can achieve recovery point objectives (RPOs) that remain near zero with recovery time objectives (RTOs) typically on the order of minutes. But is this assertion about synchronous replication really true and under what circumstances? And is it possible that asynchronous replication can actually deliver better RPOs and RTOs over a WAN for disaster recovery (DR) than synchronous replication?Jerome M. Wendthttp://sales.dciginc.com/about/jeromemwendtbiography.html
article entitled WAN Mirroring and Replication written a little over a year ago even makes the assertion that organizations using synchronous replication can achieve recovery point objectives (RPOs) that remain near zero with recovery time objectives (RTOs) typically on the order of minutes. But is this assertion about synchronous replication really true and under what circumstances? And is it possible that asynchronous replication can actually deliver better RPOs and RTOs over a WAN for disaster recovery (DR) than synchronous replication?
Synchronous replication is often held out as the "Gold" standard if organizations want to achieve the highest levels of availability and recoverability for their applications. It is true that synchronous replication applies writes to both the source and target sites in lockstep, ensuring that the data states at both sites are always in sync. The downside to this approach, however, is that it may adversely affect application performance at the source site.
The distance to the remote site - and therefore the laws of physics - determine how long it takes to apply the write at a remote site, with longer distances imposing higher latencies. At some point, this imposed latency will begin to adversely affect application performance at the source site. The viability of using synchronous replication for DR will depend upon the response time requirements of different application environments, but most organizations will not use synchronous replication when the distance to the remote site exceeds 50 kilometers.
Organizations generally assume as long as they remain within the distance limitations of the application, they can successfully fail over and recover an application at a remote site. This assumption may lead organizations to select synchronous replication as their preferred replication option. But is the decision to select synchronous replication for remote DR based on fact or fiction?
With synchronous replication, organizations may assume that when the data in the two sites is in sync, they can fail the application over from the primary site to the remote DR site at any time, enjoying zero data loss and near real-time application recovery. However, this assumption may or may not be true depending on how the environment is configured. To achieve this, minimally the following must hold true (this is not meant to be a comprehensive list):
The servers at the remote DR site are "aware" of the state of the application servers at the production site and can initiate a recovery. Data being synchronously replicated to the remote site is only part of the equation. If an application recovery is to occur at the remote site, there must be some sort of event that triggers the failover of the application itself from the production site to the DR site. If the software used to replicate the data has no awareness of the state of the production application, there is no way to successfully fail over the application over to the DR site so processing occurs uninterrupted.
The data must be in a consistent state at the remote site. Just because data is synchronously replicated from the production site to the remote DR site does not mean that the data at the DR site is in a useable condition. Any number of events can occur that make the state of the data at the remote site unusable and unrecoverable. The WAN link between the two sites can be interrupted or broken. A write transaction may not have completed at both the production and DR site when a disaster happens. The application may not have flushed its buffers on the production server so it is holding some writes in its queue.
Unless all of these tasks are perfectly orchestrated such that the copies of data are in sync, organizations must assume the data at the remote DR is not in a consistent, recoverable state even though the data is being synchronously replicated. In fact, organizations will likely find that the vast majority of the time that they cannot do a real-time failover of a production application to a remote site in part because the data at the remote site is not in a consistent state with the production site.
There must be a mechanism to bring the application server in the remote DR site into a production state. Organizations may need to take any number of steps to recover the application at the remote site. They need to find a past checkpoint (these checkpoints tend to occur about once every 15 minutes for database applications) where the data at the remote site is in a recoverable state. Then once they find this checkpoint, they need to apply writes that have occurred since the checkpoint occurred. Organizations also need to change the network setting so the application server at the DR site assumes the "primary" role, notifying other applications in the network that this application is now operating from a remote DR site.
Like I said, this list is not meant to be a comprehensive list of everything that an organization needs to consider when implementing synchronous replication. Rather it is meant to point out that organizations cannot and should not assume that merely implementing synchronous replication will provide real time application availability or failover. In fact, one IT director at a New York financial institution recently discovered that after implementing synchronous replication it still took him and his staff over 40 minutes to fail over an application server from a production site to his DR site.
Organizations need to exercise a great deal of caution when implementing synchronous replication and should not assume that synchronous replication is synonymous with instantaneous application recovery, especially when it comes to recovering applications at remote DR sites. If anything, by the time one looks at the costs and different steps that one has to go through to support synchronous replication, a solid case for using asynchronous replication in lieu of synchronous replication can be made for remote DR. In an upcoming blog entry, I'll take a look at how one such asynchronous replication product, InMage Systems Scout, can actually deliver a faster, simpler and more economical solution for remote DR for application servers. ]]>
Displacing Backup is the New End Game for Replication Softwaretag:inmage.dciginc.com,2009://14.8012009-04-02T10:00:00Z2009-04-02T10:00:00ZReplication software is increasingly entering the conversation as the logical replacement for backup software in client environments. Yet replicating data is really the easy part. Integrating the replication software so it becomes part of the fabric of a company's infrastructure is a far more difficult task. It is also one of the reasons that replication software has, to date, made so little headway in terms of displacing backup software for enterprise wide data protection. But as replication software matures, that will change.Jerome M. Wendthttp://sales.dciginc.com/about/jeromemwendtbiography.html I recently had a chance to speak with Peter O'Brien, InMage Systems Vice President of Business Development, about what features he now sees driving the adoption of InMage Systems' Scout in customer accounts. While Scout continues to have success as a business continuity solution, he sees more companies starting to use it to address other immediate business needs that they have. For instance, one company recently started to use Scout to measure and forecast data change rates in its environment.
But displacing backup software with replication software on servers is becoming the new end game for replication software. Replication software will never completely replace backup software as backup software is still needed to manage tape drives and tape libraries as well as the tape cartridges themselves. However replication software is certainly becoming a more viable option to displace backup software on the servers as more environments move towards disk as a backup target. Further, more organizations need near-zero backup windows and faster recovery times which are features that replication software, not backup software, is better equipped to provide.
So why have companies not adopted replication software already? The answer is simple according to O'Brien. Most replication software does not provide enough other functionality that organizations need to justify its wide-scale implementation. Features that he sees as replication software needing to do a better job of providing are the support of data movement, data migrations and greater application extensibility.
He notes that replication software received a big boost over the last few years with the introduction of continuous data protection (CDP) technology that tracks most or all changes to production data. But CDP alone has not been enough to push replication over the top. Backup software has decades of technology behind it, a management interface and policies that administrators are accustomed to using and deep integration with the many applications that it protects.
The other issue is that as organizational data stores continue to grow, administrators need simple and effective ways to migrate and move this data locally and remotely. Pure replication software may or may not handle this task very well or, if it does, it only moves or migrates for one server or one application, not every server in the enterprise. As a result, it is really not suitable for wide scale deployment.
But a number of things have changed in the last few years that now make replication software products like Scout viable for enterprise wide deployments including:
Improve data movement and migration capabilities. Scout can move and migrate data between different storage platforms so organizations can recover data locally or remotely.
It has application level plug-ins. This means that as replication occurs, Scout prompts the applications to flush their buffers and create consistent recovery points. These consistent recovery points can be used for remote recoveries or even as a source for off-host backups.
It can manage multiple replication jobs from a central console. Scout does not require administrators to log onto a specific console on each server in a replication pair. Rather it can manage replication and recovery for all servers performing replication from a central console which is needed for enterprise deployments.
In talking to O'Brien, it is clear that replication software in general and products that provide CDP functionality have come a long way in the last few years. While they are not all of the way there yet, the gap has narrowed significantly and I would expect by late 2009 or sometime in 2010, the final step in the process - a tight integration between backup software and replication software - will be complete. At that point - "Watch out!" as the reasons to replace backup software with replication software will become so compelling that organizations will have no excuse not to do so. ]]>
How One Company Built a Business Case for Its Disaster Recovery Highwaytag:inmage.dciginc.com,2009://14.7962009-03-26T10:00:00Z2009-03-26T10:00:00ZIn a previous blog, Dr. James Tu, the Information Security Officer at a real estate services company, discussed how he had sought out an affordable and workable enterprise-wide disaster recovery solution from an uneven landscape of replication products and found one that met his needs right under his nose. By turning on a feature in InMage Systems' Profiler which he had previously obtained to measure data change rates on his application servers, he converted it into InMage Systems' fully functioning replication software, Scout. But now he still had to assess how well Scout would fit into his existing infrastructure and then build the business case to justify it.Jerome M. Wendthttp://sales.dciginc.com/about/jeromemwendtbiography.html
Profiler which he had previously obtained to measure data change rates on his application servers, he converted it into InMage Systems' fully functioning replication software, Scout. But now he still had to assess how well Scout would fit into his existing infrastructure and then build the business case to justify it.
To verify Scout's replication capabilities, one of the tests that Dr. Tu performed was to replicate data between the source and target and then verify he could recover the replicated data at the target site. A key Scout feature that he examined was Scout's s ability to support the creation of virtual mount points at the target site. To create this virtual mount point, Scout would periodically introduce a marker into the replication stream on the source so that the target would know that the replicated data was consistent and recoverable and could know the appropriate point to mount the replicated data by looking for the markers.
Something else Tu uncovered that he did entirely anticipate was how this virtual mount point feature was going to solve other business problems. He had discovered during his business impact analysis phase that a number of his production databases were experiencing performance issues. These performance issues were specifically showing up when his company ran reports against these databases.
Using Scout and its virtual mount points feature, Tu could replicate the production database to a target. Once replicated, the application team could mount this database on the target server and use the available compute power on the target servers to generate these reports. This reduced the load on the production databases since reports no longer needed to be run on them. Instead he could make use of the available computing and capacity resources at the target site for tasks that were important to the business but not mission-critical which helped to contribute to his business case for purchasing Scout.
He also found that by using Scout's virtual mount point feature eliminated his need to rely upon storage system snapshot tools which also helped to cost-justify the solution. Going forward he no longer needed to license snapshot software from storage vendors for application recoveries but could instead use Scout for the same purpose.
The final way he discovered that Scout could cost-justify itself was that it could also eliminate his need to pay for backup licenses on every application server. In the same way he was running database reports on the target servers in his DR site off of Scout's virtual mount points, he could also run backups off of these virtual mount points as well. This meant all he had to do was purchase a backup software license for the target server which further reduced his ongoing operational costs and helped to cost-justify his purchase of Scout.
As Tu discovered, business continuity software such as Scout is providing value well beyond just creating fast and affordable DR for the majority of his corporate application servers. Tu started out using Scout to measure data change rates and then eventually evaluated it based upon its ability to deliver an enterprise-wide DR solution. However he ended up partially cost-justifying it based upon the number of day-to-day operational issues it solved in his company. While Tu is still looking for InMage to provide better integration with existing backup software, he was able to successfully put down the foundation of a DR highway for his company while partially cost-justifying it through the creation of a more stable and functional environment for his current backup and reporting requirements.
In part 1 in this 2-part series with Dr James Tu, Tu discusses the factors he considered before starting to build a DR highway for his company. ]]>
Implementing a Disaster Recovery Solution Can be as Easy as Flipping a Switchtag:inmage.dciginc.com,2009://14.7892009-03-19T18:00:00Z2009-03-19T18:00:00ZThe road to recovery is a journey that more organizations are embarking upon as they start to look beyond just successfully backing up their data and instead focus on cost-effectively recovering their business. Yet as organizations begin this journey, they find that that the road to recovery is strewn with obstacles and is neither well-traveled nor well-marked. This was the dilemma that recently confronted Dr. James Tu, the Information Security Officer at a real estate services company, who was seeking to carve out an affordable and workable enterprise-wide disaster recovery solution from an uneven landscape of replication products.Jerome M. Wendthttp://sales.dciginc.com/about/jeromemwendtbiography.html The impetus behind Tu's need to create a better disaster recovery and business continuity solution was predicated upon his company's needs to create new revenue streams as well as renew contracts with its existing clients. His company had existing DR contracts with IBM and Sungard so in the event something occurred at its primary data center the company had a location where it could recover its application. However those contracts only provided for 48 - 72 hour recoveries which no longer met its business requirements and it now wanted a solution that could ideally provide for recoveries in 4 hours or less.
To accomplish, Tu did a business analysis impact so he could begin to understand what sort of solution he needed. To arrive at the correct conclusion, he documented what kind of applications his company had in house, the financial impact that an outage would have on the organization and how well the current DR solution worked.
Once he had gathered this information, he determined that this was still not enough information to make a decision about what course of action he should take as he was missing a critical piece of information: the data change rates of the application. Without this data he could not appropriately size or budget for the LAN or WAN links between the primary and secondary sites that would carry the replicated data.
Adding to the complexity, his application servers used direct attached storage (DAS), network attached storage (NAS) and storage area networks (SANs). To capture the data change rates on all of these different servers, he needed a software tool that would non-disruptively capture all of that information and then someone who could help him interpret the data and make recommendations as to how to proceed.
To assist him in performing that task, he hired a consulting company that assisted him in performing the assessment. It brought in the software that collected the data they needed to understand the data change rates across all of the company's different type of application server so they could appropriately size the network infrastructure for replication.
Once Tu had this data, he set forth the following requirements in terms of selecting a solution that would serve as the DR highway for his company:
Had to be vendor neutral. Tu did not want to be tied to a specific hardware solution that was storage-centric.
Had to be application independent. He could not afford to have a dedicated replication solution for each application in his enterprise either from a cost or management perspective.
Could not be solely a file-based solution. Tu had to replicate all of the data on entire server volumes and only tracking changes at the file system level would not work.
Preferred to use a company listed on the NASDAQ or NYSE. Since his company was a large company, he wanted to select a solution from a company that was financially viable.
Based on these stated criteria, he initially evaluated two solutions from publicly traded companies whose products ran in the network - one ran on network switches and the other ran on appliances. However he found the solution that ran on network switches was still very immature for the mission-critical type of applications he was looking to support and the type of recoveries he was looking to achieve. The appliance approach that virtualized his storage infrastructure he found very intrusive as well as very time-consuming to simply configure to even do the testing.
Due to all of these struggles, he re-evaluated his criteria for selecting products and decided to remove the requirement for the vendor to be a publicly traded company since there does not exist a great number of publicly traded companies that do replication. Having removed this requirement, he went back to the consulting firm and asked what new options this created for him. The consulting firm suggested he use the same software they used to collect the data change rates in his DR environment, InMage Systems' Scout.
It turns out that the software the consulting firm had installed on all of his application servers was a slightly scaled down version of InMage System's Scout called Profiler. It performed all of the preliminary steps necessary to replicate the data up to the point of replicating the data in order to collect the data necessary to do the assessment. However its replication features could be turned on by simply flipping a switch in the Profiler software that turned it into InMage Systems' fully functioning Scout replication software.
In part 2 of this 2-part series with Dr James Tu, Tu discusses some of the unexpected benefits his company realized from using Scout and how these new benefits contributed to cost-justifying the introduction of Scout into his environment. ]]>
Enterprise Considerations for Keeping Replicated Data on Disktag:inmage.dciginc.com,2009://14.7802009-03-11T10:00:00Z2009-03-11T10:00:00ZA little over two years ago, an article appeared on the Smart Computing website that provided some tips for how to select the appropriate backup software for your PC. Of the tips it suggested, one of the more interesting was its recommendation to select backup software that stored data in a native format. Storing data in its native format eliminates the need to use backup software to recover it since any computer can access and recover the data. But this article was written for PCs. So the question that companies now need to ask is, "What do they need to consider before selecting a product that will allow them to store replicated data of its enterprise production servers in its native format?"Jerome M. Wendthttp://sales.dciginc.com/about/jeromemwendtbiography.html
article appeared on the Smart Computing website that provided some tips for how to select the appropriate backup software for your PC. Of the tips it suggested, one of the more interesting was its recommendation to select backup software that stored data in a native format. Storing data in its native format eliminates the need to use backup software to recover it since any computer can access and recover the data. But this article was written for PCs. So the question that companies now need to ask is, "What do they need to consider before selecting a product that will allow them to store replicated data of its enterprise production servers in its native format?"
Before answering that question, it's first important to understand why storing backup data in its native format works fairly well for PCs and laptops. First, the amount of data that actually changes on a day-to-day basis on most PCs and laptops is minimal so the performance overhead associated with replicating data on PCs and laptops is also minimal. Second, the replicated data only goes to one target device (network drive, secondary disk drive or even a USB flash drive) so it is fairly easy to configure. Finally, the individual responsible for managing the software is often the same person using the software so there are minimal or no concerns about central administration.
Now let's extend the discussion surrounding storing replicated or backup data in its native format to include production application servers. Can or should organizations look to replicate production data from these servers from production disks to backup disks and store the data in a native format? The answer is yes but organizations need to carefully consider what tool they use to do this since how it is implemented and managed differs from how it is done for PCs and laptops.
The biggest difference between the two is that the software that enterprise application servers require must be much more sophisticated. For instance, enterprise replication software needs to support many more operating systems such as Linux, Windows, and VMware, it needs to integrate with critical applications such as MS Exchange, MS SharePoint and MS SQL Server to create multiple, consistent recovery points and it may need to replicate the data to multiple disk targets.
To accomplish this at an enterprise level, enterprise replication software needs to scale so it can concurrently and centrally monitor and manage the replication and recovery of this data across multiple physical and virtual application servers. This is no trivial task since it requires the replication software to constantly adjust to changing conditions such as server overhead, network traffic and even outages in the network or on the source or target. Further, the job of copying or replicating the changes to the production data should not cause undue overhead on the server or negatively impact the performance of the application.
InMage Systems Scout distinguishes itself from other products in that it stores replicated data in a native format so any computer - physical or virtual - can use the replicated data for recovery. But equally or even more importantly, Scout includes the underlying architecture that enterprises need so they can scale it to manage the replication across tens or even hundreds of servers while still maintaining a central console to monitor and manage the replication and recovery of the applications.
Storing backup and/or replicated data stored in its native format is not a new concept as it has been used successfully on PCs and laptops for years and is now moving upwards into the enterprise. But before organizations take this jump and implement it on enterprise application servers, they need to look beyond the obvious benefits that storing data in its native format provides and consider how they will configure, manage and scale the software that does the replication so it works consistently across all of their enterprise servers. InMage Systems' Scout is one such software product that is architected so that it can handle and adjust to the requirements that enterprise applications have while still scaling to centrally manage the movement and recovery of replicated data in its native format anywhere in the enterprise. ]]>
This is what makes it possible for InMage's customers to remove backup agents from their application servers - they are no longer required to get at the data - and see this doubling of value of their investment in Scout. Once the copied data is on the CX, an AppShot (application-consistent recovery point) can be created, mounted on a recovery server target (which can act as the common backup "workhorse" for a number of different servers) and a backup to tape can be performed - all without introducing any overhead on the server - physical or virtual.