这主要是理论上的，但如果将来发生这种情况，我希望有一个记录在案的选项列表。
今天，我们在 SAN 上遇到了一个严重的磁盘错误，这意味着保存我们生产实例之一的事务日志文件的磁盘崩溃了，最初看起来它已经死了。显然，实例、数据库以及在其上运行的应用程序都会下降。
我们的数据中心人员正忙于研究磁盘故障的原因、原因和方式，与此同时，我很快就想出了一个数据库恢复选项列表。
好的，所以数据中心人员恢复了磁盘。这是 VPLEX 错误，而不是物理硬件故障。
但同时我发现我没有太多选择。实例不会启动，因为系统和用户数据库的所有日志文件都无法访问。如果 Sys 数据库日志文件位于“已启动”的单独磁盘上，实例是否会重新启动
我可以访问 .mdf 文件，所以我可以选择将它们复制到另一个服务器，然后将它们与另一个卷上的新日志文件附加在一起。要么使用我们相当有弹性的备份将数据库恢复到另一个服务器\实例。这两种选择都对应用程序人员有用，因为所有应用程序和相关服务都需要重新指向。
我还有另一种选择，即删除服务器上的实例并使用相同的实例名称重新安装它，然后从完整的广告日志备份中恢复所有数据库。从理论上讲，这对 App 团队来说没有任何工作，但对我（唯一的 DBA）来说却有严重的时间开销。
我在这里错过任何选择吗？我最近才开始这份工作，公平地说这里的文档是有限的。在过去的几个月里，我一直忙于整理我们 SQL Estate 的清单，查看补丁/升级差距等，并参与了几个项目。我认为可以公平地说，针对这种情况的记录在案的灾难恢复计划现在是我们层级议程的首要任务。
任何帮助表示赞赏。
灾难恢复计划取决于
1.可接受的停机时间
2.可接受的数据丢失
您制定的任何灾难恢复计划都将仅围绕以上两点
您的灾难恢复选项不取决于所涉及的工作量以及谁在其中所占的份额。
您将不得不与业务人员坐在一起，弄清楚他们可以承受的停机时间和数据丢失是多少。在此基础上，您必须制定计划（使用高可用性选项）并不时对其进行测试（模拟演习）。