那么，先介绍一下背景。我所在的公司有许多非常重要、不对外公开的网站。人们的安全和生计取决于这些网站的正常运行。我们的停机时间很少，但总是有灾难性的情况需要从裸机恢复。
我们目前的设置不够完善，但我想听听大家对我所认为的潜在选择的意见。我们在一个非常好的 vSphere 设置上内部托管所有内容。目前，我们有一个庞大的 Ubuntu 实例，它托管所有内容——所有网站、数据库、资产等。
我们采用您能想到的每一种方式进行备份，而 vSphere 设置的优点之一是我们可以在必要时进行异地恢复，但拥有一台大型机器意味着恢复时间并不小。
我看到两条可以走的路。
简单的冗余。从这台机器迁移到 Web 服务器、SAN 和数据库服务器，然后要么让冗余机器全天候待命，要么能够快速启动它们。这是我传统上期望存在的，但我不知道它对我们有多大帮助。异地恢复意味着要花几个小时才能全部网站备份，而且似乎很难以一种可以优先处理最关键任务的方式进行恢复。在内部，使用 vSphere，这似乎不是一个巨大的优势。但是，这相当容易维护。
使用 vSphere 拆分所有内容。每个站点都可以是自己的 vSphere 实例（或一组用于拆分数据库/资产的 vSphere 实例）。这意味着需要做更多工作来维护多个小型服务器，而不是一个整体服务器，但这也意味着我可以在灾难情况下轻松选择恢复站点 A 和站点 B，并将非关键任务留到以后再处理。这也允许在必要时在软件方面有所分歧，这既是好事也是坏事。
有什么意见吗？我是不是忽略了一个显而易见的选择？
答案1
利用 VMware SRM，或者至少是 VMware Replication。它将大大减少您在辅助数据中心上线所需的时间。（Hyper-V Replica 和 HVRM 在 Microsoft 堆栈中是等效的。
将前端与后端分开。听起来你需要一个 Web 层和一个数据库层。
为前端投资适当的负载平衡。这可能意味着安装和配置多站点 Netscalar 集群，或配置类似 HAProxy 的东西。
在数据库层引入冗余。您没有提到您正在使用哪种数据库产品，但许多产品都具有高可用性、复制、集群等功能。使用这个。
将 DR 站点设为“暖站点”，其中有一些服务器（如数据库镜像）会持续运行。这样，您就不必在灾难发生时恢复它们，只需将它们设为活动节点即可。
vSphere 通过抽象硬件使备份和恢复变得更加容易，但是当可用性至关重要时，它无法替代经过验证的 HA 方法。
没有理由为每个网站设置一个 vSphere 实例。这不会给你带来任何好处。
答案2
我见过第二种设置比第一种设置更常见，尤其是当您的 DR 站点的容量与您的主站点不同时。但是，我认为这个问题不太适合 SF，因为它很大程度上是基于意见的（尽管我不会将其标记为这样，因为我认为这个问题有一定价值）。