数据库备份/恢复过程

Question

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

Microsft的维护计划似乎还不够。我使用的最佳解决方案是我手动创建的解决方案，它使用许多作业，每个数据库在源服务器(备份)和目标服务器(还原)上运行许多步骤。这些作业使用存储过程来执行备份、复制和恢复。它每天运行一次(完整备份/恢复)，每5分钟运行一次(事务日志传送)。

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

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

Answer 1

我使用了类似的步骤来保持dev/test/QA数据库每晚‘零步长’，供开发人员和QA人员使用。

文档是关键--如果你想去除Scott Hanselman所说的“总线因素”(即系统的创建者会被总线撞到，一切都开始变得糟糕的危险)。

也就是说，对于正常的数据库备份和灾难恢复计划，我发现SQL Server维护计划效果很好。只要你包括: 1)像样的文档2)例程测试。

我已经概述了一些这样做的方法(对于任何想要了解如何创建灾难恢复计划的人来说)：

SQL Server Backup Best Practices (Free Tutorial/Video)

Answer 2

您问题的关键部分是备份解决方案是否能够由非DBA管理。任何本机SQL Server解决方案(如备份脚本)都无法满足这一需求，因为备份脚本需要T-SQL知识。

正因为如此，你需要寻找第三方解决方案，比如米奇小麦提到的解决方案。我为Quest (LiteSpeed的制作人)工作，所以我当然更喜欢它--它很容易展示给非DBA。在我离开上一家公司之前，我花了十分钟的时间向系统管理员和开发人员展示了LiteSpeed控制台的工作原理，仅此而已。从那以后他们再也没打过电话。

另一种方法是使用与其他商店相同的备份软件。TSM、Veritas、Backup Exec和Microsoft DPM都具有SQL Server代理，使Windows管理员能够以不同程度的易用性来管理备份过程。如果您真的希望非DBA来管理它，这可能是最简单的方法，尽管您牺牲了特定于SQL的备份工具为您提供的大量性能。

Answer 3

我正在做完全相同的事情，甚至在这个过程中也会半定期地遇到各种问题。

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

每隔一段时间，事务备份就会比正常情况下更大，并且需要更长的时间进行复制。然后，还原作业会收到操作系统错误，指出该文件正在使用中。

这不是什么大问题，因为文件会在下一次自动应用，不过，一般来说，最好有一个更优雅的解决方案，并专门修复这个问题。