如果数据和日志文件在同一个 HD 上，使用完全恢复是否有意义？

Question

我们有一个被设置为使用完全恢复的数据库，我的猜测是，如果完全备份之间发生故障，推理只是为了防止数据丢失。

我们每天对数据库进行完整备份，无需恢复到上次完整备份之前的任何时间点。

我们的数据文件和日志文件在同一个硬盘上。根据我的经验（作为程序员，我不是 DBA），我见过的大多数数据库故障都与磁盘故障有关，所以我想知道这种设置是否有意义。我想如果硬盘驱动器出现故障，我们将无法使用事务日志进行恢复。

所以我的问题是双重的：

1. 最可能的原因是数据库故障、硬盘驱动器故障，还是有其他常见原因可以证明这种设置是合理的？
2. 切换到简单的恢复模式并说服企业在最坏的情况下他们将不得不重新输入当天的数据是否更有意义？

Answer 1

我无法与 1 交谈，但对于 2，我不知道您的职位应该将业务推向特定的RPO（恢复点目标）。他们可能没有意识到，如果出现问题，他们将不得不重新输入一天的所有数据。与他们交谈，了解他们愿意容忍多少数据丢失。如果他们说 24 小时太多了，很好，那么这表明目前的方法不足以满足他们的需求。如果这需要购买硬件来满足 RPO，那么他们将需要提供资金或接受他们当前的最大数据丢失。最后，在某个公共场所记录结果，然后定期测试您的恢复，以确保您能够满足该 RPO。

也就是说，在不同的驱动器上保存数据和日志（和临时文件）还有很多其他原因。其中一些记录在这个问题https://serverfault.com/questions/38511/ms-sql-layout-for-best-performance

Answer 2

首先，直接回答问题：

1. 以我个人的经验，如果我记分，数据库恢复的原因是：意外删除数据 = 很多，恢复到 dev 进行测试 = 很多，IO 系统故障/损坏 = 无。（敲木头）

2. 您表示您“无需恢复到我们上次备份之前的任何时间点”。如果情况确实如此，那么是的，切换到简单恢复。

不过也有一些评论：

每个人的故障原因都不同：开发人员的才能可能决定意外数据删除的频率，存储架构可能决定故障驱动器是致命的还是只是麻烦，等等。

至于 SIMPLE 与 FULL 恢复模型，这是应该由业务人员做出的决定。他们需要权衡停机和/或数据丢失对业务的损害与管理和空间成本。

关于同一驱动器上的数据和日志文件，传统观点将两者分开，因为对数据文件的访问是随机的，而对日志文件的访问是顺序的。根据我的经验，如果您在谈论可以隔离的驱动器上的几个数据库，这会起作用，但是在具有 100 个数据库分布在 48 个磁盘上的 SAN 上，无论如何所有数据访问都变得随机。