>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
I have to share the variant experience at one of the founding
institutions in networking. They carefully analyzed power-consuming
resources, and assigned the least critical to utility power only, the
next most critical to backup with the campus diesel, and the most
critical on UPS. The UPS was equipped with extensive power
management consoles so even finer distinctions could be made when
power was short. As a critical resource, the UPS controller was
locked in a secure room, with an electronic lock.
When the first major power failure hit, they discovered that the
electrical power for said electronic lock had no backup whatsoever.
And guess how the lock reacted to failures? Being unlocked, of
course, would have been a vulnerability...
Luckily, said institution had a tradition of lockpicking skill.
>
>
>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]
