Question: So, a little background. I work for a company that has a number of extremely important, non-public facing websites. People's safety and livelihoods depend on these staying up. We have very little downtime, but there are always catastrophic situations that mean restoring from bare metal.

Our current setup is inadequate, but I'd like opinions on what I see as the potential options. We host everything internally on an incredibly nice vSphere setup. Right now, we have one monstrous Ubuntu instance that hosts everything--all sites, databases, assets, et cetera.

We backup every way you can imagine, and one of the benefits of the vSphere setup is that we can restore offsite if we have to, but having one massive machine means the restore time isn't insignificant. 

I see two roads I can head down.

1. Simple redundancy. Migrating from this one machine to a web server, a SAN and a database server, and then either having redundant machines ready full time, or be able to spin them up quickly. This is what I'd traditionally expect to exist, but I don't know that it helps us that much. Restoring offsite means taking hours to get *all* sites back up, and it seems difficult to restore in a way that I could give preference to the most mission critical things. Internally, with vSphere, this doesn't seem like a massive advantage. But, this is fairly easy to maintain.
2. Split everything up with vSphere. Each site could be its own vSphere instance (or small set of vSphere instances to split out database/assets). This means more work maintaining a number of small servers instead of the one monolithic one, but it also means I could easily choose to restore Site A and Site B in a catastrophic situation, and leave the non-mission critical things for later. This also allows things to diverge software wise where necessary, which is both a positive thing and a negative thing.

Opinions? Am I ignoring an obvious option?

Answer: 
* Leverage VMware SRM, or at least VMware Replication. It will drastically reduce the amount of time it takes you to come online in a secondary datacenter. (Hyper-V Replica and HVRM are the equivalent in the Microsoft stack.
* Separate your front-end from your back-end. It sounds like you need a web tier and a database tier.
* Invest in proper load balancing for your front end. This can mean installing and configuring a multi-site Netscalar cluster, or configuring something like HAProxy.
* Introduce redundancy in your database tier. You don't mention which DB product you're using, but many have high availability, replication, clustering, etc available. Use this.
* Make your DR site a "warm site" where you have some servers running constantly, such as database mirrors. Then you don't have to restore them in a disaster, you just make them the active node.

vSphere makes backup and recovery easier by abstracting the hardware away, but it's no substitute for tried and true HA methods when availability is critical.

There's no reason to have a single vSphere instance per-website. This doesn't gain you anything.
I've seen the second setup more often than the first, especially when your DR site doesn't have the same capacity as your primary site. However, I think this question isn't really appropriate for SF, since it's very much opinion based (although I'm not going to flag it as such since I see some value to the question).