{"id":490634,"date":"2010-03-30T16:19:00","date_gmt":"2010-03-30T20:19:00","guid":{"rendered":"tag:blogger.com,1999:blog-7196788127833928948.post-8179224524247156699"},"modified":"2010-03-30T16:19:00","modified_gmt":"2010-03-30T20:19:00","slug":"mitigating-risks-of-the-it-disaster-recovery-test","status":"publish","type":"post","link":"https:\/\/mereja.media\/index\/490634","title":{"rendered":"Mitigating Risks of the IT Disaster Recovery Test"},"content":{"rendered":"

The IT Disaster Recovery Test as part of the Business Continuity testing is becoming an annual event for most IT departments. It is mandated by a lot of regulators, nearly insisted upon by internal audit and ofcourse a very healthy thing to do.<\/p>\n

But performing the IT DRP test without proper risk management can put your organization at significant risk.<\/p>\n

\"\"<\/a>
To put things into perspective, let’s analyze the steps, risks and countermeasures of an IT Disaster Recovery test:

<\/p>\n\n\n\n\n\n\n\n
DRP Test Step<\/td>\nActivity<\/td>\nRisks<\/td>\nCountermeasures<\/td>\n<\/tr>\n
1. Failure of primary systems<\/td>\nIn order to perform a disaster situation, the Primary systems need to be caused to fail on some level<\/td>\n\n
    \n
  1. Databases not closed properly\/damaged due to forced shutdown or forced power failure<\/li>\n
  2. Hardware components failing due to forced shutdown or power failure<\/li>\n
  3. Spilt-brain cluster due to uncontrolled sequence of failures of servers and storage<\/li>\n<\/ol>\n<\/td>\n
\n
    \n
  1. Full backup prior to the initiation of the DRP test<\/li>\n
  2. Backup components and Vendor presence at ready during the entire test.<\/li>\n
  3. Not performing a direct forced shutdown but forcing a network level isolation at the routers<\/li>\n<\/ol>\n<\/td>\n<\/tr>\n
2. Activation of Disaster Recovery systems<\/td>\nSevering any relation between the DR and the primary systems and running the DR systems as temporary primary<\/td>\n\n
    \n
  1. Actual failure of primary system during the test<\/li>\n
  2. Failure of the primary system while the DR system is concluded to be non-functional<\/li>\n<\/ol>\n<\/td>\n
\n
    \n
  1. Full awareness of the test of every interested party – business custodians, directors of divisions and top management to initiate the real Business Continuity Plan<\/li>\n
  2. Full backup prior to the initiation of the DRP test at DRP site, and full vendor support.<\/li>\n<\/ol>\n<\/td>\n<\/tr>\n
3. Reconfiguring the user environment<\/td>\nIntervening in the end-user environment in a way that will make them use the DR system<\/td>\n\n
    \n
  1. Error in reconfiguration which may cause the end-user to input test data into the primary systems<\/li>\n
  2. Error in reconfiguration which may cause the primary system to stop functioning.<\/li>\n<\/ol>\n<\/td>\n
\n
    \n
  1. , 2. Scripted and documented steps of reconfiguration. All steps should be performed by 2 persons – one observing the others actions<\/li>\n<\/ol>\n<\/td>\n<\/tr>\n
4. Reverting to the primary systems<\/td>\nResuming the primary systems at some level and reestablishing the relation between the DR and the primary systems<\/td>\n\n
    \n
  1. Error in reconfiguration which may cause the primary system to stop functioning.<\/li>\n
  2. Copying of test data that was input into the DR test system back into the primary location3. Failure of primary systems during resumption<\/li>\n<\/ol>\n<\/td>\n
\n
    \n
  1. Scripted and documented steps of reconfiguration. All steps should be performed by 2 persons – one observing the others actions.<\/li>\n
  2. Fully controlled and documented process of resumption, which guarantees that only the primary system is data master.<\/li>\n
  3. Full backup prior to the initiation of the DRP test, Backup components and Vendor presence at ready during the entire test.<\/li>\n<\/ol>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

    <\/center><\/p>\n

    With all these risks, is it more prudent to never perform an IT DRP test? – Absolutely NOT, and here is why:<\/span><\/p>\n