SQL Server 上的大型数据库或数据库集合的备份和恢复过程对于灾难和恢复目的非常重要。然而，我还没有找到一个强大的解决方案来保证整个过程尽可能高效、100%可靠、易于维护和跨多个服务器进行配置。
微软的维护计划似乎还不够。我使用过的最佳解决方案是我使用许多作业手动创建的解决方案，其中每个数据库在源服务器（备份）和目标服务器（恢复）上运行许多步骤。这些作业使用存储过程来进行备份、复制和恢复。它每天运行一次（完整备份/恢复），日内每 5 分钟运行一次（事务日志传送）。
尽管我当前的流程可以正常工作并通过电子邮件报告任何作业失败，但我知道整个流程不是很可靠，并且在不深入了解该流程的情况下，非 DBA 无法在我们所有的服务器上轻松维护/配置。
我想知道其他人是否有相同的备份/恢复过程以及其他人如何克服这个问题。
我使用了类似的步骤来让开发/测试/QA 数据库每晚保持“零步长”，供开发人员和 QA 人员使用。
文档是关键——如果你想消除 Scott Hanselman 所说的“总线因素”（即系统的创建者被总线撞到并且一切都开始糟糕的危险）。
也就是说，对于正常的数据库备份和灾难恢复计划，我发现 SQL Server 维护计划效果非常好。只要你包括：
1) 体面的文档
2）日常测试。
我概述了一些这样做的方法（对于任何对此问题感兴趣并寻找如何创建灾难恢复计划的示例的人）：
SQL Server 备份最佳实践（免费教程/视频） http://www.sqlservervideos.com/sqlserver-backups/sqlbackup-best-practices
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
