只是想知道你们有什么备份过程。
我目前正在运行每周完整数据库备份和每日差异备份。
我的理解是，通过这样的设置，完全恢复模式和简单恢复模式的区别在于，在完全恢复模式下，我将能够使用事务日志将我的数据库回滚到特定的时间点，差异备份。
假设在我的场景中，最后一个差异备份是我最后一个也是最终的“保存点”，我没有看到需要使用日志回滚我的数据库。 这使我想到我的问题：对于我当前的备份过程，是否有任何额外的好处可以使用完全恢复模式？
那么，如果你不保存日志，你可以做的最好的是回滚到最后的差异。
我通常做的是以更短的时间间隔备份交易日志（可能每15分钟左右）。 这可以防止我在最坏的情况下（机器烧到地面）丢失大量的数据。 这是一个非常轻量级的操作，所以可以在线完成，影响最小。
您通常应该只使用完全备份模式，而且您应该经常备份您的事务日志，除非您承受了一整天的数据损失，这是您现在接触到的数据。
确定备份策略时通常考虑两个因素。 还原点目标（RPO）和还原时间目标（RTO）。
恢复时间目标
我不会介绍RTO，因为这是在数据库镜像/集群中进行备份等。但要记住，在发生故障后服务器重新联机需要多长时间，例如将磁带返回到现场，新的服务器，重build服务器等。RPO和RTO是两个数字，你应该回报业务，你应该testing他们reguraly。
还原点目标
还原点目标是您想要将数据库恢复到的时间点。
全对V简单
如果您需要恢复到特定时间点，则需要转到完整恢复模式和事务日志备份。 否则，您将只能恢复到上次完全备份或差异备份的时间点。
尽pipe大多数企业认为每晚或4小时的数据丢失是可以接受的。 当你处于这种情况时，它总是不是。 所以我总是用事务日志备份来完全恢复。
满血复活
作为一般规则，我在大部分数据库上进行夜间完整备份。 我也每隔4小时就做一次差距，每15分钟做一次事务日志。 如果您的差异备份大小开始超过您的完整备份大小。 现在是做更频繁的完整备份的时候了。
如果您的差异备份大小开始超过完整的备份大小。 现在是时候做一个完整的备份，因为在恢复速度方面你正在失去差异备份的好处。
最大的问题将是完全恢复是你必须始终有最后一个完整的备份在设置能够恢复。 如果有人对数据库进行了手动备份，并且不保留备份，他们将破坏您的设置，如果没有备份，您将无法恢复。 （仅使用备份副本）
另外，如果您正在进行完全恢复，则会使您正在执行事务日志备份，否则您的日志文件将变得难以pipe理。
恢复
要以完全恢复模式恢复，您需要。 最近的完整备份离您的还原点最近，然后是最接近的差异备份，那么您需要前滚每个事务日志以达到您所需的时间点。
恢复过程要困难得多，但明确值得。 正如您可以恢复到开发人员将删除全部发送到数据库的确切时间点。
所以要回答这个问题，完全恢复是值得的额外的工作，因为你会很感激能够恢复到各种情况的时间点。 特别是当你在一个月之前有一个重大的失败结束财务处理。
数据库的大小在差异备份和事务日志备份中起着很大的作用。 在非常大的数据库上，执行差异备份或完全备份所需的时间将超过数据库需要备份的频率。 例如，在很多地方，我看到了夜间差分，每小时事务日志和每周完整备份的组合。
能够恢复到某个时间点或检查点是事务日志备份有用的另一个原因。 如果我没有记错，这个function对于差异备份是不可用的。
在一个小型的数据库上，差异对比事务日志数据库的时间可能不太重要，这可能就是为什么你没有看到这个额外的价值。 您也可以有更简单的维护要求。
有关此方面的专家信息，请查看Paul Randal博客上关于备份和事务日志的所有信息。 每一种情况都不一样，只有你才能决定你需要什么。 教育自己，然后去与你需要的数据恢复的工作和多less数据丢失是可以接受的。
在例如configuration数据（即没有用户数据，只有configuration设置）的情况下，您可以使用简单的备份去除事务日志的需要。