Backup software is an integral part of many companies' core IT operations so the idea of replacing it with CDP software can be a discomforting thought for these individuals within organizations. However a "rip-and-replace" strategy is not necessarily the correct way to view CDP software either. To perceive it correctly, companies should first have a fundamental understanding of how backup and CDP software differ from one another, what specific problems that each one is designed to address and then how to best position these two respective technologies appropriately in your organization.
First, backup software and CDP software are respectively designed to take advantage of technologies that are/were widely available, inexpensive and abundant at the time they came into existence. In the 1990's, tape was much more inexpensive than disk so backup software was designed to take advantage of tape's lower costs as well as to manage tape media. Meanwhile CDP software has came of age in the 2000's as the cost per GB cost of disk has dropped - primarily as a result of the widespread corporate adoption of Serial ATA (SATA) disk drives.
Second, backup software was developed to satisfy lower corporate expectations for recovery that existed in the 1990's. Companies were once content to know that they could only recover data from last night's backup and accepted the fact that they had to make other provisions to recover data that was new or had changed since the backup occurred if they needed a more robust recovery. Today's application owners and users are not so forgiving of that approach anymore. CDP addresses these higher recovery expectations by giving application owners and end-users the option to recover data back to any previous point in time.
Third, CDP is intended to store data on disk for relatively short periods of time while backup software can store backup data on either disk or tape for relatively long periods of time. While companies can configure CDP software to retain data it has protected for any length of time, realistically speaking most recovery requests (~80%) for data occur within 7 days from when the data is protected and almost all requests (~95%) within 30 days of when the data is protected. Hence it makes sense to keep data on disk to expedite recoveries.
However keeping all data on disk forever is not always cost-effective and companies may still have internal or regulatory requirements to keep copies of this data for months and years. In these circumstances, using backup software to move the data from disk to tape is still the logical and best way to tackle this. Not only can backup software copy and/or move the data from disk to tape, but it can also manage the tape libraries and cartridges on which the data is stored.
Further, using CDP software in this situation not only complements backup software, it actually enhances its capabilities. Products like InMage Systems' DR-Scout have the capability to create consistent, point-in-time snapshots of data it protects and then presents these snapshots of the backup software for backup. This provides the backup software with unfettered access to previously backed up data, off-loads the overhead associated with the backup from the application server to the CDP server and expedites the transfer of the data from disk to tape since the backup job is not competing for server resources as frequently occurs on application servers.
So the short answer to the question I posed at the outset is that backup software and CDP software are both complimentary and competitive software packages. On server hosts I would classify them as competitive as CDP software potentially replaces the need for backup software agents. However once the data is centrally protected by the CDP software, backup software compliments CDP software by handling the management and movement of backup data from disk to tape to meet other concerns (such as archiving, regulatory, and retention) that the organization needs to satisfy.
]]>Companies may incorrectly view technology purchases in the same context as the purchase of a piece of furniture. When an organization purchases a chair, a table or a desk, the assumption is that the piece of furniture will essentially last forever (15 to 20 years). However companies should exercise caution to not apply the same mindset to technology purchases. The problems that hardware and software were designed to solve 5, 10 or 15 years ago are very different than the types of problems confronting companies today and no where is that more true than in enterprise data protection and business continuity software.
In previous blog entries I have gone into some detail how existing models of enterprise data protection and business continuity software may not satisfy today's business requirements. However navigating the transition from old to new data protection technologies like InMage Systems' DR-Scout that meet today's challenges is more complicated than just wheeling an old piece of furniture out and wheeling a new one in.
Too often, companies don't have a solid handle on how their current data protection software works, what its impact is on servers, what will occur if they remove it or how the new data protection software will perform. The lack of information about how the proposed data protection software will the impact the company's infrastructure puts everyone from the CIO down to systems administrators on edge. As a result, it leaves them reticent to make substantive yet needed changes to their IT infrastructure.
The information that companies need to gather in order to have the confidence to make these changes and then implement them includes:
Change is a necessary component to not just every organization's health but its ongoing survival. Making it so the prospect of changing out one technology for another does not strike fear in the hearts of individuals is a totally separate challenge but one that vendors need to appropriately address. Vendors can not and should not expect companies to take it on faith that their products will work as good as or better than existing technologies that companies already have in place. Companies should expect their vendors to provide them with a mechanism to gather the information they need and model how their environment will look so they can have the confidence that they can make such a change safely.
In this respect, InMage Systems' DR-Scout includes a modeling feature as part of its software called Profiler. It documents how the current production environment behaves with the current data protection software in place. However it also predicts the amount of data that changes daily, how well the data compresses and how much bandwidth that DR-Scout would consume if implemented. By first using Profiler that is a part of DR-Scout, companies can get before and after snapshots of what DR-Scout's impact will be on their environment without taking a huge leap of faith that few individuals in most companies are usually prepared to take.
]]>The outcome of trying to balance these conflicting priorities of high availability and immediate recoveries versus providing affordable data protection creates a zero-sum game for companies. No matter which application need they are trying to meet, they end up robbing from Peter to pay Paul because they can't put their finger on an application that provides enterprise-wide business continuity.
However the way to negate these unpleasant trade-offs is not working harder, more hours or kicking your system administrator, system integrator or technology provider in the backside a couple of more times in order to make the current solution work. The solution is to identify a whole new method to enterprise business continuity.
Think about how most enterprise business continuity solutions are engineered now. Host-based solutions are based on a one-to-one mapping between the source host on which the application runs and the target system. Storage system-based solutions only work for hosts attached to that storage system while network-based solution (appliance or switch) only work for those hosts that pass data through that appliance or switch.
All of these are incomplete for the enterprise business continuity needs that companies are trying to cope with today. Each of these are built with specific paradigms in mind (host-centric; network-centric or storage system-centric). Toss in the rapid adoption of server virtualization and it becomes evident that deploying any of today's solutions amount to nothing more than a zero-sum game.
A whole new paradigm is needed that accounts for DAS-attached servers, NAS-attached servers, SAN-attached server and the rapidly growing server virtualization space. That's why when one looks at the enterprise business continuity capabilities of what InMage Systems' DR-Scout delivers, it can take a little while to grasp how comprehensive it is. What makes it unique is not that it protects and recovers data from all of these different types of applications attached to storage in multiple ways. Other products can do that as well. What makes it unique is that it has put a foundation down to recover application locally or remotely back to a consistent point in time regardless of how what type of storage systems these application servers are attached.
Enterprise business continuity can feel like an exercise in futility and that you always have to give up some level of recovery or data protection in order to satisfy some other application recovery requirement. InMage Systems' DR-Scout gives companies the opportunity to stop making compromises about their ability to recover when disasters - large or small - strike. Instead, it starts to take companies down a path of protecting and recovering their data for any application server in the infrastructure and out of the mindset of, "What trade-off do I need to make today?"
]]>The trick is configuring, managing and monitoring these point products in such a way that they work together in a cohesive, unified manner. Not only is this nearly impossible to do, the cost and complexity of performing these tasks can quickly escalate when trying to manage and recover multiple applications across the enterprise at the same time.
The fundamental flaw that exists with using point products to deliver enterprise business continuity is they tackle it from an application, server or storage system viewpoint. This is an incomplete view considering the multitude of applications, operating systems and storage systems that exist in companies today and the unknown relationships and dependencies that exist between them. Trying to do one-to-one matches of specific point products to specific applications, operating systems or storage systems is unrealistic and will not deliver the desired outcome: an easy to manage, enterprise-wide business continuity solution with a centralized management vantage point.
This situation is further exacerbated by the fact that these point products are not managed by a common console or the same person. When all of these factors and costs are added in, companies need to ask the obvious question, "Why are we doing this and will it work?" Because at the end of the day, companies spend a pile of money to purchase all of these solutions with little or no assurance that they can recover from a disaster should one occur.
While one may expect organizations to take this more holistic view of business continuity, that is easier said than done. There are a thousand and one minor issues that executives, storage managers and IT staffers deal with on a day-to-day basis that are required to run an organizations' internal IT operations. In performing these tasks, it is easy for the responsibility of creating and executing on a vision that an enterprise-wide business continuity solution requires to slip through the cracks. It is also quite possible that these same individuals do not believe that such an enterprise-wide business continuity solution exists so they don't even bother looking for one.
In this respect, InMage Systems' DR-Scout provides companies with a mechanism to create and execute on converting a vision of enterprise business continuity into a corporate reality. Though DR-Scout supports heterogeneous application, server and storage environments, it also meets head-on the tactical issues that companies have on deal with a day-to-day basis in order to deliver on the vision of enterprise business continuity.
You can't introduce and manage enterprise business continuity software while neglecting daily tasks like backup and recovery, creating copies of data for testing and developing, or migrating data between DAS, NAS or SAN-attached storage platforms. Using DR-Scout, you no longer have to. DR-Scout provides enterprises the ability to perform and manage all of these functions through one interface. In the process, companies can create and execute on a vision of building an enterprise-wide business continuity solution without taking their IT staffers away from the day-to-day tasks that keep their companies up-and-running.
]]>The bigger question is why are companies still failing to conduct business continuity tests in 2008? There are more data protection options than ever from which companies can choose and the costs for hardware, software and network bandwidth are significantly less than what they were 5 - 10 years ago. My thoughts are that the real reason enterprise business continuity remains so elusive is that companies find the complexity associated with using multiple point products precludes them from even attempting to test their business continuity plan and the thought of doing so enterprise wide is seen as impossible.
Consider how most companies attempt to perform enterprise business continuity now: Host-based software, storage hardware appliances and backup software are the three products that companies typically use for enterprise business continuity. Yet there are inherent problems with using all of these products when trying to deliver enterprise business continuity.
For example, to deliver business continuity using host-based software, companies need to license the software for both the source and target servers. The problem that emerges here is that host-based software is often tied to the host operating system. This prevents companies from creating a many-to-one scenario where data on multiple, different operating systems is replicated to one common platform. Instead each source host requires another host with a like operating system as a target in order to deliver business continuity. Even in this scenario, this only delivers business continuity for a limited number of applications or servers, not the enterprise.
In response to these difficulties, storage hardware appliances have emerged as an alternative means to deliver business continuity in an operating system agnostic fashion. Storage hardware appliances eliminate the requirement to have servers with like-operating systems as sources and targets while giving companies the flexibility to replicate data to remote sites.
But again, implementing and managing storage hardware appliances does not deliver enterprise business continuity, it only delivers business continuity for those servers using that appliance that may leave LAN attached servers unprotected and unrecoverable. Further, companies may find that the storage hardware appliance do not provide the recovery features that specific application servers need.
Backup software is the most prevalent method that companies use to provide business continuity though this option also has its fair share of problems. Primarily it is designed to provide once-a-day backups and manage tape libraries, not deliver simplified, near real-time business continuity.
In this respect, InMage Systems' DR-Scout addresses the concerns raised in Storage Magazine's survey as it provides companies an alternative means to deliver enterprise business continuity. Aside for its architecture that provides a single point of administration, support for multiple operating systems and LAN or SAN attached servers, it is designed with enterprise business continuity in mind so that the recovery testing is simplified, verifiable and data can be recovered either locally or remotely.
The idea that DR testing and business continuity is not routine is still an unpleasant reality for too many businesses and enterprise business continuity is still not feasible for most businesses. But for companies to move past just recovering some of their applications some of the time means they need to start to look past point products that only provide a partial solution. Looking to InMage Systems' DR-Scout will give companies the enterprise business continuity option they need without requiring them to make unpleasant decisions about which data and applications are more or less important than others.
]]>However storage managers need to look at this from another perspective. Which of the two do you believe will best meet your needs going forward? Is it the hardware that is based on three year old technology or the software that is based on ten year old technology? Looking at it this way can suddenly change one's opinion about which of the two is due for a swap-out.
Nowhere does this mindset hold truer than when it comes time to consider the replacement of a company's data protection software. Data protection software is so ingrained in corporate computing operations that just the mere thought of replacing it aggravates the ulcers of most storage managers.
So what would it take to make a storage manager feel comfortable about first introducing and then eventually replacing their existing data protection solution with a product like InMage Systems' DR-Scout? Here are some points to consider:
In most cases, a company will find that DR-Scout can measure their current environment; better protect and recover it, and introduce less overhead and create less of an impact on its servers and applications than its current data protection software. Since DR-Scout only captures changes to data as changes occur instead of trying to backup the data once a day, DR-Scout's net impact to server performance may actually turn out to be much less than the current data protection software. However because DR-Scout captures and tracks all of these changes all of the time, a company gains a new benefit of being able to recover its application data to any point-in-time much more quickly.
Storage managers are rightfully reluctant to change out their company's data protection software because it is generally better to deal with the devil you know than the devil you don't. But let's face it, ten years old technology is a life time in technology years and much of the data protection software that is in place today was designed to solve a very different set of problems. The good news is that because of the features that InMage Systems has built into DR-Scout, storage managers no longer need to feel like they have to go out on a limb to evaluate and implement DR-Scout before the swap-out of their company's current data protection software occurs.
]]>Microsoft's VSS works by using three pieces a requester, writer and provider. If you have heard about this, then skip to the last paragraph and wait for part 2 due later this week. The requester is your traditional backup solution. Requester's send collection inquiries to the application you want to protect. This application must understand the collection inquiry sent to it by the requester and needs a writer designed to support the application data and data types. The writer is written by the application developers, not the backup vendor, to ensure the most stable and consistent recoveries.
The legacy of a number of Windows and Linux-based replication software products was to solve a very specific problem in corporate data centers: provide near real-time server failover of mission-critical applications. In some cases, the availability of replication software pre-dated the availability of clustering solutions for the Windows and Linux operating systems so it was put in the position of having to provide real or near-real time failover capabilities for the operating system and the application. However as clustering found its way into operating systems, replication software started to evolve to take on a new, broader role: data protection for all corporate servers.
This evolution puts traditional replication software in more direct, head-to-head competition with backup software though we are just starting to see competition between the two. Most companies still need inexpensive media on which to store data so they rely upon backup software to copy their data and store it to tape. However that is changing. Low cost, high capacity SATA-based storage systems that meet enterprise availability and reliability requirements are now readily available even as user and management appetites for near-real time recovery for all corporate enterprise servers are growing. This combination of factors indicates that the time has come for disk-based backup.
This does not mean that traditional backup software and replication software are changing their underlying designs. Companies can configure backup software to backup to disk, but it will only backup data once a day to disk, not tape. This leaves any changes to corporate data between each backup window unprotected and exposed.
Replication software captures all of these changes but its objective is to provide an application recovery should the primary server fail so it captures every change but does not track and retain previous changes. Instead, it presumes companies want to recover applications to the last saved write, not some previous point-in-time, as replication software was designed to protect companies against server hardware failures.
This makes neither backup software nor replication software suitable to meet today's larger enterprise corporate data protection needs. The window that backup software leaves between each backup is too long. Replication software does not provide previous point-in-time data recovery options since it replicates all data - good and bad - and if the data it replicates is bad due to a data corruption, companies will need to recover the application backup software since it stores and manages multiple copies of the data.
It is these deficiencies in backup and replication software that InMage Systems' DR-Scout addresses. While it is replication software in the sense that it copies every change to application data, it also functions like backup software since it provides companies with a nearly infinite number of point-in-times to which they can recover their data. Since it combines these two functions in one product, companies can rely on one product regardless of what type of recovery they need to perform.
The corporate requirements for a standard method to deliver near real time data protection across the enterprise have changed significantly in the last decade. To only have the option to recover once-a-day or at the last point-in-time is too simplistic and no longer meets corporate expectations. InMage Systems' DR-Scout brings these two into balance. It gives companies the range of recovery options that they expect for their corporate servers at a cost that is in-line with what they pay to manage their backups now without introducing new levels of management complexity.
]]>To understand how the host-offload agent architecture works, it is easier to first describe how host-based architectures operate. Host-based replication agents initially replicate the data to a remote system by first making a copy of all data on the host system while monitoring and capturing new write I/Os. In this respect, InMage Systems DR-Scout is similar to most other host-based architectures and this one-time event creates similar amounts of server overhead, ranging from 10 - 20%, depending on the amount of data it needs to copy, available bandwidth and number of write I/Os occurring on the system.
The differences between the host-based and host-offload architectures show up most dramatically in how each one captures ongoing write I/Os. Host-based architectures make a copy of each new write I/O and then store the write to a disk cache. Then the host agent may do one of two things: it may read the writes back from disk and replicate them; or, it may read the copied write back from disk, compress the write, re-write the compressed write back to disk and then read it back again from disk before replicating it. This process of writing these copied write I/Os back to the disk cache once or twice is why agents on host-based architectures create such onerous server overhead. While the number of application reads and writes and network bandwidth all impact server overhead, writing the copied write I/Os to the disk cache is the task that slows most host based replication products.
DR-Scout's host-offload architecture management of these writes is the primary way it differentiates itself from host-based architectures. DR-Scout's agent is a "lite" agent in the sense that it does not copy write I/Os to a local disk cache. Instead it partitions out a small segment of server memory and stores these write I/Os in the server memory. The DR-Scout agent then copies the write from memory to the central DR-Scout Control and Media Server (called the DR-Scout CX) over an ordinary LAN connection.
The DR-Scout CX Server that receives the write is the other half of this equation since it is critical to delivering on the promise of the host-offload architecture. By immediately sending the copied writes to the DR-Scout CX Server, the CX Server bears the brunt of the workload and overhead of copying the write I/Os to disk, not the application server. This architecture makes the CX Server more efficient in handling replications tasks, even in performance intensive environments, than host-based replication architectures.
The host-offload architecture of InMage Systems' DR-Scout may sound on the surface like some slick marketing term that InMage Systems uses to take a company's eye off the ball. Nothing could be further from the truth. Rather it is the best way to describe a slick design that not only solves a thorny problem that host-based architectures do not address. In so doing, DR-Scouts' host-offload architecture more successfully supports virtual and performance intensive environments that pure host-based architectures can not address.
]]>The major difference between snapshots and CDP is that snapshots do not capture all application write I/Os like CDP. The reason that some argue that snapshots are as good as CDP is that companies can still achieve a point-in-time recovery when using snapshots in conjunction with database transaction logs. When doing a recovery, companies can select a specific snapshot and then replay the database's transaction logs from that point forward. This creates a point-in-time recovery similar to what CDP can deliver.
Despite this similarity, CDP provides three fundamental advantages over using a combination of snapshots and database transaction logs for recovery.
The major differentiators between snapshots and CDP are the ease of use and the scope of application recovery that they can provide. Snapshots will always introduce dependencies on database-specific transaction logs and specific people to deliver, at best, an application-specific recovery that is more complex to setup and manage. Conversely, a CDP product like InMage Systems' DR-Scout is designed to centralize, simplify and expedite application recoveries to multiple points-in-time. It can manage interdependent applications and eliminate undesirable dependencies on specific products or people. However, on a larger scale, CDP gives companies a higher degree of assurance that they can recover not just a specific application but the entire business back to a known, good point-in-time.
]]>The main problem with traditional backup software is that it was designed to solve yesterday's problems based on yesterday's computing infrastructures. In the past, companies essentially operated from 7 am until 7 pm giving IT the opportunity to run uninterrupted backup jobs at night; no one really expected IT to bring their applications back online in 30 minutes or less at the primary site, much less at a disaster recovery site; and companies did backup to tape, not disk. For the most part, companies pretty much held, and pretty much still do, hold their collective breathe if IT ever had to or has to recover any data at all.
Everyone knows this cannot continue. Companies expect IT to recover their data and applications; they expect to recover to disk, they expect their recoveries to work; and they expect IT to recover them in 30 minutes or less. So if you think your traditional backup software can deliver on any of those business requirements, you are operating from a false premise. The challenge that corporate IT faces today is not just delivering application and data recovery, it is delivering on the heightened expectations of today's corporate users.
"Can you recover your application data?" is not a trick question nor is it a technical mystery. The problem is that most companies are not properly realigning their software and processes to match the expectations of today's users or today's new computing environment. Companies serious about answering these tough backup and recovery questions need to start acting like these are real questions that have right answers.
InMage Systems' DR-Scout gives companies a viable, proven alternative to not only provide application data recovery, but scales out to backup and recover LAN attached servers across the enterprise. It addresses the recovery expectations of today's users and businesses by storing data to disk, providing point in time recoveries and giving companies local or remote recovery options.
Most importantly, InMage Systems is communicating to companies that application recovery is not hard nor is it a trick question. You can not solve today's problems with technology designed to solve yesterday's problems. InMage Systems' DR-Scout is representative of the new type of disk-based data protection software that companies may use to meet today's application backup and recovery requirements.
]]>Unfortunately none of these options is really an option anymore. New electronic discovery laws may require companies to search and produce data regardless of where it is located in the enterprise and retain it for specified amounts of time. Traditional backup software may not provide the frequency of backups or levels of recovery that companies need to adequately protect remote enterprise servers. Optimizing enterprise backups is a noble goal but is akin to boiling the ocean since it often accomplishes nothing and burns out the individual tackling the project. And who has millions of dollars to spend on protecting data whose value to the organization is dubious?
Yet user expectations for enterprise backup and recovery are now essentially the same regardless of where the server is located or what type of data it is. User expectations for near-real data recoveries (30 minutes or less) have increased in recent years due to advances in consumer technologies that provide near real time recovery. Now all enterprise users are beginning to expect - and in some cases demand - that their corporate IT department provide the same backup and recovery functions for their enterprise application data that is already available to home users.
So what is unique about InMage Systems' DR-Scout? Unlike other approaches, it delivers on these new expectations for the backup and recovery of enterprise servers for about the same cost as backup software. Some examples of what it does include:
Companies are at the point where they can no longer ignore the protection and retention of corporate data outsite of the data center but cannot afford to throw unlimited resources at the problem either. InMage Systems' DR-Scout provides the new type of approach to backup and recovery that companies now need without breaking the budget. It provides the immediate benefits of a higher level of application availability that enterprise users are coming to want and expect while putting companies in an excellent position to deliver an achievable disaster recovery plan for many of their enterprise applications.
]]>Asynchronous replication, near-CDP and real-time CDP bear some similarities in that all three technologies copy the write I/Os on a source system and then send the copied writes to a target system. They are also similar in that they first store a copy of the write I/O on a local disk cache on the source system; then send the copied writes to the target system as network bandwidth systems permits. It is at this juncture that the functionality of the three iterations of asynchronous replication begins to diverge.
Asynchronous replication is the earliest and simplest form of the three modes of replication but its flaw is that it only provides one recovery point - the current copy of data on the target system. While this replicated copy of data may provide a recoverable version of data for file systems with saved files, recovering open files or recovering usable instances of data for production applications like Microsoft Exchange or SQL Servers is not a guarantee. Replicated data for these applications needs to be in a consistent state. So unless the last copied write from the source to the target is the one that guarantees the open file's or database consistency of the application, companies will not be able to recover the application despite the fact they have a full copy of the data on the target.
This type of problem led to the introduction of asynchronous replication performing multiple snapshots in conjunction with application pauses; in essence, the creation of near-CDP. By integrating asynchronous replication and the application, companies could now acquiesce applications, flush all writes out of memory to create a consistent database image, and then take a snapshot of the data. The term "near-CDP" came into use because companies could create tens or even hundreds of snapshots over days or weeks to create multiple recovery points. However the problem with near-CDP was that recovery points were limited to the last recovery point - sometimes minutes or even hours old that is still insufficient for more corporate applications.
Real-time CDP represents possibly the third and final evolution of asynchronous replication. Rather than creating just one recovery point like asynchronous replication does or multiple recovery points that are minutes or hours old like near-CDP, real-time CDP supports the creation of application recovery points back to any previous point in time. Unlike the previous versions of asynchronous replication, it captures and journals every write I/O on the target system to provide a theoretically infinite number of recovery points.
All technologies evolve and mature over time and, in the same way, asynchronous replication has also matured. It has evolved from an early state of simply replicating data from a source to a target to providing multiple recovery points in its near-CDP form to what it is today: real-time CDP that provides for a nearly endless number of recovery points that meet the specific recovery requirements of today's world. What will be interesting to watch going forward is how will real-time CDP in general, and InMage Systems' DR-Scout in particular, evolve to provide higher levels of data protection for an even a wider number of enterprise applications and operating systems.
]]>