Disaster Recovery - What are your plans?
Jan 17, 2001
No, you're not being paranoid, Murphy really IS out to get
you. (That's Murphy of Murphy's Law i.e. "Anything that can go
wrong, will.") Have you given any thought to how you might
recover your website from the various disasters that might befall it?
I'm not talking about tornadoes, hurricanes and other acts of God,
although they can wreck havoc on your website too. Instead, here are
some more likely problems to worry about:
- The hard drive dies on your webserver. Completely unrecoverable,
all of the data on it is gone.
- The ISP you're hosting with goes bankrupt, turns off the computers,
locks their doors and is no longer answering the phone.
- Some script kiddie hacker decides to have fun and deface your website.
- Your web developer is run down by a rabid water buffalo. Do you
know the passwords to your website? Does more than one person know
how to do the updates?
Basically you need to have a plan to quickly rebuild your website
on a new webserver. In order to do that, you need to have all of the
latest files and data available. Remember, this may be more than just
a copy of the HTML files that comprise your website. It also includes
the domain name, the email accounts, the data stored in the database,
all of the little parts that get lost in the shuffle.
Here is a list of some of the common components of websites that
you'll need to have copies of in order to rebuild it quickly.
- Control of your domain name - If you have to move your website
to another machine, perhaps at a another ISP, you will need to update
the name servers that point users at your website. Do you know how to
update the name servers for your domain name or did that information
walk out the door with the consultant you hired? Do you have the
power to update them yourself, or is it in the hands of your web
developer, ISP or some other person? Once you update the top level
servers, it will take 24-48 hours for the change to ripple through the
rest of the Internet. If you have to wait 2-3 days for someone else
to get around to updating the top level servers, your website could be
down for a week or more.
Even if your website is only a couple of static HTML pages,
commonly called a brochure site, you need to have control of your own
domain name. You won't get any customers off the Internet if they
can't find you.
- Copes of the HTML files - This is what most people think of
when they talk about backing up their website. The HTML pages, the
images, all of the files that comprise your website. It's all very
well if your ISP does network backups. However, you won't have access
to those backups if the ISP has gone bankrupt or is flooded, etc.
Make sure you have your own copy as well.
In my case, I have a development webserver in my office. I make
all of the website changes there before uploading them to the public
server, so I have a backup copy built into my process. If you don't
do this, or if you pay someone else to develop your website for you,
make sure you get updates. Zip disks, recordable CDROM's are all good
ways to have a spare copy kicking around.
- Database backups - This tends to be a bit more tricky because
the data within the database is always changing, so a monthly backup
usually isn't frequent enough. Personally, the database on my website
is setup to allow remote access. So every night, I pull a complete
copy of the data down to the development server in my office. The
most I'll loose is a single days worth of data which is an acceptable
risk to me. Allowing remote access is a security hole though so some
webhosts won't do it. One of my customers has a script that runs on
their webserver every 8 hours. It dumps a copy of the database
contents and emails it to their home account. Note that the email
address you send the database backup to should NOT be on the same
server as your website. If the webserver is down, you can't get at
the email either.
- A list of Usernames, passwords, special programs, etc. - If you
own or lease your own webserver, you probably have other software
installed on it that you can't easily find on the average webhost.
This might be mailing list software, special cron jobs, whatever.
Make sure you have a copy of the source code for every one of these
programs. You'll need them to rebuild the website on a new server.
This includes license numbers for shopping carts, merchant accounts,
FTP programs, everything that goes into making the website tick.
If you have multiple employees, do you know all of their
accountnames on the webserver? If you must set these up again on
another server, having that list around is really useful. If you have
separate mailing list software, are there any special mail server
configurations that would need to be setup again?
The list goes on but gets increasingly customized to each website
so you'll need to build it up for yourself. Larger companies have the
cash to solve this problem by running two copies of their website.
Often on opposite sides of the country. If you're going to pay to
have two copies of the website, you might as well use both of them
instead of leaving the spare collecting dust in a storage room. It's
more cost effective and everybody will forget to update the spare if
it's not being used frequently. For the rest of us with smaller
budgets, we need to have a plan to rebuild. Just remember, a disaster
is only an emergency if you're not prepared for it.
If you have any comments or questions, please feel free to drop Rene an
email at firstname.lastname@example.org. If
you would like assistance in setting up this kind of feature on your website,
please contact us for a quote.