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