Disaster Recovery
We are still finding many companies with no Disaster Recovery (DR) plan in place.
Historically a large proportion of these businesses fail in the event of a disaster. So why do companies continue to play Russian Roulette with little or no DR plan in place?
Is such a plan just too complex or expensive? We think often times it is simply a lack of awareness of the risks. A DR plan for your IT systems including valuable data may not be that difficult to implement but the consequences of not doing anything could mean the end of your business as you know it.
Several factors can contribute to loss or corruption of data, not just natural or man-made disasters, as listed here:
- Hardware Failure
- Loss of power
- Software issue
- Security breaches
- Accidental user error
What does this mean to you personally or your business and what can you do to reduce your risk?
Running old or outdated technology is the biggest risk.
- Take time to make a list of hardware, operating systems, applications and devices (such as printers, routers, etc).
- Keep a copy of software licenses, passwords and related documentation in an alternative but safe location which is accessible should the need arise.
- Make regular copies or implement a versioned backup process to ensure your valuable data is safe and can be restored following human error, malware/ransomware events or other events outside of your control such as fire or earthquake which leave your building inaccessible.
A magnitude 7.8 earthquake hit the Kaikora region of New Zealand in November 2016. A Hospital file server containing medical records located in a building in Wellington, 150km from the epicentre was severely impacted by the earthquake.
There was no physical access to the server, and although a copy of the database was available in an alternative location, no provision had been made to allow the data to be made publicly available without compromising privacy – thus denying a million New Zealanders access to valuable medical records.
This situation could have been avoided by simply making a copy of the server and keeping as a cold standby in the remote location in Auckland.
