数据库备份/恢复过程

Question

在SQL Server上备份和恢复大型数据库或数据库集合的过程对于灾难恢复非常重要。然而，我还没有找到一个强大的解决方案，可以保证整个过程尽可能高效、100%可靠，并且易于在多台服务器上进行维护和配置。

微软的维护计划似乎不够充分。我使用的最佳解决方案是手动创建许多作业，每个数据库有许多步骤，在源服务器（备份）和目标服务器（恢复）上运行。这些作业使用存储过程进行备份、复制和恢复。这个过程每天运行一次（完全备份/恢复），并在每5分钟内进行日内交易日志传送。

虽然我的当前过程可以工作并通过电子邮件报告任何作业失败，但我知道整个过程并不是非常可靠，并且非DBA无法轻松地在所有服务器上进行维护/配置，需要深入了解该过程。

我想知道其他人是否有相同的备份/恢复过程，以及其他人如何解决这个问题。

- HAdes

Answer 1

你的问题关键在于备份解决方案能否由非DBA管理。任何原生的SQL Server答案，如备份脚本都无法满足这种需求，因为备份脚本需要T-SQL知识。

因此，你需要寻找像Mitch Wheat提到的第三方解决方案。我为Quest工作（制造商LiteSpeed），当然我更喜欢它 - 这很容易向非DBA展示。在我离开上一家公司之前，我有一个十分钟的会议向系统管理员和开发人员展示了LiteSpeed控制台的工作原理，那就是这样。从那以后他们再也没有打电话来过。

另一种方法是使用与您的商店中其他备份软件相同的备份软件。 TSM，Veritas，Backup Exec和Microsoft DPM都有SQL Server代理，可以让您的Windows管理员以不同程度的易用性管理备份过程。如果您真的想让非DBA管理它，这可能是最简单的方法，尽管您会牺牲SQL特定备份工具带给您的很多性能。

- Brent Ozar

Answer 2

我已经使用过类似的步骤来保持开发、测试和QA数据库每晚“归零”，以供开发人员和QA专业人员使用。

文档是关键，如果你想消除Scott Hanselman所说的“公交因素”（即系统创建者可能会遭遇意外事故，导致一切开始失控）的危险。

话虽如此，对于普通数据库备份和灾难恢复计划，我发现SQL Server维护计划运行得相当不错。只要包括： 1）合理的文档 2）常规测试。

我概述了一些实现这一目标的方法（任何寻找创建灾难恢复计划示例的人都可以参考）：
SQL Server备份最佳实践（免费教程/视频）

- Michael K Campbell

Answer 3

我正在做完全相同的事情，即使使用该过程，也经常会遇到各种问题。

您如何处理从服务器A复制文件到服务器B并在服务器B上恢复事务备份之间的间距？

偶尔事务备份比正常大，并需要更长时间进行复制。然后还原作业会出现操作系统错误，表示该文件正在使用中。

这并不是什么大问题，因为文件会自动在下一次应用，但通常最好有一个更优雅的解决方案，特别是可以解决此问题。

- YonahW