数据库备份/恢复过程

Question

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

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

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

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

Answer 1

我已经使用了类似的步骤来让开发人员和QA人员每晚保持dev / test / QA数据库“零步”。

文档是关键 - 如果你想删除Scott Hanselman所说的'总线因素'（即系统的创建者会被公共汽车撞到并且一切都开始变坏的危险）。

也就是说，对于正常的数据库备份和灾难恢复计划，我发现SQL Server维护计划运行良好。只要你包括： 1）体面的文件 2）常规测试。

我已经概述了一些实现这一目标的方法（针对这个问题的任何人寻找如何创建灾难恢复计划的示例）：
SQL Server Backup Best Practices (Free Tutorial/Video)

Answer 2

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

正因为如此，你想要看看Mitch Wheat提到的第三方解决方案。我为Quest（LiteSpeed的制造商）工作，所以我当然偏爱那个 - 很容易向非DBA展示。在我离开上一家公司之前，我有一个十分钟的会话来向系统管理员和开发人员展示LiteSpeed控制台是如何工作的，就是这样。从那时起他们就没有打过电话。

另一种方法是使用与您店铺其余部分相同的备份软件。 TSM，Veritas，Backup Exec和Microsoft DPM都具有SQL Server代理，可让您的Windows管理员以不同程度的易用性管理备份过程。如果你真的想要一个非DBA来管理它，这可能是最简单的方法，尽管你牺牲了SQL专用备份工具给你的很多性能。

Answer 3

我正在做同样的事情，并且即使在这个过程中也经常半问题。

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

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

这不是什么大问题，因为文件会在下次自动应用，但是通常会有一个更优雅的解决方案，并且能够明确解决这个问题。