A functional DR and usually the most optimal are the ones that require the least amount of work when disaster strikes. If our the datacenter in which our servers are hosted is destroyed I do not want to be figuring what hardware to restore databases on, where to deploy applications, what to use as load balancers, or what IPs to point my dns records to, what ad hoc config changes I had on a server somewhere. It should all have been preplanned, 80% of that should already have been done. We've got a 100mbit line running into the office. We've got staging servers, database servers and just crap loads of hardware thats used internally which would instantly become our server farm. Databases are being replicated as we speak, those that cannot are being incrementally backed up and restored. I've got a DR dns zone file ready to go, the ttl on dns records is 1800. If you had to do this stuff from scratch yes it would take time. But any credible business that runs online should have these things in place. If you're idea of a backup is your mirrored RAID I feel bad for you.
Does the size of their site matter? Perhaps. Does it require 10 engineers to get a DR strategy going and be able to implement it? No. If you clearly plan this ahead of time, if all the pieces are in place then no it will not take that many. If I was to take into account multiple pieces of infrastructure it could still be done. DR is not about getting the exact same infrastructure up. Its about keeping the business running, its about staying alive and in those situations usually you try the minimal that will get you there. Do I really need my back end reporting and emailing systems when shit hits the fan? No. Messages will queue up and when those systems come online later they'll take care of it.
Am I simplifying it? Perhaps so lets take an example.
In your current infrastructure you've got 100 servers, you got a couple load balancers, 40 webservers, 30-40 app servers and 20 database servers. Load balancers a dummy HA thing where something like haproxy, nginx, keepalived, lvs or something else runs, the second one is just the backup that takes over when the first dies. Those are static configs that dont take much to get up and running somewhere else. 40 webservers. So in my place of work each webserver is identical and any one of those can go down without affecting the other. Usually thats varnish, nginx, apache or something of the like in the front end maybe proxying off to rails apps, php or python. Each server has no dependency except on the database. Got some mid caching layer like memcached? Ok well you'd have one per webserver in a cluster and those things drop in and out with ease. App servers follow suit if you know how to build systems that are not tightly coupled and deal with asynchronous requests. Alot of it comes down to queues and message passing. Obviously there are some inter dependencies which you cant help and if you can solve some of it with intermediary haproxy balancing then great. So far I feel like all of these things can easily be setup on servers anywhere else and code can be frequently updated.
The real complexity is in data stores. I assume in companies with more than 20 machines they may have chosen multiple datastores for different purposes so it doesnt all live in one place. Yes that adds to the difficulty of things but you have to break things down and work on each one at a time. If you're smart you'll have used something that can be replicated, has multi master or is clustered in most cases you dont even have to worry about it because almost every popular datastore these days have those capabilities. Lets look at mysql. Most of the time people go with basic master slave replication and move to master with multiple slaves so you can offload reads. If you're replicating within the one place then theres no reason you cant replicate offsite to your warm standby. If you do maintain that offsite slave then you've got an upto the minute copy of your database in the event of catastrophic failure. Now thats one database down, what if your using redis, well that also has replication so I'm not seeing a problem there either. Mongodb, cassandra, oracle, it really doesnt matter what it is because you can maintain a copy.
At the end of the day its about planning, its about taking the time to already have 80% of the work done and getting the major pieces up and running. Theres no excuse. There really isnt. You think facebook's in one datacenter? Yea at one point they were but back then you really think they didnt have a backup plan? Ok they are big with lots of people but honestly I dont care if you've got 10 different datastores (dont do that) and each is half a terabyte on disk. I dont care what the complexity is, if you think its too complex to have a running backup thats your fault. Imagine google said, "eh yea the application is a bit complicated and we really cant have a backup somewhere else". What?!
Migrations, if you have no plan and are doing it from scratch yes that takes time. It took me a month from start to finish and thats only because I spent the first two trying to figure out how to get chef to automate most of it. But that was a migration and I had the luxury of time. If it was a DR scenario I'd have at max 8-10 hours before the MD would be yelling at me. Put all your databases on servers somewhere else, get the code up and running and have a strategy for switching.