It’s every IT manager’s worst nightmare.
An extreme power spike hits the network sewer and the hard drive is fried. Or computer equipment, including hard drive, is destroyed in a flood, fire or earthquake. Valuable, irreplaceable data - customer contact information, sales reports, accounts receivables - is lost. The company grinds to a standstill as employees wait for IT staff to work a miracle. Only too soon IT discovers it is easier to feed the multitudes using a few loaves and fish than it is to recover data destroyed in a disaster. Data disasters can take many forms: operator error, vandalism by employees or mischievous hackers, malfunctioning hardware, operating systems or applications, power surges or blackouts, fire or other natural disasters. To minimize the risk of data loss, companies need to eliminate the risk of physical and cyber disasters. For instance, placing a network server in the coffee room near the sink might free up office space, but it can lead to disaster if the sink overflows. Connecting a network to the Internet without firewall or other protection is just inviting an invasion. The largest contributing factor to data loss is hardware or system malfunction, followed by human error, according to CDL Data Recovery Technologies Inc. (www.cbltech.com). A Markham, Ontario darn recovery company, CDL can recover lost data on most storage devices up to 75 percent of the lime, But frequently, data loss is terminal, especially when panicking employees try to recover data themselves, further exacerbating the data loss problem. But wait, you say. There is no problem here. We back up all our data. Simply backing up data may not solve the data loss problem. The reason? Many companies never verify backups and only discover they have backup tapes full of corrupted files when they are trying to recover from a disaster Testing backups regularly to make sure they are in working .order is a good idea; but it does not help a company recover data if backups are destroyed or stolen. That’s why backups should be stored in a secure setting like a fireproof safe, preferably off-site. Of course this is exactly what would happen if the company had disaster recovery plan (DRP) in place. A DRP is a formal document that spells out the steps a company will take to minimize disaster and the steps the company will take to recover data, applications end hardware if disaster strikes.
For a small business, the DRP can be as simple as “get last night’s back up from the safety deposit vault and use the company credit card to buy a new computer. But that won’t cut it for large enterprises. They need a DRP based on business processes and priorities that spells out the disaster recovery process in detail. Since not all data, hardware and applications have to be recovered for a business to continue, the company should establish DRP priorities by taking stock of data, applications and hardware to determine what data should be backed up (and how often), what applications and hardware are replacement priorities and how they will be replaced. Crucial data files tend to include revenue generation data: accounts receivable and other financial information, client contact data, sales orders, and any digital products the company sells. It should also include staff contact information, hardware, hardware specifications and configurations, components, peripherals, software and software registration numbers and software and hardware vendor and other third-patty contact information, such as accounting or payroll and communication (telecom provider, Internet Service Provider) services. Such a DRP can be a massive document covering data, applications and hardware in many departments in multiple locations. Without it, a company can literally go under if disaster strikes. The DRP should be field tested to ensure it is fully operational, and it should be revised as a company grows. Those responsible for implementing the DPI’ should know what roles they have to play and the time- lines within which they have to play their part. After all, the last thing you want to do when restoring back ups is discover the back ups are faulty and the last thing you want to do when implementing a DRP is discover that the DRP itself is a disaster.