Most of us understand that backing up data is a necessary part of our work world since almost all of us store critical information on the company’s file server. A backup system is very much like a smoke alarm. We know we should have one but we hope we never have to us it. Data loss can happen for any number of reasons. New viruses are written every day to threaten the safety or our data. A fire or flood could wipe out our servers in a few hours. Servers and computer equipment can get stolen and when that happens, the data walks out the door with the hardware. Much more innocent errors can also threaten data – EG an employee accidentally overwriting data. In recent years, losing valuable data as a result of hardware failure has become much less frequent, but that still happens.
Most of us can say we have a backup system, but how many of us test the backup regularly to ensure that is it actually doing what we think it’s doing? How many of us know, with certainty, that we can recover data from our backup if disaster strikes?
There is a major difference between having a backup and having a complete disaster recovery plan. Now, I’m not suggesting you set the house on fire to test the smoke alarm. However, there needs to be a plan in place with the steps to recover your information, regardless of the severity of the situation. This disaster recovery plan needs to be documented and tested on a regular basis to ensure the information being backed up can actually be used to restore your computer system in the event of a disaster.
We recently had a situation where a client was infected with a ransomware virus. The infection spread from a workstation to the server that housed their accounting information. That server also contained the user files (Excel, Word, PDF documents etc.). This type of virus locks up the files and the criminals who created the virus demand payment (ransom) in exchange for a key to unlock the files. The amazing fact about ransomware viruses is that you have no real assurance that the key you just paid for will actually work. You are now dealing with criminals so all bets are off.
The entire server was essentially crippled, and the data was being held hostage. So the company said, “Wow, it’s a good thing we have a backup, we just need to do a restore from yesterday, right?” Well, not so fast.
The backup device was strategically placed in a vault at the opposite end of the building. The thought was that a second copy of their data in a secure location would offer protection in a number of disaster scenarios. The one flaw was the backup device was permanently connected to the network. So the virus was able to jump to the backup device and lock all the backup files as well. The server and the backup device were both fine physically, but they both contained information that was locked up and of no use for recovery.
The lesson here is the importance of an offsite copy of your information. The local backup is a necessity, but the additional offsite copy can be a lifesaver. Secondly, any backup strategy is incomplete until it is tested and updated on a regular basis. As hardware is refreshed and applications are upgraded, your disaster recovery plan needs to stay on pace with these changes. In addition to the recovery steps, the plan should include everything from website login credentials for downloading software, to licensing information, to contact names and phone numbers for support.
The recovery test can begin with a simple restore of a single file from backup, all the way to a full server recovery. The entire process may be time-consuming, but will pay off if and when disaster strikes….and it will.
