My father once told me a story about an out of work actor. He got a one line role in a Broadway performance. He had to say “Hark, I hear the cannons roar”. He dutifully practiced his lines every day for hours until the scheduled performance. Finally, at the opening night, it’s time for him to go on stage and recite his line. He practices it once more. He goes on stage and hears a loud boom. Instead of saying his line, he says, “What the hell was that!”. Recovery from a disaster can be like that if you are not prepared. Here are some steps to mitigate the “What the hell was that” factor when disaster strikes.
• Take a quick inventory of all your IT related business processes.
This includes everything from financial applications, logistical functions, email, outward facing functions and more. Remember the regulatory /compliance environment you are in (HIPAA, PCI or Sarbanes)
• Rank them for recovery priority.
Think about which applications are necessary for your company to generate revenue or are critical to business continuity?
What data can’t your customers do without? What’s critical to running your internal accounting and finances? And what is required for compliance? Now, create a list in descending order to establish your DR recovery sequence. This is the dress rehearsal for your performance. It makes the “what the hell was that” factor diminish significantly.
• Establish a Recovery Time Objective (RTO) for each function.
Ask yourself, “How fast do I need to recover this application?” Email and transaction based applications that people inside and outside the company depend on at all times will probably be near the top of this list, whereas applications that are less frequently accessed, such as a human resources applications, may be low on the list because they’re ancillary to your immediate business continuity requirements. Be realistic in your estimate of the recovery time objective.
• Establish a Recovery Point Objective (RPO)
How much data can you afford to lose for business process? How important is the data that you could lose? Applications related directly to business continuity, where data changes significantly every day, will top this list. Back office processes may be lower on the list. Is it a day’s worth of data? Is it an hour’s worth of data?
• Create a “Break Glass in Case of Emergency” plan. Define where you want to keep your DR data and systems.
If you are located in an area that could be hit is regional weather events like hurricanes, floods, or wild fires, then select a secondary location outside of your region that you can fail over to when disaster strike at your primary location. Your choice could include cloud-based recovery.
• Determine which of your RTOs and RPOs can be supported by your existing backup and recovery scheme.
This will allow you to figure out pretty quickly which of your processes are going to “fall through the cracks.” Certain applications, like very heavily used SQL or Exchange applications may need to be backed up even more frequently, and if your current backup scheme can’t support anything more frequent than once daily backup, you may wish to consider investing in a newer, more aggressive disaster recovery solution.
• Consider your DR options.
If your current system is not up for the job, select a Disaster recovery solution that best meets the business and recovery objectives you have developed in the previous steps of this plan (see below in the next section for more information). Once it’s installed and in production, make sure your staff is trained how to use it.
• Assign responsibilities so everyone knows what to do when a disaster strikes.
Assign everybody involved in the DR plan a specific task. Don’t expect the relevant personnel to always be at the disaster site or to be in control immediately. Implement necessary duplication and redundancy for people, just like you would do with computers.
• Test, test, test!
One of the worst feelings an IT administrator can have is discovering a backup is corrupted in a disaster recovery scenario. Why wait to find out when it’s too late to do anything about it? Test your backup data for corruption when you back it up. Newly developed software allows you to test for recoverability automatically. Use these available tools.
• Practice, practice, practice!
The more experience your team has successfully carrying out a simulated disaster recovery, the more comfortable and quick they will be to succeed when the real thing happens.
Source by Vic Levinson