Planning for Disaster
A great kickstart of an article on Linux.com (by Brian Jones) got me started on a quick review of the disaster recovery plans I have in place for my own systems as well as those of my clients.
Having come from enterprise level IT in financial services, I had a good bit of experience planning — so even in the small and medium environments I operate in now, disaster recovery always becomes part of client conversations.
Like most, if not all of us, I perform the traditional backups from the web side of operations (databases, configuration files, data, etc.) both locally as a hot backup and remotely on a daily basis using automation. Once monthly a batch of these backups go to CD or DVD and land in a bank safe deposit box.
Internally (non-web) the same basic processes occur, daily backups both in local hot copies and a weekly remote backup as well as once monthly archives to CD or DVD.
In many cases I have also begun using small RAID arrays with clients. For example, one customer deals in audio and video daily. They run an external firewire RAID 1 array of two 160 GB drives. In RAID 1 drive A is mirrored by drive B. We also have a drive C that is swapped out once weekly and taken off site. In this scenario we chose hot swappable drives so we could yank and change the mirror drive on demand.
Recently I have also been testing the use of third-party backup services that offer compressed data transfer and storage over a broadband or higher Internet connection. These vendors utilize encryption to secure the process and store data indefinitely or by parameters set when the service is initialized. I have found one particular service that offers 1 GB of compressed storage for $17.50 monthly (backs up 2 GB of data).
Back to the beginning — one thing I have not done is investigated profiling software such as that in SUSE. SCPM (System Configuration Profile Management) looks to be a candidate for just such an add-on to my plans. SCPM profiles and stores information on your (for example) Apache, firewall and other daemon configuration files and stores them in a text file. So long as these files were included in your backup plan, recovering from a server disaster could be easier.
Basically a reinstall of the base OS with your required daemons would be followed with a restoration of the profiles and then SCPM should redeploy the stored configuration data for those critical applications. Not only did you recover from disaster, but you probably did it hours faster.
I would look forward to hearing about your disaster recovery plans, goals or questions.