如果数据和日志文件位于同一个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. 您表示“不需要恢复到上次备份之前的任何时间点”。如果是这样的话，那么是的，切换到简单的恢复。

不过，也有一些评论：

每个人的失败原因都是不同的:开发人员可能决定意外删除数据的频率，存储架构可能决定失败的驱动器是致命的还是仅仅是一种麻烦，等等。

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

对于同一驱动器上的数据和日志文件，传统的看法是将两者分开，因为对数据文件的访问是随机的，而对日志文件的访问是连续的。根据我的经验，如果您谈论的是几个驱动器上的数据库，可以隔离，但是在一个SAN上，100个数据库分布在48个磁盘上，所有的数据访问无论如何都是随机的。

Answer 3

您肯定希望将备份移出磁盘，原因是您指出:磁盘故障会发生。拥有一个本地副本可能很方便，所以这并不一定是坏的--例如，如果最终用户不小心运行了一个没有WHERE子句的delete查询，那么快速访问备份可以节省您的时间。尽管如此，我仍然会将本地备份放在单独的驱动器上；您不希望在承载数据库文件的驱动器上耗尽磁盘空间。此外，绝对应该有另一个副本的场外。遵循3-2-1规则可以帮助您安全地避免产生简历的事件。

关于恢复模型，如果您不需要实时恢复并且经常进行完全备份以满足您的恢复点目标，那么简单的模式就可以了。但是首先要确保--如果SLA保证了4小时的损失，那么您可能希望将事务日志备份保存在那里。