Solve this disaster scenario

It would be helpful to me to have the direct URL to the newsletter in question.

TSP

Everything is fine as long as the failover system is working. But what if it experiences problems? Also with only one IP address this implies a single point of access, not a reliable option for something as critical as failover. Should be multiple access points, preferably via totally separate "backbones."

Does the failover machine have the capacity to
handle all or most of the traffic in a disaster
situation? Is there enough network bandwidth to
the backup to handle the traffic?

Since you don't mention network bandwidth, I'll assume that the client hasn't thought about it. They should!

You neglected to mention whether the replication was synchronous or asynchronous and that could make a difference to the client as well. With asynchronus replication, the client should be prepared to lose some of his newest data; anywhere from a few seconds to a few hours depending on the load, and the available bandwidth.

Finally, you don't mention if or how this was tested. The client should not rely on it until it is tested.

And finally, Mike, many (most?) of us have never had the budget to set up such a thing, much as we'd like to.
"I don't get to run the train,
the whistle I can't blow,
but let the damned thing jump the track,
and see who catches hell!"

And some of us aren't even PC support people!

Please keep this in mind when you put together these exercises.

You need to make sure that you have redundancy. You need at least two (preferably clustered) WinNAS servers to replicate in real time during any failover. You also need to make sure that enough bandwidth is available to redirect the traffic to the failover site as well as for the business to continue functioning. A redundant T1/T3 pipe to the failover site would also help you to sleep better...

Mike Talon is currently overseas, but he said he'd jump in the discussion as soon as he returns. Thanks for your patience.

Bandwidth and redundancy are two possible faults I see with this plan. When they do have to fall back to the DRP site, an aggragate of hits distributed over 8 servers will now be going onto one server. That will tax both processors and RAM as the requests are handled. Also, given that they are relying upon one device in the DRP site, if it fails at the time of cut-over, there will be nothing to fall back on. There should be multiple servers at the DRP site, with overlapping functinality so that the user base will not be compromised by decreased bandwidth or availability.

I'm looking for one particular issue with this Windows NAS scenario that will definitely cause the solution to fail. Bandwith is a consideration, but I specifically left out something that will definitely cause this whole thing to come crashing down during failover.

Mike Talon