Testing Your Oracle Database Disaster Recovery Plan

Testing Your Oracle Database Disaster Recovery Plan

Your Oracle database needs its own disaster recovery (DR) plan to ensure that its recovery time objective (RTO) and recovery point objective (RPO) are met in the event of an outage. Some level of Oracle database disaster recovery testing is the only way to shake out problems with your plan/runbook.

Common issues that stall recovery in today’s interdependent environments include communication disconnects and missing data. It’s not easy orchestrating recovery across your database, storage, network, etc.

There are several Oracle database disaster recovery approaches to suit different recovery needs, along with a range of third-party options and custom configurations. Your DR plan can include a remote site, a failover system, and/or offsite storage for database backups and archived logs, among other components.

But whatever DR technology and plan you have in place, if you don’t test them ahead of time they might very well fail when you need them most.

DR testing types

The good news about Oracle database disaster recovery testing is the basics apply regardless of your test plan specifics. There are three DR testing types:

  1. Plan review. Here, the team that helped developed the DR plan closely reviews it to identify missing steps or process disconnects.
  2. Tabletop exercise. Similar to a play rehearsal, in a tabletop exercise, the people involved in executing the DR plan go through it carefully step-by-step to make sure they know what to do and the steps make sense and lead to the desired results.
  3. Simulation. A simulation attempts to mimic a real-world disaster scenario as closely as possible. It can validate whether your Oracle database disaster recovery team can restart the necessary hardware and software in sync with the RTO timeline and whether your backup, redundancy, and/or failover systems work as expected.

Which approach to do? Usually, that depends on the criticality of your database and the time since your last test. The more your database environment has changed since your last simulation, the more comprehensive your Oracle database disaster recovery testing needs to be.

Simulation scenarios

If you’re doing a simulation, it’s helpful to base it on a specific disaster scenario. Some of the most common real-world disaster scenarios your database could face include an external or insider cyber-attack, hardware failure, data corruption, human error, extreme weather, flooding, and fire.

DR plan testing frequency

How often should you test your Oracle database disaster recovery plan? It’s a function of the RTO for your database. If your RTO is 2 days, for example, you could get away with testing maybe twice per year. If you need high availability and near-instant recovery, you should plan on testing your Oracle database DR plans much more frequently.

Another variable in testing frequency is major changes in your Oracle database environment. You need to make sure that important changes are reflected in your DR plan, and you don’t want to find out during a real disaster that they’re not.

Next steps

The importance of Oracle database disaster recovery is hard to calculate. But it is easy to underestimate the financial and reputational impacts of disasters, which can add up to millions of dollars per hour in some industries. The general expectation has become that businesses are available 24×7, and tolerance for downtime is low.

At Buda Consulting, we know how much our clients rely on their databases. Our Reliability Review is a proven approach to evaluating your current risk scenario and deciding what level of protection you need. Contact us to find out more.

RTO vs RPO: Which Should You Prioritize for Disaster Recovery?

RTO vs RPO: Which Should You Prioritize for Disaster Recovery?

Disasters can range from a critical database crashing to a ransomware attack to the complete stoppage of your business operations. Whatever happens, two concerns top the list: how long will it take you to recover, and how much data will you lose? 

To make sure you don’t experience more downtime and/or data loss than your business can withstand, you need to define two key metrics that will guide disaster recovery planning for each of your critical workloads: 

  • Recovery Time Objective (RTO), the time between the onset of an outage and a return to business as usual
  • Recovery Point Objective (RPO), the maximum amount of data your business can lose before experiencing significant impacts, measured by volume or time

Ideally, all your critical applications would failover automatically and have continuous real-time backups, so your RTO and RPO would both be zero. But while technically possible, these measures are too costly for many businesses to contemplate. 

This is why you need realistic RTO vs RPO calculations to help design your recovery process and determine backup methods and frequencies. 

RTO vs RPO both start with application priority

When thinking about RTO vs RPO, it’s not a question of which metric is more important because they are interrelated. How long it takes to recover impacts how much data you’ll lose, and how much data you can afford to lose drives how fast you need to recover.

A best practice is to factor application importance and priority into your RTO vs RPO calculations. For example, the most mission-critical customer-facing services with the highest cost per minute of the outage may require a near-zero RTO, necessitating failover capabilities. Other applications, such as an HR database, might be OK with an RTO of 24 hours. 

With RPO, the more difficult it is to recover or recreate the data, the shorter the associated RPO should be. Mission-critical databases might require continuous, real-time replication for a near-zero RPO, while an RPO of 24 hours might suffice for data that you can recreate from your last backup using “pen and paper” sources. 

Accuracy matters

Another best practice is to make your RTO vs RPO estimates as accurate as possible. If you’re too conservative, you’ll end up spending more than you need to on backup services, redundant systems, etc. If you’re too lax, your business could face unacceptable risks that threaten its continuity and even survival.

In the end, it’s about balancing your IT budget against the business value/criticality of your IT services and associated data. Costs for backups, storage, and other technology add up quickly. But so do the costs of downtime and data loss—from lost sales to lost customers to a damaged reputation that can haunt you for years. A further RTO vs RPO consideration in regulated industries is whether the loss of certain irreplaceable transaction data (e.g., medical records or other personal data) could constitute a compliance violation and result in sanctions.

Next steps

What are the “right” RTO vs RPO numbers for your workloads? It’s often not easy to arrive at answers that satisfy all stakeholders. You’ll need to start by meeting with senior leaders to identify which systems and databases are central to operations and/or produce the most revenue. 

RTO vs RPO values for individual systems also needs to be embedded in the context of a risk-based, prioritized disaster recovery or business continuity plan for all your IT systems and databases in the aggregate. Balancing the factors mentioned above, from the nature of the event to the importance of the application/data to regulatory risks, takes objectivity and experience. Then there’s the question of how best to leverage technology to meet your agreed RTOs and RPOs.

For expert help with defining, selecting, and implementing the perfect disaster recovery solution for your databases, your business, and your budget, contact Buda Consulting

IT Disaster Recovery Planning Done Right

IT Disaster Recovery Planning Done Right

Every business needs proper IT disaster recovery planning as part of its overall business continuity plan. You might think you don’t need to plan for disaster recovery because disasters like floods and fires are so uncommon. But the top reason for IT disasters and significant unplanned downtime is human error: clicking a malicious link, accidentally deleting critical data, misconfiguring systems causing failures, etc. Other top IT disaster causes include commonplace occurrences like software bugs, hardware failures, power outages, and cyberattacks (including insider threats). Natural disasters are at the bottom of the list.

If you don’t have an IT disaster recovery plan, your recovery attempts will be chaotic and take much longer than if your team follows a well-considered, up-to-date plan that they are at least somewhat familiar with. Just a few hours of downtime impacts employee productivity and customer experience, leading to lost revenue and reputational damage. Days of downtime can threaten an SMB’s ongoing viability.

What does proper IT disaster recovery planning look like?

An IT disaster recovery plan describes your IT disaster recovery strategy and key goals and lists your IT disaster recovery procedures. Its purpose is to help your company take appropriate action to quickly recover IT operations and protect data. That means bringing critical systems back online in the right order, taking steps to reduce or eliminate data loss, and minimizing downtime for physical server hardware, user workstations, databases, etc.

A typical SMB IT disaster recovery plan has at least these core elements:

  • Description of recovery goals, such as the recovery time objective (RTO) for each critical IT system, and the recovery point objective (RPO), which is the maximum amount of acceptable data loss as a function of time. You also need to define what constitutes a disaster and when to invoke your IT disaster recovery plan.
  • Recovery team assignments who is responsible for carrying out the IT disaster recovery plan, and who are their backups if they are unavailable? How will they be notified when a disaster occurs? Where will they work, how will they communicate, etc.?
  • IT system recovery procedures. These are your emergency response steps, including what systems will be recovered first and in what order.
  • Incident response procedures to contain the damage from ransomware and other malware (e.g., isolating infected systems).
  • Data backup/recovery procedures. Exactly how and where is each key data resource backed up, and what are the corresponding recovery steps?
  • IT asset inventory a detailed list of hardware and software/application assets, including their criticality rating, where they reside (on-premises, cloud-based), and whether they are owned, leased, purchased as-a-service, etc. You can’t recover what you don’t know exists.
  • Testing procedures. Regular testing and updating of your IT disaster recovery plan is key to efficient, successful recovery. This includes tabletop exercises and read-throughs of the plan, not just full-on simulations. A best practice is to review your IT disaster recovery plan quarterly or twice annually to keep it current with your ever-changing IT environment, staffing, and business goals.
  • Disaster recovery sites. If your IT disaster recovery plan includes failing over to a remote hot site, or recovering from a mobile site, you should include those details in a separate section of your plan. For example: What replicas and backups are you maintaining via the hot site? What software, services, vendors, etc. are involved to maintain and operate the hot site setup?

How do you construct an IT disaster recovery plan?

Building an IT disaster recovery plan takes careful research and discussion among all stakeholders. You should holistically understand your business needs, as well as your risk profile.

Therefore, conducting a risk assessment to identify top threats your organization faces, including specific threats to critical assets like your intellectual property, is a key initial step. You must also interview people who work with essential systems to understand what those systems do and what inputs and connections they depend on.

As you develop a holistic, prioritized understanding of IT operations, you can connect with technical and business leaders to discuss the impacts of interruptions to various critical systems. This input serves as the basis for key recovery metrics like your RTO and RPO.

Finally, based on your analysis of assets, risks to those assets, and your recovery objectives, you can plan a disaster recovery configuration. For example, do you need a cloud-based/hosted hot failover site? What backup and replication scenarios are most critical (e.g., the backup plan for your cloud-based ERP solution)? What software, services, vendors, etc. are needed to help you create the overall setup you need?

A best practice is to submits several options and price tags to management, to strike the optimal balance between recovery cost and disaster risk. Once management approves a plan, it’s time to communicate the plan around your organization and initiate training as needed.

The Database Component of IT Disaster Recovery Planning

Among the most important assets that your DR plan will protect are your databases and these require special consideration in your disaster recovery planning and testing. Databases may have their own D/R configuration such as hot or cold Standby databases using Oracle dataguard or SQL Server log shipping, or standby databases managed by DBVisit using either of those databases.  In addition to testing switchover/failover to standby databases, proper database backup monitoring, protection,  and testing must be part of your DR plan. A disaster recovery plan will fail if the backups that are part of the plan are compromised or not complete when the time comes to recover to them.

Next steps of IT Disaster Recovery Planning

Many companies cannot afford to face significant unplanned downtime and strive for continuous availability of critical systems like their website or ERP environment—including associated databases.

Buda Consulting understands how companies rely on databases and the importance of high availability to support quick database recovery and minimize the impacts of outages, interruptions, cyberattacks, natural disasters, etc.

Our Reliability Review service will help you evaluate your current risk scenario and help you determine the level of protection your business needs. Contact us to schedule a time to discuss your business needs and goals.

 

Why Disaster Recovery Testing is Mission Critical

Why Disaster Recovery Testing is Mission Critical

With cybercrime still on the rise, and remote work scenarios stressing IT infrastructures and security controls, every organization needs a disaster recovery (DR) plan to protect against data loss and quickly restore IT infrastructure and systems following a significant outage.

But planning for disaster recovery is only the first step. You might think your plan is solid, but you need to test it regularly and keep it updated as your environment constantly changes. Otherwise, you will uncover its shortcomings at the worst possible time—in the midst of a disaster.

Yet according to a recent survey, only about half of SMBs have a documented, company-wide DR plan in place. Of that subset, 50% test their DR plan annually or even less frequently, while 7% have never performed any disaster recovery testing.

Shockingly, not a single survey respondent said their last DR test was even moderately successful—every company in the survey that conducted testing reported experiencing significant issues impacting the network, service availability and performance, data integrity, and/or critical workloads. But at least these firms know what they need to fix.

Business risks from inadequate disaster recovery testing

Insurance can blunt the financial impacts of a disaster, but lost data may be irreplaceable. Unless you have a DR plan and test it regularly, chances are almost 80% that your business will experience significant downtime, data loss, and other negative impacts within a few years.

Here are 5 of the most significant impacts of not conducting disaster recovery testing:

  1. Downtime cost. About 80% of the time, significant unplanned downtime and data loss is caused by IT hardware or software failures. The cost of an hour of downtime for most SMBs is on the order of $20,000 to $40,000. But depending on the nature of your business it can be much more.
  2. Lost customers. Your customers and business partners have high expectations regarding your services. Ideally, you want to recover before they notice you were down. The longer it takes you to recover and the more problems you have, the more customers you’re likely to displease or lose outright. Further, your downtime may have caused your clients and partners that depend on your services to suffer losses as well.
  3. Reputational damage. Chances are you’ve worked long and hard to build a reputation as a reliable partner. But you can lose that in minutes, and the cost while hard to quantify will be enormous. Your failure to invest in protecting your business is not something that will impress customers or prospects. Without disaster recovery testing your priceless business reputation is not safe.
  4. Cybersecurity risk. When an organization is trying to recover from a disaster, some of its cybersecurity controls may be rendered ineffective, increasing the risk of an attack. Conversely, conducting disaster recovery testing helps you identify and remediate critical vulnerabilities before hackers have a chance to exploit them.
  5. Compliance risk. Depending on your industry (e.g., financial markets, government agencies, healthcare firms) and applicable regulations, your company’s ability to maintain business continuity could be a compliance requirement. For organizations like these, regular disaster recovery testing could help fend off fines and sanctions for noncompliance.

In short, unless you can afford to lose revenue, customers, and your good name in the market, disaster recovery testing is mission-critical.

What disaster recovery testing looks like

The purpose of disaster recovery testing is to gauge the effectiveness of your DR plan and determine whether you can restore operations within the planned timeframe (your Recovery Time Objective or RTO). Disaster recovery testing will also reveal faults in your IT and/or database environment that you need to fix.

Of course, disaster recovery testing also tests and trains your key employees who have responsibilities for restoring your business. The more they can practice the better they will perform when a real disaster is declared.

Disaster recovery testing doesn’t have to be a full-on simulation scenario where systems go down. You can learn a lot by reviewing your DR plan in a tabletop exercise. Think of it as a dress rehearsal, a step-by-step walk-through of the plan. It’s a great way to spot problems, especially missing pieces and errors.

How often should you perform disaster recovery testing? At least once every six months, given the pace of change in the average IT environment and the importance of practice for human performance.

Next steps

In today’s business environments, continuous availability is the target as downtime for mission-critical applications—like your databases—is considered unacceptable. Getting to “zero downtime” for your database environment, even in the face of outages and interruptions, usually requires special expertise and services to maximize the benefits of the high availability and disaster recovery capabilities your Oracle, Microsoft or other RDBMS offers.

Contact Buda Consulting to discuss a Reliability Review, our proven and tested approach that will evaluate your current risk profile and help determine the level of protection your database environment requires.

How Much Does Database Disaster Recovery Cost? “It Depends”

How Much Does Database Disaster Recovery Cost? “It Depends”

How Much Does Database Disaster Recovery Cost? “It Depends” – a sometimes frustrating response that we hear frequently when we ask a question.  To some, it feels like a dodge. Maybe the person we are asking does not know, or would rather not give their opinion, or would rather not share their knowledge.

But when I hear someone respond “It Depends”, I tend to think that they are seriously considering the question. I hope that the answer will be a thoughtful, considered response.  In fact, few questions really deserve an automatic response. Most issues are nuanced, and when someone says “It Depends”, it does not mean that they are dodging the question.

A common question that we are asked by new clients is how much will it cost to implement Disaster Recovery (D/R) for their database environments,  My answer always starts the same:  “It Depends”

Database Disaster Recovery vs High Availability

Disaster Recovery is sometimes considered distinct from High Availability. For the purposes of this article, I think of them as two parts of the same whole. The objective of both is to keep your database available to your users when they need it. And when designing a solution that meets those objectives, both types of tools may be implemented. 

I think of Disaster Recovery in terms of things like backup and recovery tools and passive standby databases. The idea is to have a straightforward way of recovering and resuming operations if the primary server fails.  And I think of High Availability in terms of things like clustering, geographically distributed availability groups, and active-standby databases. The idea here is to prevent the system from ever failing in the first place.

When it comes to keeping the database available as needed, all of these tools need to be considered.

The Cost of Downtime

There are many factors to consider when thinking about Disaster Recovery.  Perhaps the most important, and I think the first that should be asked, is what is the cost of downtime?   Determining the cost of downtime to our own organizations requires asking what would happen if we were down for 1 minute, 1 hour, 1 day, or other appropriate intervals. We must consider all departments and stakeholders.  For example, in a manufacturing operation (this list of considerations is not exhaustive):

  • How many orders are typically placed in one minute, hour, day? What is the dollar value of those orders? What percentage will likely be lost forever vs delayed?
  • How many items are received during those intervals, what is the downstream impact on production if items cannot be received into the system?
  • How many items are produced during those intervals, what is the downstream financial impact if they are not produced and shipped?
  • How many orders are labeled during those intervals, how many shipped? What is the downstream impact of delays on labeling or shipping?
  • What are the upstream production impacts of not being able to produce, label, ship, or record order information (inventory space, etc)
  • What is the liability cost of not getting products or services to vendors or end customers within contractual guidelines?

These are not simple questions to answer, but the true cost of downtime can only be determined by such an exercise. 

What is Acceptable Database Disaster Recovery?

Once we know the cost of downtime, we can determine what level of disaster recovery is required in order to prevent unacceptable costs to the organization, which, of course, is the main reason to have a disaster recovery plan in the first place.  At the end of the day, the question is how much data loss or downtime is acceptable.

Of course, we would always like to say zero. Zero downtime, zero data loss, no matter what. However, implementing true zero loss Disaster Recovery may be cost-prohibitive for your organization. And moving from a zero-loss posture to a very small loss posture can reduce implementation costs vary significantly. So it makes sense to determine what the costs are and therefore what is acceptable to the organization.

Once we know the cost for an interval of downtime, we can do a cost/benefit analysis regarding the cost of implementing D/R. 

Factors That Drive The Cost of Implementation

The implementation cost of Database Disaster Recovery varies mainly on two key factors. 

  • The amount of data loss that is acceptable (known as recovery point objective or RPO)
  • The amount of downtime that is acceptable (known as recovery time objective or RTO)

For both of these factors, the lower the acceptable loss, the higher the cost, with the cost and complexity of driving down downtime generally greater than that of driving down the amount of data loss.

Implementing a Disaster Recovery scenario with zero possibility of data loss and zero downtime can be very expensive. This approach essentially requires full live redundancy across multiple geographic regions and the complexity that goes along with ensuring a seamless automatic transition of all applications from one environment to another and real-time synchronization between them.  

For many organizations, this full redundancy approach will be cost-prohibitive. And for most organizations, the cost of a small amount of downtime and a small possibility of a very small amount of data loss is acceptable and will not cause significant damage to the operation (or to profit). This compromise can mean the difference between being able to afford a Disaster Recovery Solution and not being able to do so. Having any Disaster Recovery Solution, even one without all zeroes is much better than having none.

The Bottom Line

When someone asks me how much it will cost to implement a Disaster Recovery Solution, I always say “It Depends”.  And then I ask a lot of questions. Contact us today for a consultation.

The Elements Of A Good Disaster Recovery Plan

The Elements Of A Good Disaster Recovery Plan

What is a Disaster Recovery Plan

The elements of a disaster recovery plan (also called a Business Continuity Plan) is a document that describes how an organization will survive a disaster. These can be natural disasters like hurricanes, fires, terrorist attacks, or any event that may prevent the business from operating. A good disaster recovery plan includes everything from how to replace lost personnel to how to relocate everything in the event that an entire building is lost. The plan includes human loss, product loss, customer loss, technology hardware loss and data loss.  This article will discuss only hardware loss and data loss, but it is important to think of the disaster recovery plan in the larger context of an overall disaster recovery plan. 

Why is a good disaster recovery plan important

When disaster strikes, time is critical, resources are stretched, and capabilities are limited.  Planning ahead for a disaster ensures minimum disruption by identifying everything that might be needed beforehand and ensuring that there is redundancy in each element. For example, a good disaster recovery plan will identify individuals responsible for restoring a database, and a backup to that individual in case the primary individual is lost. The backup individuals can then be trained properly to take action when it becomes necessary.  Once the crisis starts, it is too late to take these steps. 

Elements of a Disaster Recovery Plan

A Disaster Recovery plan includes many elements that help us be prepared in a crisis. The purpose of identifying all of these up front is to ensure that we have primary and backup human resources trained for each task that will be necessary to be performed in a crisis, and that that we have reliable backups in place of all physical and technical resources (applications, databases, servers, networks, buildings, vehicles, machinery) that will be required in order to stay in business or get back in business after a disaster. Some of the more critical elements of the plan follow. Since this is a database blog, the remainder of this article will be focused on applications and databases.

Scenarios

We want to enumerate as many possible disaster scenarios as we can in order to ensure a robust plan. As we describe each scenario in detail, we will find blind spots that we have and we will address them. The scenarios must describe what may happen, what that will look like, exactly what steps we will need take to get back in business, and exactly who will do them. Examples of technology related disasters:

  • Main data center is hit by extended power outage due to flooding damage to regional power grid
  • Infrastructure is hit with ransomware attack
  • Hurricane cuts connectivity to main data center
  • Human error causes loss of a large data table for mission critical applications.
  • Storage system firmware update causes corruption in production database

Inventory of applications (including dependencies on databases) 

Include nameless applications (reporting or analytical tools used against a data mart or data warehouse). Collecting this information on each application will help us know exactly who to call when disaster strikes, saving valuable time. Ensure that every known database is referenced here.

  • Application Owner
  • Recovery Time Objective
  • Recovery Point Objective
  • Responsible IT persons (primary and backup)
    • Application
    • Network
    • Cloud Infrastructure
    • Storage
    • Server
    • Database
    • Backup Maintenance

Test the Elements of a Disaster Recovery Plan

    • Test Procedures for each application in inventory
      • Identify systems to be used for test restore if applicable
        • Responsible party to provision these systems
      • Example Pre testing steps
        • Determine which applications/databases are in scope of this test
        • Gather data points to validate. This typically involves finding an example of both recently entered or modified data, and old data, to ensure that a full range of timeframes is represented and continues to be available after the recovery.
      • Example steps for conducting the test   — some or all of these may be applicable
        • Failover to backup database
        • Restore backup database
        • Point application to test database 
      • Example Post testing steps — some or all of these may be applicable
        • Validate the data points
        • Switch back to primary
        • Repoint the applications to primary database
  • Update the Disaster Recovery plan to reflect any lessons learned, staff changes, new, changed, or decommissioned databases, applications, or hardware.
    • Testing Schedule
      • When will tests be conducted?
        • Frequency — recommend minimum of twice per year.
        • What point in the quarter, month, week,
        • Time Of Day
  • Test Cases
    • Screens/reports to review
    • Data points to validate 
  • Responsible parties
    • Who will be responsible for conducting the test?
    • Who will be responsible for validating the results?

Living Document

As with many documents critical to our businesses, this must be a living document. This document contains names and contact information for key personnel that must be called in a time of crisis. It is critical that this document be updated regularly so changes in staff and responsibilities are reflected.  New applications and databases are added regularly as well, these must also be kept current.  Best practice is to update this document each time the tests are conducted.

Database Disaster recovery tools

One key aspect of the recovery plan from a database perspective will be the designation of a tool or tools to create standby databases that can be used in the event of a failure of the primary database. Most database tool vendors provide tools to do this. We will discuss the tools provided in Oracle for this purpose as well as a third party tool (Dbvisit). Future articles will describe DR options for SQL Server and other database.

Oracle Data Guard

Oracle provides a tool called Oracle Data Guard that can be used to configure and manage standby databases. Oracle Data Guard provides the capability to create and manage local or remote standby databases, and manage the transition from primary to standby and back. and it can create logical or physical standbys. At the center of Oracle Data Guard is a set of command line utilities entered at the Oracle console (SQL Prompt).  Oracle’s enterprise manager tool (Cloud Control) provides a graphical interface on top of dataguard and simplifies the use of the tool.  

Oracle Data Guard comes included as part of Oracle Enterprise Edition. A more powerful tool enabling greater use of standby databases is also available for enterprise edition called Active Standby. Unlike basic Oracle Data Guard, Active Data Guard has additional license fees.

DBVisit

Both of the Oracle Data Guard tools previously mentioned require Oracle Enterprise Edition.  There is no DR solution available from Oracle for Standard Edition. Fortunately, DBVisit offers a solution. Dbvisit provides the functionality to create and manage standby databases for Oracle Standard Edition. The tool offers a graphical user interface that makes creating and managing a DR solution for Oracle Standard Edition simple. And the licencing is much lower than the cost to upgrade to Oracle Enterprise Edition. If the only reason for needing Oracle Enterprise Edition are the DR capabilities of Oracle Data Guard, DBVisit is a good option. 

These are the Elements Of A Disaster Recovery Plan

In summary, a good DR plan should include everything about what an organization must do to recover from an emergency. This includes the who, what, when, where and how for the entire process from the moment that an emergency occurs to when the organization is fully recovered. 

If you would like to discuss creating and implementing a Disaster Recovery Plan, especially the Database Related components of your plan, give us a call and we can talk about the best approach.

Also, please leave comment with thoughts that you have about disaster recovery planning.  Let me know if you include things I didn’t mention. Or share stories about how a plan helped in a disaster, or how the absence of a plan hurt 🙁

And if you like this article, please share it with your colleagues and subscribe to our blog.