Hi,
I am often amused by people that design sytems to work and test them to work. Why? At
least test them to see if they fail to work.
In a place I worked they had an UPS. This was to supply a backup for the entire
computer room and state wide connumcations centre. Every other month they would come
in and check the batteries test they were fine etc. One day the power to the building
broke and so did the entire network. The UPS sat there and did nothing. It never
failed. Guess what? Nobody had ever plugged the computer room power into the UPS.
Nobody had ever shut down the computer room power to test it. After all you did not
want to tempt fate and we designed it to work.
Just a thought on why you should always test not only to see if something works but
also attempt to break it under trial conditions.
This is where age and experience creeps in.
Teunis,
Hobart, Tasmania
Australia
On Friday, February 23, 2001 at 09:11:09 AM, Howard C. Berkowitz wrote:
> >Brian wisely observed,
>
>
>
> >You have to test it.......no matter what. Thats like having a "Tape
> >backup" system, but never actually trying to do a restore until you *have*
> >to.
>
> In the great tradition of sea stories, "Hey, this really happened!"
>
> A couple of years ago, I had a consulting client that INSISTED on
> reliable Internet connectivity. So, we implemented dual BGP routers,
> one to AT&T and one to a local provider, and made sure the AT&T links
> were provisioned over dual SONET.
>
> I had done most of this design offsite. When I finally visited the
> computer room, I discovered one server. When, rather shocked, I
> asked what happened if the server failed, I was told they had a tape
> backup. When I continued probing, and asked to what server they
> would restore the tape backup, shocked looks broke out.
>
> Incidentally, tape backup, for large transaction processing systems,
> is increasingly being regarded as a secondary or legacy method.
> Given the decreasing cost of mirrored disks, and the increasing
> amount of time it takes to restore from a (serial) tape backup, the
> restoral time with tape backup alone is unacceptable. What is
> increasingly comon is to implement the database either with a doubly
> or (preferably) triply redundant RAID server, or across backup
> datacenters.
>
> In the event of failure, the database fails over to a backup disk
> system. With triple redundancy, that still gives you a backup while
> maintenance is performed on the failed server. Tape is reasonable
> for restoring the failed system once it has been repaired. After
> repair, the previously failed system usually becomes a backup, rather
> than taking over from the current primary server.
>
> >
> >
> >On Thu, 22 Feb 2001, Z wrote:
> >
> >> Question... Anybody know how I can test to see if our dial backup on our =
> >> devices actually kicks up when the primary interface goes down? We have =
> >> dialer interfaces as our backup and I want to see if they work. I just =
> >> got to this place a month ago and have noticed that in most of the =
> >> devices, they don't even have the backup statements configured on the =
> >> primary int. Here's the kicker. I can't take the primary down to do this =
> >> and I don't feel like coming in on the weekend =3Do) I remember =
> >> somebody said something about creating a floating static and pinging =
> >> something but I forget what was said. Is there just an easy way to do =
> >> this? I would imagine there is. Thanks all,
> >>
> >> ********************************************************************
> >> This has been an Eyez Only streaming e-mail broadcast...We are watching.
> >>
> >> ~ NetEyez ~ CCNP, CCDA
> >>
> >> _________________________________
> >> FAQ, list archives, and subscription info:
> >>http://www.groupstudy.com/list/cisco.html
> >> Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
> >>
> >
> >
> >-----------------------------------------------
> > I'm buying / selling used CISCO gear!!
> > email me for a quote
> >
> >Brian Feeny,CCDP,CCNP+VAS Scarlett Parria
> >[EMAIL PROTECTED] [EMAIL PROTECTED]
> >Netjam, LLC
> >http://www.netjam.net
> >1401 Oden St.
> >Suite 18
> >Shreveport, LA 71104
> >318-222-2638 x 109 318-222-2638 x 101
> >Fax 318-221-6612
> >
> >_________________________________
> >FAQ, list archives, and subscription info:
> >http://www.groupstudy.com/list/cisco.html
> >Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
>
> _________________________________
> FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
> Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
>
>
--
www.tasmail.com
_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
