There are a lot of obvious reasons why companies need disaster recovery plans. Shareholders and other stakeholders want to ensure their assets are protected while employees want to do everything possible to ensure continued employment. These are very clear ramifications that are easy to understand. What is often less well understood is how clinical disasters manifest themselves over time.

Companies on the forefront of Disaster Recovery are focusing on addressing the disaster before it happens. Whether the disaster is Catastrophic or Clinical in nature, there are a variety of steps a company can take to reduce their risks. The key step to this new approach is to focus on the architectural availability during the application development and deployment phases.

The survivability of an application is MUCH easier to address during its development; API and Web Service layers can be written to tolerate latency and interruption and data replication techniques can be built into the application itself. Even simple recovery techniques such as the automated removal of corrupt data can have a big impact on the availability of a company’s critical applications

I have found it helpful to provide a framework for people to use when considering architectural availability. This framework is comprised of 4 key considerations.

Transactional Data. The ability for an application to duplicate transaction data to a second/remote site without the use of 3rd party tools or costly professional services is a key item to consider when architecting a bet-the-business application. A rule of thumb to consider is to always replicated data as close to the native transaction as possible. Examples include tools like Oracle’s DataGuard and Microsoft log shipping functionality.

Reference Data. Reference data is all the non-transactional data that is part of an application’s data set. Common examples are images or documents. Since they are not contained in the database but may have a direct correlation between specific transactions it is critical that they be “in sync” with the database records that point to them. The vast majority of these data types are contained in standard file systems and as such can be protected with any file system aware replication technology.

System State. Think of System State as all the meta data that defines how a server and its applications are configured. System State is often overlooked by application architects and as such can introduce significant delays in any disaster recovery exercise. Just imagine the effort required to rebuild a group of servers from bare metal using only documentation and you can quickly appreciate the importance of being able to reconstitute the way an application infrastructure is deployed.

Accessibility. In its most basic form can an application’s intended user reach the application without interruption that exceeds the particular application’s RTO. Specific issues that need to be considered here include; directory extensibility, DNS change propagation and private network connectivity.

By focusing on architectural availability and utilizing Hosting.com’s Critical Availability Service, a company can achieve a higher level of availability while optimizing their disaster recovery budget.

From: Stuart Oliver, Advanced Solutions Manager

To continue our disaster recovery blog series, I think it is important to explain a few common terms:

• Recovery Time Objective: (RTO) refers to the amount of time required to re-establish an application for end user access from the point of time where the application failed.
• Recovery Point Objective: (RPO) refers to the amount of data an application “owner” is prepared to lose.

In addition to RTO and RPO there are two other key terms that are often misunderstood and therefore incorrectly used:

• Restorable is a word used to describe an application that can only be re-built to the point of when the last available backup was completed.
• Recoverable is used to describe an application that can be re-built to the point of time when the original disaster occurred.

The key issue to understand here is that a recoverable environment is much more advantageous to a customer than a restorable solution, yet today the vast majority of organizations are still using restore centric services.

To add to the complexity, as applications have become more sophisticated ,the number of dependencies between separate systems have grown rapidly and the nature of these interconnections have also become more sensitive to failure – most mission-critical applications are interconnected to the point where they appear as one business system.

For many companies, the role of the Disaster Recovery Coordinator is rapidly reaching an end. Companies don’t want to spend monthly planning for an annual recovery test that for the most part has become irrelevant.

Therefore, companies are looking for new ways to address the availability of their critical applications. As discussed previously, the approach companies have taken to planning for disasters has quickly become obsolete as the interconnectedness between business systems has increased.

What Hosting.com did was to design a solution that addresses this interconnectivity and is backed by one of the industry’s most aggressive application-level SLAs. I invite you to take a closer look at our Critical Availability Service to see how Hosting.com is guaranteeing the availability of mission-critical applications.

Disasters on any level have always been a business threat, yet as we depend more and more on the technology and applications intertwined within our daily lives, disaster takes on a whole new meaning. So how have we come to this point? Let’s review some history for a moment.

In the mid 70’s several small backup computer facilities were established in the Midwest. In 1982 SunGard was spun off from Sun Oil as a computer services and recovery services vendor. In the early 80’s Comdisco computer leasing entered the recovery services business. Shortly thereafter both IBM and Hewlett Packard entered the market. All four of these firms (plus the 100 regional startups that were competing with them) had one thing in common – they all sold standby computing services to companies looking to avoid purchasing duplicate equipment and the associated software licenses.

In the early 80’s the term Disaster Recovery was coined to describe the services provided by these companies. Disaster Recovery was predicated on the idea that if enough geographically dispersed companies subscribed to emergency access to a particular computing platform then the overall cost of the service would be substantially less than each having their own dedicated equipment. The technology departments of the day established a new role called the Disaster Recovery Coordinator. This person’s primary job was to work with the various IT operation groups and their chosen disaster recovery vendor(s) to ensure the annual recovery tests were successful.

Disaster Recovery became officially defined as the process, policies and procedures related to preparing for the recovery or continuation of technology infrastructure on which critical applications operate.

In the early 90’s as organizations developed more sophisticated applications and work flows the Business Continuity industry began in earnest. Business Continuity was defined as the activities performed by an organization to ensure that critical business functions would be available to customers, suppliers, regulators and other entities that required access to those functions. In effect, Disaster Recovery (Technology) became a subset to the Business Continuity (Organization) industry.

In the late 90’s a number of organizations began to realize that a portion of their IT infrastructure was supporting business functions that could not withstand a 48-72 hour outage. It was then that many companies started to evaluate data replication technology. Previously, data replication was the exclusive domain of financial institutions and certain government agencies but with the rapid improvements in telecommunication performance the capabilities were becoming available to a broader audience.

Since then the High Availability market has continued to mature to the point where most organizations can afford some type of highly available infrastructure for their critical application(s). Cloud computing has played a major role in making Business Continuity and Disaster Recovery (BC/DR) available and affordable for a greater number of organizations.

Hosting.com offers Critical Availability Service (CAS) to meet the BC/DR needs for organizations of all sizes. CAS combines cloud and hybrid platform solutions, high availability managed services and a guaranteed SLA to provide you with a BC/DR infrastructure.

Something at the top of most IT professionals’ minds, besides Cloud computing, is business continuity and disaster recovery. Today we launched a new solution that addresses the most critical concerns of any business; uptime and application availability. Called the Critical Availability Service or CAS for short, this solution is a combination of complimentary managed hosting services bundled with excellent support and an aggressive SLA. CAS is designed to provide business continuity for businesses that have applications and systems that cannot be offline for any amount of time.

There are really two types of disasters that can affect organizations:

Catastrophic. These events are typically environmental (weather, geological) in nature but regardless of the cause are always widespread and well documented. The vast majority of disaster recovery budgets are allocated to addressing outages associated with Catastrophic events and for that reason are typically allocated across an organization’s entire technology infrastructure without consideration for a specific application’s impact on a company.

Clinical. Clinical disasters typically only affect a small number of companies and are often caused by human error or some sort of malicious event. These events are every bit as devastating to the operation of the company but due to their unique nature are seldom, if ever, explained or even documented. The result is that each affected company’s customers may change supplier or key employees may leave, both of which can place additional duress on a company. The net effect is that a single, focused event such as equipment failure or security breach can trigger the decline of a company to the point where it can no longer compete or ceases to grow.

Clinical disasters are every bit as devastating to the company they affect and for that reason organizations need to invest in their prevention instead of simply investing in just recovery mechanisms from catastrophic disasters. Read more about the new CAS solution now and talk with one of our recovery specialists to learn more about securing the continuity of your business.