thoughts on setting up an emergency server

thoughts on setting up an emergency server

[Gregory Nowak]

Hi all.

I've been thinking of the possibility of a dark day when some piece of hardware should fail in my server, leaving it inoperable, and me up a creek without a paddle.

I usually wouldn't have the time to setup another box to temporarily replace the failed one. Instead, I'd like to have things already set, so that I can make some minor tweaks if need be, and let a replacement run.

I do have one more box with gnu/linux that I can configure as a server just in case.
However, doing so would mean that I would need to keep in mind that it should be a backup server any minute, and that I can't mess around with it like I could otherwise.

What came into my head is to put zipslack/speak on a 250 meg zip disk. Then, should something go wrong with the main box, I can hook up my parallel zip drive into another box, and let it run until I was able to get the main box back online without being under pressure.

I would strip zipslack to the minimum needed to run web, dns, and mail.

The advantage would of course be that it would all be ready to go.
The disadvantage would be the 250 meg limit.

I was wondering if those of you who run your own domains have prepared for the dark day I described.

If so, I would appreciate it if you could please share your plan b for my brain to chew on and/or resynthesize to meet my needs.

Some people may just ask why don't I take a couple of hours, install slackware on some other partition some where, and I'd be ready to go.

It wouldn't be that simple, since I'd need to build software such as qmail from sources, and I have also pretty heavily modified my current slackware server's startup scripts to meet my specific needs.

Thanks in advance for any thoughts.
Greg

Re: thoughts on setting up an emergency server

[Darrell Shandrow]

Hi Greg,

Well, first, especially if a particular system is mission-critical, it is a
very good idea to make a full system backup and keep that backup up to date.
Perhaps, do a full backup once weekly, then an incremental backup each night
thereafter.  Of course, you'll need to devise a quick method of restoring
such a full backup in the event of an emergency.

Outside of that, well, it'd be best to just have another Linux box up and
ready to go.  When the inevitable happens, just change the IP addresses on
that second box as needed, and you're all set.  Of course, your second Linux
box must be configured the same or similarly to your primary one; though it
doesn't probably have to be nearly as powerful.

OK; hope this helps.





----- Original Message -----
From: "Gregory Nowak" <greg@romuald.net.eu.org>
To: <speakup@braille.uwo.ca>
Sent: Saturday, October 26, 2002 8:28 PM
Subject: thoughts on setting up an emergency server


> Hi all.
>
> I've been thinking of the possibility of a dark day when some piece of
hardware should fail in my server, leaving it inoperable, and me up a creek
without a paddle.
>
> I usually wouldn't have the time to setup another box to temporarily
replace the failed one. Instead, I'd like to have things already set, so
that I can make some minor tweaks if need be, and let a replacement run.
>
> I do have one more box with gnu/linux that I can configure as a server
just in case.
> However, doing so would mean that I would need to keep in mind that it
should be a backup server any minute, and that I can't mess around with it
like I could otherwise.
>
> What came into my head is to put zipslack/speak on a 250 meg zip disk.
Then, should something go wrong with the main box, I can hook up my parallel
zip drive into another box, and let it run until I was able to get the main
box back online without being under pressure.
>
> I would strip zipslack to the minimum needed to run web, dns, and mail.
>
> The advantage would of course be that it would all be ready to go.
> The disadvantage would be the 250 meg limit.
>
> I was wondering if those of you who run your own domains have prepared for
the dark day I described.
>
> If so, I would appreciate it if you could please share your plan b for my
brain to chew on and/or resynthesize to meet my needs.
>
> Some people may just ask why don't I take a couple of hours, install
slackware on some other partition some where, and I'd be ready to go.
>
> It wouldn't be that simple, since I'd need to build software such as qmail
from sources, and I have also pretty heavily modified my current slackware
server's startup scripts to meet my specific needs.
>
> Thanks in advance for any thoughts.
> Greg
>
>
> _______________________________________________
> Speakup mailing list
> Speakup@braille.uwo.ca
> http://speech.braille.uwo.ca/mailman/listinfo/speakup

Re: thoughts on setting up an emergency server

[Patrick Turnage]

Hi
One disadvantage to using zipslack on a zip drive is the slow slow speeds
from the lpt port, I ran zipslack on a zip drive for a while when my
laptop's hard drive was being repaired and it was incredably slow, booting
took over 2 minutes, and emacs took a while too..
If you can manage this, I'd buy an extra hard drive and then nightly mirror
your current setup on it, so add another hard drive to your server and only
use it to be mirrored everyday, then if your machine ever dies than swap
out the hard drive in your other linux box and replace it with your
server's hard drive back up, and then hen ever your server gets replaced or
fixed just copy your back up hard drive to your new server's hard drive and
then you do not have to do all that stuff that goes with setting up and
preconfiguring a new system.


-----
Patrick Turnage
E-mail: pturnage@tampabay.rr.com
AOL Instant Messenger: kg4dqk
Home Page:
http://www.access-connect.com

Re: thoughts on setting up an emergency server

[Gregory Nowak]

Thanks Darrel.

Actually, this is a 2 drive system, with both drives in use (no, it's not for raid).
Every 24 hours, I have a script that tar balls the entire system, and stores a copy on each drive. That way, if it's something like a drive failure, All I have to do is to untar the last backup on the remaining drive, and I'm all set.
However, if it's something more critical, then ...

I also have a cdrw set which I bring up to date weekly with my configuration files, and user directories if they're not too big to fit on the backup.

This box is slackware 8.0, with the internet tools such as bind and apache updated to the newest versions from 8.1 packages.
If this box should ever go, I'd like to be able to do a full reinstall with the newest version of slackware or maybe debian, so that I don't just keep using an outdated distro version when I have the chance and excuse to replace it.

Greg


On Sat, Oct 26, 2002 at 09:15:28PM -0700, Darrell Shandrow wrote:
> Hi Greg,
> 
> Well, first, especially if a particular system is mission-critical, it is a
> very good idea to make a full system backup and keep that backup up to date.
> Perhaps, do a full backup once weekly, then an incremental backup each night
> thereafter.  Of course, you'll need to devise a quick method of restoring
> such a full backup in the event of an emergency.
> 
> Outside of that, well, it'd be best to just have another Linux box up and
> ready to go.  When the inevitable happens, just change the IP addresses on
> that second box as needed, and you're all set.  Of course, your second Linux
> box must be configured the same or similarly to your primary one; though it
> doesn't probably have to be nearly as powerful.
> 
> OK; hope this helps.
> 
> 
> 
> 
> 

Re: thoughts on setting up an emergency server

[Darrell Shandrow]

Hi Greg,

OK.  Then, simply tarball all the configuration files for the various
applications and utilities you use, as well as all the mission-critical data
such as e-mail and web sites.  Do this in such a manner as to keep the
existing directory structure intact; I think tar already does this by
default?  Do this in the form of a full backup weekly and an incremental
backup nightly.  Make sure to keep current, full-installation CD-ROMS
available for the Linux distro you use.  It would probably be best to have
the backup be the same distro as that running on your actual
mission-critical system, as different distros do things differently.  Then,
do restore, just re-install your full Linux distro, then restore the
configurations and the data from the backup.  Of course, all your customized
binaries and sources would certainly need to be included in the backup...
:-)


----- Original Message -----
From: "Gregory Nowak" <greg@romuald.net.eu.org>
To: <speakup@braille.uwo.ca>
Sent: Saturday, October 26, 2002 9:45 PM
Subject: Re: thoughts on setting up an emergency server


> Thanks Darrel.
>
> Actually, this is a 2 drive system, with both drives in use (no, it's not
for raid).
> Every 24 hours, I have a script that tar balls the entire system, and
stores a copy on each drive. That way, if it's something like a drive
failure, All I have to do is to untar the last backup on the remaining
drive, and I'm all set.
> However, if it's something more critical, then ...
>
> I also have a cdrw set which I bring up to date weekly with my
configuration files, and user directories if they're not too big to fit on
the backup.
>
> This box is slackware 8.0, with the internet tools such as bind and apache
updated to the newest versions from 8.1 packages.
> If this box should ever go, I'd like to be able to do a full reinstall
with the newest version of slackware or maybe debian, so that I don't just
keep using an outdated distro version when I have the chance and excuse to
replace it.
>
> Greg
>
>
> On Sat, Oct 26, 2002 at 09:15:28PM -0700, Darrell Shandrow wrote:
> > Hi Greg,
> >
> > Well, first, especially if a particular system is mission-critical, it
is a
> > very good idea to make a full system backup and keep that backup up to
date.
> > Perhaps, do a full backup once weekly, then an incremental backup each
night
> > thereafter.  Of course, you'll need to devise a quick method of
restoring
> > such a full backup in the event of an emergency.
> >
> > Outside of that, well, it'd be best to just have another Linux box up
and
> > ready to go.  When the inevitable happens, just change the IP addresses
on
> > that second box as needed, and you're all set.  Of course, your second
Linux
> > box must be configured the same or similarly to your primary one; though
it
> > doesn't probably have to be nearly as powerful.
> >
> > OK; hope this helps.
> >
> >
> >
> >
> >
>
> _______________________________________________
> Speakup mailing list
> Speakup@braille.uwo.ca
> http://speech.braille.uwo.ca/mailman/listinfo/speakup

Re: thoughts on setting up an emergency server

[Janina Sajka]

This is more complicated than it needs to be.

Just mirror the primary computer to the backup machine nightly. That way, the second is always ready to go with an ip
adjustment--or even without one depennding on how the ifrewall is handled.


Darrell Shandrow writes:
> From: "Darrell Shandrow" <nu7i@azboss.net>
> 
> Hi Greg,
> 
> Well, first, especially if a particular system is mission-critical, it is a
> very good idea to make a full system backup and keep that backup up to date.
> Perhaps, do a full backup once weekly, then an incremental backup each night
> thereafter.  Of course, you'll need to devise a quick method of restoring
> such a full backup in the event of an emergency.
> 
> Outside of that, well, it'd be best to just have another Linux box up and
> ready to go.  When the inevitable happens, just change the IP addresses on
> that second box as needed, and you're all set.  Of course, your second Linux
> box must be configured the same or similarly to your primary one; though it
> doesn't probably have to be nearly as powerful.
> 
> OK; hope this helps.
> 
> 
> 
> 
> 
> ----- Original Message -----
> From: "Gregory Nowak" <greg@romuald.net.eu.org>
> To: <speakup@braille.uwo.ca>
> Sent: Saturday, October 26, 2002 8:28 PM
> Subject: thoughts on setting up an emergency server
> 
> 
> > Hi all.
> >
> > I've been thinking of the possibility of a dark day when some piece of
> hardware should fail in my server, leaving it inoperable, and me up a creek
> without a paddle.
> >
> > I usually wouldn't have the time to setup another box to temporarily
> replace the failed one. Instead, I'd like to have things already set, so
> that I can make some minor tweaks if need be, and let a replacement run.
> >
> > I do have one more box with gnu/linux that I can configure as a server
> just in case.
> > However, doing so would mean that I would need to keep in mind that it
> should be a backup server any minute, and that I can't mess around with it
> like I could otherwise.
> >
> > What came into my head is to put zipslack/speak on a 250 meg zip disk.
> Then, should something go wrong with the main box, I can hook up my parallel
> zip drive into another box, and let it run until I was able to get the main
> box back online without being under pressure.
> >
> > I would strip zipslack to the minimum needed to run web, dns, and mail.
> >
> > The advantage would of course be that it would all be ready to go.
> > The disadvantage would be the 250 meg limit.
> >
> > I was wondering if those of you who run your own domains have prepared for
> the dark day I described.
> >
> > If so, I would appreciate it if you could please share your plan b for my
> brain to chew on and/or resynthesize to meet my needs.
> >
> > Some people may just ask why don't I take a couple of hours, install
> slackware on some other partition some where, and I'd be ready to go.
> >
> > It wouldn't be that simple, since I'd need to build software such as qmail
> from sources, and I have also pretty heavily modified my current slackware
> server's startup scripts to meet my specific needs.
> >
> > Thanks in advance for any thoughts.
> > Greg
> >
> >
> > _______________________________________________
> > Speakup mailing list
> > Speakup@braille.uwo.ca
> > http://speech.braille.uwo.ca/mailman/listinfo/speakup
> 
> 
> _______________________________________________
> Speakup mailing list
> Speakup@braille.uwo.ca
> http://speech.braille.uwo.ca/mailman/listinfo/speakup

-- 
	
				Janina Sajka, Director
				Technology Research and Development
				Governmental Relations Group
				American Foundation for the Blind (AFB)

Email: janina@afb.net		Phone: (202) 408-8175

Re: thoughts on setting up an emergency server

[John Covici]

Well, you might want to look at the following web page
http://www.knopper.net/knoppix/index-en.html because what this is a
complete live system on a bootable cd which is supposed to autodetect
hardware etc.  I have gotten it to talk, but it still needs a bit of
fixing up, but it has already saved a certain portion of my anatomy
when I couldn't boot into linux.  It uses kernel 2.4.19 with the xfs
patch.


on Sat, 26 Oct 2002 22:28:47 -0500 Gregory Nowak <greg@romuald.net.eu.org> wrote:

> Hi all.
>
> I've been thinking of the possibility of a dark day when some piece of hardware should fail in my server, leaving it inoperable, and me up a creek without a paddle.
>
> I usually wouldn't have the time to setup another box to temporarily replace the failed one. Instead, I'd like to have things already set, so that I can make some minor tweaks if need be, and let a replacement run.
>
> I do have one more box with gnu/linux that I can configure as a server just in case.
> However, doing so would mean that I would need to keep in mind that it should be a backup server any minute, and that I can't mess around with it like I could otherwise.
>
> What came into my head is to put zipslack/speak on a 250 meg zip disk. Then, should something go wrong with the main box, I can hook up my parallel zip drive into another box, and let it run until I was able to get the main box back online without being under pressure.
>
> I would strip zipslack to the minimum needed to run web, dns, and mail.
>
> The advantage would of course be that it would all be ready to go.
> The disadvantage would be the 250 meg limit.
>
> I was wondering if those of you who run your own domains have prepared for the dark day I described.
>
> If so, I would appreciate it if you could please share your plan b for my brain to chew on and/or resynthesize to meet my needs.
>
> Some people may just ask why don't I take a couple of hours, install slackware on some other partition some where, and I'd be ready to go.
>
> It wouldn't be that simple, since I'd need to build software such as qmail from sources, and I have also pretty heavily modified my current slackware server's startup scripts to meet my specific needs.
>
> Thanks in advance for any thoughts.
> Greg
>
>
> _______________________________________________
> Speakup mailing list
> Speakup@braille.uwo.ca
> http://speech.braille.uwo.ca/mailman/listinfo/speakup
>

-- 
         John Covici
         covici@ccs.covici.com

Re: thoughts on setting up an emergency server

[Janina Sajka]

So, you want what the IT industry calls "faul tolerance?" Good for you.

Do you have a bootable CD ROM? Why not put the basics on a bootable CDR?

Scaling up from there, the next step, imho, would be a second hd mirroring the first. Scaling further, a second
controller for the second hd. Beyond that, I'm afraid, it's a second machine.

Gregory Nowak writes:
> From: Gregory Nowak <greg@romuald.net.eu.org>
> 
> Hi all.
> 
> I've been thinking of the possibility of a dark day when some piece of hardware should fail in my server, leaving it inoperable, and me up a creek without a paddle.
> 
> I usually wouldn't have the time to setup another box to temporarily replace the failed one. Instead, I'd like to have things already set, so that I can make some minor tweaks if need be, and let a replacement run.
> 
> I do have one more box with gnu/linux that I can configure as a server just in case.
> However, doing so would mean that I would need to keep in mind that it should be a backup server any minute, and that I can't mess around with it like I could otherwise.
> 
> What came into my head is to put zipslack/speak on a 250 meg zip disk. Then, should something go wrong with the main box, I can hook up my parallel zip drive into another box, and let it run until I was able to get the main box back online without being under pressure.
> 
> I would strip zipslack to the minimum needed to run web, dns, and mail.
> 
> The advantage would of course be that it would all be ready to go.
> The disadvantage would be the 250 meg limit.
> 
> I was wondering if those of you who run your own domains have prepared for the dark day I described.
> 
> If so, I would appreciate it if you could please share your plan b for my brain to chew on and/or resynthesize to meet my needs.
> 
> Some people may just ask why don't I take a couple of hours, install slackware on some other partition some where, and I'd be ready to go.
> 
> It wouldn't be that simple, since I'd need to build software such as qmail from sources, and I have also pretty heavily modified my current slackware server's startup scripts to meet my specific needs.
> 
> Thanks in advance for any thoughts.
> Greg
> 
> 
> _______________________________________________
> Speakup mailing list
> Speakup@braille.uwo.ca
> http://speech.braille.uwo.ca/mailman/listinfo/speakup

-- 
	
				Janina Sajka, Director
				Technology Research and Development
				Governmental Relations Group
				American Foundation for the Blind (AFB)

Email: janina@afb.net		Phone: (202) 408-8175

Re: thoughts on setting up an emergency server

[Gregory Nowak]

Well, those are good suggestions , but there are a few problems.

1. More hds, controllers, or another machine are out, because they cost, and I don't have the budget of an it department at my disposal (smile).

2. The bootable cdrw is a good option, because I can keep it updated.
However, this would mean the whole system would be running from ram, and any additional info stored while the system was running would be lost upon a reboot.

Greg


On Sun, Oct 27, 2002 at 10:55:40AM -0500, Janina Sajka wrote:
> So, you want what the IT industry calls "faul tolerance?" Good for you.
> 
> Do you have a bootable CD ROM? Why not put the basics on a bootable CDR?
> 
> Scaling up from there, the next step, imho, would be a second hd mirroring the first. Scaling further, a second
> controller for the second hd. Beyond that, I'm afraid, it's a second machine.
> 

Re: thoughts on setting up an emergency server

[Janina Sajka]

Well, Greg, you did say "emergency." I wouldn't regard running full time from the CDR as most attractive, but it would
get you back and up in the event of an hd/controller issue--hardware, or firewall breach. This approach does not
substitute for good backups.

Or, just burn a new CDR every X interval -- weekly, monthly, whatever fits your risk vs. funds assessment. No doubt that
fault tolerance costs, it sure does. So, you need to determine what's the best path to getting back up and running,
given your available resources. I would certainly expect you're not talking redundant systems in disparate geographic
locations. Even most businesses don't go that far--and don't really need to.

It's a matter of prudently assessing risks, and planning for recovery.

Here's what I do:

I back up my data on two different machines--one at home and one at the office. I have substantially the same data, in
other words, in /home on my portable (which is my main machine), my office and home server. I keep a backup of critical
configuration data from /etc backed up on /home. I even have a shell script to help me get my configurations back
quickly. For example, I do "cat filename >> /etc/passwd to help restore my users following o n some event that requires
recovery.

Of course, in my situation, I find myself using this strategy mostly because I've decided to upgrade my
installation--not because my system was trashed, but it's really about the same thing. It isn't that hard reinstalling
from scratch if you know your partition setup, and you keep appropriate backups of /etc, /usr/local, /var/ftp/pub, etc.,
etc, as appropriate.

It's the stuff in /home that's not easily recovered, should it be lost.

In my risk assessment, a ups is very important. I keep a ups on my home server because I have frequent
brownouts--several per month. Gregory Nowak writes: > From: Gregory Nowak <greg@romuald.net.eu.org> > > Well, those are
good suggestions , but there are a few problems. > > 1. More hds, controllers, or another machine are out, because they
cost, and I don't have the budget of an it department at my disposal (smile). > > 2. The bootable cdrw is a good option,
because I can keep it updated. > However, this would mean the whole system would be running from ram, and any additional
info stored while the system was running would be lost upon a reboot. > > Greg > > > On Sun, Oct 27, 2002 at 10:55:40AM
-0500, Janina Sajka wrote: > > So, you want what the IT industry calls "faul tolerance?" Good for you. > > > > Do you
have a bootable CD ROM? Why not put the basics on a bootable CDR? > > > > Scaling up from there, the next step, imho,
would be a second hd mirroring the first. Scaling further, a second > > controller for the second hd. Beyond that, I'm
afraid, it's a second machine. > > > > _______________________________________________ > Speakup mailing list >
Speakup@braille.uwo.ca > http://speech.braille.uwo.ca/mailman/listinfo/speakup

-- 
	
				Janina Sajka, Director
				Technology Research and Development
				Governmental Relations Group
				American Foundation for the Blind (AFB)

Email: janina@afb.net		Phone: (202) 408-8175

downloading ISO CD

[Glenn Ervin]

Could someone send an FTP  link for downloading a CD ISO of Debian -Woody
distribution?
I have followed many ftp downloads, for debian, but they were all potato.
Thanks.