Courting disaster?
1. Doing a cut and paste job on a downloadable template. Far too many IT teams, when tasked with designing a DR strategy, simply download a basic template from the Internet and fill in the gaps. The resulting, short document is woefully inadequate and fails to address any of the business-specific issues that determine ongoing success in the event of a disaster. The answer: A DR strategy needs to reflect the impact of system failure on key operational performance. It needs to encompass not only buildings, staff and data backups, but also communications – both telephone and Internet service provider – as well as access to new versions of critical application software. Doing a cut and paste job on a downloadable template is not a DR strategy. 2. The board pays lip service to the need for disaster recovery but completely refuses to allow comprehensive testing that requires all staff to work from home for a day. Fears of lost productivity and business disruption are the regular reasons cited by senior management for not undertaking a full disaster recovery test. IT teams are encouraged to focus on basic operational tasks such as restoring servers instead. But without a real-life simulation of disaster there is no way of predicting just where the DR plan may fall down. Indeed, according to a recent study by Gartner (The Broken State of Backup), only 28 percent of all disaster recovery tests were fully successful. In detail, 11 percent of businesses that performed a recovery test admitted that the exercise was cancelled because problems could not be resolved; 50 percent said that recovery exercises encountered problems and 11 percent were not sure how the exercise went. The answer: It is essential to perform regular disaster recovery tests to ensure that every single server can be recovered within the recovery time objective. Send the MD and/or FD on a disaster recovery awareness workshop for a day to provide some real insight into the likelihood of business success post emergency event. And then put in place regular disaster recovery tests that include all staff working from home and relocating back-office services to a stand-by site. It is this level of rigour that is required to truly assess the viability of the DR strategy. 3. There is only one copy of the disaster recovery plan – and it resides on a system within the organization. It is a simple but obvious mistake – the building is on fire and the only copy of the disaster recovery plan just went up in smoke, leaving the organization completely bereft of key contact details and any plans for operational procedure in an emergency. The answer: Ensure multiple copies of the plan are stored securely off-site. Copies should be made available – under non-disclosure – to trusted suppliers, and also stored securely by a number of directors to ensure as many senior staff as possible have immediate insight in the event of a problem occurring. 4. The back-up data is never tested. Too many organizations assume that regular back-up processes are a core component of any disaster recovery strategy. Yet when organizations do test the quality of the back-up, many discover that entirely the wrong data has been backed up – a factor that contributes to the disaster recovery test failures outlined above. Furthermore, organizations are also failing to assess just how long it will take to restore data in the event of a disaster: if it takes an entire weekend to back-up the server, the business is looking at a minimum two day delay to restore that system, which is unacceptable for a business critical system. The answer: Test the quality of the back-up process regularly. Check that both data and servers can be restored within a reasonable timeframe and, if not, look at alternative, mirrored solutions that provide faster restore. 5. The software vendor will provide duplicate application software on demand. Of course, the company will no doubt provide that software – in time. It may also provide the necessary expertise required to configure the software and restore the database. But just how long will that take? The answer: Firstly, ensure that data back-ups are regularly tested and working correctly to minimise the need for external expertise. Secondly, put in place strong logistical processes for securing new versions of software. 6. The organization plans to rely on mobiles (cells) for communication in the event of an emergency. This may work for a couple of hours, but if the business suffers any major event, especially one that affects a large number of people and companies, a mobile is not a robust, reliable option. The mobile network will, as has been seen in major events, suffer significant performance problems. Furthermore, most organizations rely on sophisticated telephone systems, especially in areas such as customer services. The answer: Put in place a robust telephony contingency solution to ensure calls can be rerouted and diverted to temporary office facilities as well as employee’s home premises. 7. It’s all in the cloud, so there is no need for disaster recovery. As growing numbers of organizations move back-office applications into the cloud, there is a strong argument that DR planning becomes simpler as the business is far more portable. But if staff are accessing these applications from an Internet connection at home, organizations face a major security risk since around 90 percent of home computers are incorrectly configured. Furthermore, organizations need to consider ISP agreements to ensure email and cloud-based applications can be immediately accessed from any stand-by site. The answer: Ensure that the ISP agreements extend to any temporary office facilities to minimise interruption. Consider the viability of allocating laptops to all staff to mitigate the risk of exposing corporate systems to the security vulnerabilities associated with home computers. Author: Tony Brown is technical director of PhillipsTaylorBrown. http://www.phillipstaylorbrown.com/ Make a comment / add to this list
•Date: 22nd Sept 2009• Region: UK/World •Type: Article •Topic: IT continuity |
