Centralize your disaster recovery work

I don't have any specific comments about Mike's
article but I would like to share some work we have done at our company on DR. In particular
a complete procedure to allow restore of a SUN Solaris machine to new ( and different ) hardware.
This took a while to research, create and test.
Can someone let me know if this is of use and how and where I can submit it. Garry Ferguson

Restoring data across WAN links is fine as long as you're restoring files to a machine that is online and functioning.

Centralization for data backups is a very cost effective solution, providing you have invested sufficiently in your comms infrastructure (try restoring 10Gb of data over a DSL line and see how inefficient that is!) but what if the disaster is physical?

Disaster recovery is not just about data, it's about kit and the abilty to function as a business too. If the network card (or both if you've built your server right) have been fried by a freak electrical accident how do you restore files over a WAN? If the RAID array has failed or a workstations hard disk is faulty, what can you really do remotely?

A better stance is to take preventative action rather than reactive support. Put your centralised IT staff on a rolling pre-emptive support scheme, going from site to site on a regular basis to perform health checks and flag potential disaster before thay actually occur.

The best IT systems in the world suffer from the problem that management never notice anything has gone wrong, therefore requiring the IT department to continuously justify its staffing levels - and for that you just need to keep detailed maintenance logs.

After all, a replacement RAID array card is going to cost a lot less than a day with a site not being able to work. You don't pay for business insurance beacuse you HAVE made a mistake, you do so because it's a possibilty you might, and that's something management will not try to cut back on.

Backup technologies exist today to allow you to backup remote systems (where IT staff are scarce) to a central location. These "e-vaulting" solutions are focused on servers as opposed to desktops.

Infostor just wrote an article on the topic...see link http://is.pennnet.com/Articles/Article_Display.cfm?Section=Articles&Subsection=Display&ARTICLE_ID=178555

There are many options for recovery to address ad-hoc and bare-metal restore requirements.

I am new to the disaster recovery field and am hoping you can enlighten me. If all the backup activities and tapes are in one central location don't you run a higher risk of losing all of your data than you would if it were decentralized?

I agree with Mike's assessment of the situation, but would add that for centralized backup solutions you might be best dealing with small business and smnall data.

It has been my experience that the larger a company, and the resulting size of data, the more worthwhile an in-house expert becomes.

Centralization of data recovery, whether backup or disaster recovery, is worthwhile only where a backup solution is prohibitively expensive for a single company.

If they can afford to spend themoney to protect their data, including the hardware and software then they really ought to invest and make sure that they have the skill set on board to make the most use of their investment.

Centralization of data, this concept should only be considered if you do not have any other alternatives. I do believe that data should all be routed to a central recovery site, or point, but distributed to offsite locations that are not part of the main data center. If data is not replicated at/to a recovery site with telecommunications that is configured to handle the load and simply fail over also , what good is the replication? Training and internal audit of the backup processes can accomplish much!

A chimpanzee can be trained to put a tape in a tape drive!

ANSI tape labels with expiration dates and software that enforces those expiration dates, go a long way towards ensuring that yesterday's tape is not being overwritten today. Checking log files gives you some assurance that the right stuff is being backed up. This can be done locally or remotely.

Technical people forget things, make mistakes, go home sick, and go on vacation the same as ordinary mortals do. The key is to have asystem of checks and balances in place that will catch problems before they turn into disasters or contribute to disasters. You need to know that the right tape is being mounted each day, that the backup is backing up what it's supposed to, and that the tapes are being sent off-site.

My name is Mark Akins and I am the Director of IT for a large law firm in Florida. We have tem offices throughout the state and have experienced all of the problems indicaded in your article regarding remote backups. This year we centralized our backup system using a product called Evault. Evault had a remote agent loaded on every remote server. The initial "seed" backup takes a day or two because it is a true full backup of the remote system. Every subsequent backup is a delta snapshot ofthe changes from the previous full backup or snapshot. The other nice thing abouth this technology is that all of our remote offices are backed up to a SAN and the Administrator recives an email notifing of a successful or failed backup. Additionally, because the daily bakcup is a delta level backup, this technology has reduced our remote backups to less than 1 hour. Now considering that we have about a TB of data out there, thats pretty amazing.

After installing this product, I decided to wait two weeks before notifying the remote offices that we had disabled there backup software and were now performing the backups remotely. During this period the IT departemnt did not recieve one call notifying us that the local backups had failed. Centralizing our backup was one of the smartest things we did.