General discussion

  • Creator
  • #2291925

    Incorporate “problem” applications in your DR plan


    by debate ·

    When creating its disaster recovery plan, has your company encountered systems that seem “unprotectable”? How did you work around this issue? Share your comments about dealing with applications that don’t easily fit into a DR plan, as discussed in the Nov. 2 Disaster Recovery newsletter.

    If you haven’t subscribed to our free Disaster Recovery newsletter, sign up today! Click this link to subscribe automatically:

All Comments

  • Author
    • #3296658

      OK for mini-event, but . . .

      by jglenncrp ·

      In reply to Incorporate “problem” applications in your DR plan

      Mike Talon’s advice (follows) is OK for a mini-event, but for an event of any magnitude, it will be a disaster within a disaster.
      Mike wrote:
      “So what can you do in these situations? Your best bet is to create backup hardware in your DR data center and configure it as closely as you can to the solution in the primary data center. Make sure you keep copies of the installation media for your applications in the DR data center, preferably in some form of fire-proof media safe.

      “In the same safe, you should also keep copies of the tapes that correspond to your recovery point objective. For example, if you can only afford to lose 24 hours of data, you need to keep a copy of last night’s tape in the safe–not an easy feat but definitely possible.”

      If the data center is destroyed, the “backup hardware in your DR data center” also is gone. Likewise, the “copy of last night’s tape in the safe” is gone or inaccessible.

      As with most IT-centric plans, the planner fails to see all of the service interruption possibilities. Flooding is the most common risk (even if caused by sprinklers triggered by a fire).

      If IT is that critical – and it some cases it IS “that critical,” arrange for an alternate site as a backup facility. This can be anyplace with sufficient capacity to keep the business-critical processes functioning. A development center with a little extra capacity (development priority is zero following a disaster event), another data center within the organization, even a neighbor’s data center in a non-competing business. Of course there always are commercial sites.

      John Glenn, MBCI, CRP
      Certified Business Continuity Planner

      • #3296636

        How about an exact hardware/software backup

        by lordgoofus ·

        In reply to OK for mini-event, but . . .

        Granted in big servers price would become a major restrictive factor, would not a backup server, normally disconnected from the network and stored in a seperate location be a viable solution? (I am assuming a ghost image it taken of the production server at least once a month).

        By using the exact same hardware, a ghost image would very easily be transferred across to the emergency server, then it’s just a case of hooking it up to your network and away you go?

    • #3296611

      Techrepublic Sucks

      by support ·

      In reply to Incorporate “problem” applications in your DR plan

      Techrepublic Sucks

    • #3294998

      Unable to use same IP and two sites

      by ehoffman ·

      In reply to Incorporate “problem” applications in your DR plan

      The body of the article inlcuded this statement.

      Other times, networking itself causes problems for system protection, a type of problem I’ve addressed in previous columns. For example, if an application only works when using a specific IP address, and you can’t make that IP address appear at another data center, you’re stuck with only one system that can run the software.

      This not longer true. Raptor Networks Technology has a system that allows redundant connections over distances up to 10Km where a system can have connections in multiple data centers yet keep the same IP and MAC address using IEEE802.3ad over special Raptor Adaptive Switch Technology 10Gb links.
      see for details.

Viewing 2 reply threads