Re: [cobalt-users] BACKUP

[Elmer Fuddpucker <elmer@xxxxxxxxxxxxxx>]

On Wed, 16 May 2001, Gerald Waugh wrote:

} I want to backup everything possible so that when I restore a server,
} all the updates, rpms, php, MySQL, are ready to go.

	I can't help you with this as our approach is different
than most. We run multiple servers, some of which are dedicated to
specific purposes. For example, I've got two primary DNS servers on
line as I write this. One is the real deal. The other is mirror
which is fully configured and ready to go at a moments notice. We
also do the same thing with our client's web sites. We simply set up
accounts on two machines, mirroring the live server's content to the
backup server. The result is that recovering from a hardware failure
is as easy as changing a machine name and/or swapping out some IP
addresses.

} I would also be interested in using your method of keeping a backup
} server ready to go!

	While we don't use Cobalt's for this purpose but the
simplest way to explain how we do it is by saying we do...

	We add a client just like you do. Once the client is up and
running we simply create a second account for them on another
server. Then we use rsync to mirror the live account to the backup
account every 6 hours (this is our "daily" backup). If the live
server fails we simply change the IP addresses on the backup server
and the client is back up and running in a matter of moments.

	The reality is that I buy factory refurbished servers whose
day has come and gone. I stuff them with a couple of huge drives
and load them with Slackware. Then, rather than waste them, we use
the additional disk space for our regularly scheduled backups which
are run on weekly and monthly basis.

} Do you keep the backup server "updated" by rsync, or do you do that
} manually?

	We run rsync from cron. We run monthly and weekly backups
which are stored on the additional drive space mentioned above.
These are separate from the backup of the live server. They also
sometimes make us money. Every now and then a client will trash
their site and few maintain their own backups. In those cases we
restore the client's site for a fee. That may sound cruel but our
backups are to cover our butts, not their's. It costs money to be
able to maintain the backups and most clients understand that it is
going to cost them money to have us restore their site for them
before they call and ask us to do just that.

} When you bring the backup on line, what do you do?

	In the case of a server failure, we simply rename the backup
server and change the applicable IP addresses. We've scripted this
so it's fast and very easy to do... and no, I'm not going to share
the scripts. Not because I'm greedy, I wrote a very popular perl
script (Virtual Yenta) a few years back. Within a few months a dozen
or so perl 'gurus' were claiming the script as their own and it
ended up in retail stores in the East and all I got out of it was a
major headache so I quit distributing my scripts:

	serenity now...
	serenity now...


	brent sims

	Elmer Fuddpucker's WWW Directory
	http://www.fuddpucker.com/