It Disaster Recovery: How to Minimise the Loss of Data By Derek Rogers At Isnare.com Ezine Articles

A disaster is, by its definition, a low odds probability with a high cost if it happens. An astonishing number of businesses, caught up in the day-to-day running of the enterprise, don't take adequate steps for disaster prevention or have adequate recovery procedures in place. Disasters can be natural (earthquakes, hurricanes, tornadoes) or manmade (vandalism by a former employee, terrorist threats). Either way, your organization's data centre is its brain, and just like a person who has taken a severe brain injury, most organisations that suffer a severe data centre disruption don't recover.

Here are some generally agreed upon best practices. Whilst they are not a sovereign remedy against disaster, they are the measures you should take to ensure continuity.

First, have a plan. Understand what risks your location presents – while hurricanes aren't likely, earthquakes are possible in the UK. Your plan should include, at the very least, who you contact in the event of a service disruption to your power supply or your connectivity or both.

Second, your plan should include provisions for the people who work in your data centre. Will they need facilities to sleep in when the disaster strikes? Or a place where their family can be safe? Your data centre has people, and they are the most important asset you have. Similarly, if you have a mission critical data centre, look at ways to generate your own power; many in the US have on-site diesel storage tanks and generation facilities, so that when the power runs out, before the batteries run out, they can generate onsite storage.

Your next most important asset is the data, and the mantra of data preservation is triage, triage, triage, and backup, backup, backup.

Triage means making a list of what data needs to be backed up and what data doesn't. For example, for your servers, build a mirror that you can restore from that contains the bare operating system, the required applications and configuration files – and then nothing else. That is your restore point; from there the only data you need to back up on your production servers are anything that differs from the default installation.

This can save you tremendous amounts of labour (and confusion) when backing up data; far too many organisations just blindly copy the contents of all hard drives rather than make staged backups.

Your backup plan should include both on site and off site backup provisions. You should make backups on servers at your facility regularly, and should mirror them on an off-site facility as well, so that something that damages your facility doesn't destroy all your data.

The most critical part of a backup plan is doing test restores. You absolutely need to schedule a test restore from backups at least once per month if not more regularly; doing backups without test restorations is a sure fire way to discover, at the wrong time, that your restoration technique is inadequate at the worst possible time. Your users will complain about having a day interrupted for a test restore every month, but it is essential to making this process work.

Published At: Isnare Free Articles Directory http://www.isnare.com
Permanent Link: http://www.isnare.com/?aid=333860&ca=Computers+and+Technology

Important Notice DISCLAIMER: All information, content, and data in this article are sole opinions and/or findings of the individual user or organization that registered and submitted this article at Isnare.com without any fee. The article is strictly for educational or entertainment purposes only and should not be used in any way, implemented or applied without consultation from a professional. We at Isnare.com do not, in anyway, contribute or include our own findings, facts and opinions in any articles presented in this site. Publishing this article does not constitute Isnare.com's support or sponsorship for this article. Isnare.com is an article publishing service. Please read our Terms of Service for more information.