A client of mine is concerned that when our co-lo server goes down, the need to redirect to another mirrored site.
I understand his concern, but our server isn't down any more often than anyone else's and the concerns that it adds - possible Google blocking due to duplicate content, dealing with mirrored FTP uploads, having to rush to point the URL elsewhere and by the time it propigates the issue could be resolved.
At some point you need to assess to what reasonable extent you will maintain service. There is no such thing as 100% uptime. Define what is "reasonable" DR, by whether the cost can be justified. One server going down? reasonable - use load balancing between 2 or more machines. An entire cluster going kaput because a tornado destroyed them? reasonable - you maintain two parallel clusters, geographically separated for failsafety. The entire East Coast being swarmed by magnetic fire-breathing velociraptors, destroying everything that runs on electricity? Unreasonable. Folks'll just have to accept that they can't access the site right now. Sigh and rebuild.
What you DON'T want to do is mirror to a new domain. What you DO want is to direct your traffic to a different physical machine.
for example, example.com -> DNS points to 126.96.36.199 then if 188.8.131.52 is destroyed by hordes of magnetic velociraptors, reroute example.com -> 184.108.40.206, where you have *conveniently* kept a working running copy of the site, and have been diligently replicating the master data all along.
So, don't worry about duplicate content. You won't be publishing thousands of new URLs, you'll merely be pointing the DNS (domain) to a new IP address. That is not punishable in the rankings - large sites use multiple IPS, and big publishers employ distributed CDNs. What you mustn't do is mess around with the URLs that people are requesting. DR should be accomplished with invisible magic.