大型数据库或 sql server 上的数据库集合的备份和恢复过程对于灾难和恢复目的非常重要。但是，我还没有找到一个健壮的解决方案来保证整个过程尽可能高效、100% 可靠、易于维护和跨多台服务器进行配置。
Microsft 的维护计划似乎还不够。我使用过的最好的解决方案是我使用许多作业手动创建的，每个数据库在源服务器（备份）和目标服务器（恢复）上运行有许多步骤。这些作业使用存储过程来进行备份、复制和恢复。这每天运行一次（完全备份/恢复），每 5 分钟运行一次（事务日志传送）。
尽管我当前的流程可以正常工作并通过电子邮件报告任何作业失败，但我知道整个流程不是很可靠，并且如果不深入了解流程，非 DBA 无法在我们所有的服务器上轻松维护/配置。
我想知道其他人是否有相同的备份/恢复过程以及其他人如何克服这个问题。
我已经使用了类似的步骤来让开发/测试/QA 数据库每晚都保持“零步”，以供开发人员和 QA 人员使用。
文档是关键——如果你想消除 Scott Hanselman 所说的“总线因素”（即系统的创建者会被总线击中并且一切都开始糟糕的危险）。
也就是说，对于正常的数据库备份和灾难恢复计划，我发现 SQL Server 维护计划运行良好。只要您包括： 1) 体面的文档 2) 例行测试。
我已经概述了一些方法来做到这一点（对于任何被这个问题吸引来寻找如何创建灾难恢复计划的例子的人）：
SQL Server Backup Best Practices（免费教程/视频）
您问题的关键部分是由非 DBA 管理备份解决方案的能力。任何本机 SQL Server 答案（如备份脚本）都无法满足该需求，因为备份脚本需要 T-SQL 知识。
正因为如此，您想要寻找像 Mitch Wheat 提到的第三方解决方案。我为 Quest（LiteSpeed 的制造商）工作，所以我当然偏爱那个——它很容易向非 DBA 展示。在我离开上一家公司之前，我进行了十分钟的会议，向系统管理员和开发人员展示 LiteSpeed 控制台的工作原理，仅此而已。从那以后他们就没有打电话了。
另一种方法是使用与您商店的其他部分相同的备份软件。TSM、Veritas、Backup Exec 和 Microsoft DPM 都具有 SQL Server 代理，可让您的 Windows 管理员以不同程度的易用性管理备份过程。如果您真的希望非 DBA 来管理它，这可能是最简单的方法，尽管您牺牲了 SQL 特定备份工具为您提供的大量性能。
即使在这个过程中，我也正在做同样的事情并且半定期地遇到各种问题。
您如何处理将文件从服务器 A 复制到服务器 B 和在服务器 B 上恢复事务备份之间的间隔。
每隔一段时间，事务备份就会比正常情况大，并且需要更长的时间来复制。然后，还原作业会收到一个操作系统错误，表明该文件正在使用中。
这没什么大不了的，因为该文件会在下次自动应用，但是通常有一个更优雅的解决方案并且专门解决这个问题会更好。