Take, for example, a typical backup server scenario. At first glance, it may seem like a very simple matter to replicate a critical server and locate it in some facility a safe distance from the main data center. It might also apparently be sufficient to assess the viability of this replicated server by having technicians test it every so often.

But this kind of cursory testing doesn’t accurately reflect what will happen if end-users from all over the company all have to connect to the replicated server in the event of a disaster. That’s because all kinds of unforeseen issues can arise when additional physical distance is put between end-users and a server. Those issues may not be evident when a small number of technicians test a replicated server’s performance from a single corporate location. But when disaster strikes, such inadequately tested recovery scenarios can fail miserably.

Here’s why. Distance adds latency, and latency can negatively impact response time and server scalability. So if the replicated server is in a location that’s twice as far from end-users as the original data center, its capacity may be cut in half. When disaster strikes and the replicated server is activated, the cumulative affect of remote end-users connecting to that server is that the application’s performance slows to a crawl—or even becomes completely unavailable to some end-users.

This is just one example of how CIOs can get blindsided by inadequately tested disaster recovery plans. Full-scale production testing, however, is rarely a viable approach either. Few companies can afford to regularly have all their end-users access all critical applications under actual disaster recovery conditions--especially if they’re still not 100% sure that their recovery measures will work.