Paul Randal问了一些有关SharePoint SQL数据库最佳实践的非常好的问题。 今天，在帮助客户维护SharePoint安装的同时，他问我一个关于SharePoint数据库的最佳SQL恢复模型的问题。
这是我的做法（我不是DBpipe理员:)）））使用简单的恢复模式。 如果定期备份SharePoint数据库，并且在项目级别还有第三方工具备份，则实际上不需要保留整个日志。
我在这里错过了什么？ 这是正确的方法吗？ 你有没有使用SharePoint数据库日志来恢复您的数据？
这完全取决于您愿意丢失多less数据与所需的pipe理工作量。 如果您正在使用简单恢复模式，并在星期天每周进行一次备份……如果您在星期六的11:59发生崩溃，那么您已经失去了一周的工作时间。 增加备份频率（或差异化）将减less数据丢失的数量。
通过定期进行全面/差异备份，但将完整恢复模式与事务日志一起使用，您可以恢复上次备份，然后在发生崩溃之前立即将事务日志重播到某个时间点，并且几乎不会丢失任何数据。
说到保罗·兰德尔（Paul Randal），他刚刚为本月的TechNet杂志撰写了一篇精彩的文章： http : //technet.microsoft.com/en-us/magazine/dd822915.aspx
只备份数据库不会得到所有的分享点信息。 当然，它会得到数据库中的所有内容，但是所有的定制和外观都会丢失。 这对你来说可能并不重要，但我向你保证你的用户会不高兴。
选项包括获取可以读取备份软件的SharePoint数据库的备份代理，或者执行一些脚本备份来获取configuration信息，并将其和SQL数据库备份安全地放在一起。
http://technet.microsoft.com/en-us/library/cc288330.aspx有一些信息。
testing你的备份。 还原它们。 看看有什么变化，什么不变。 我们的第一次恢复并不像以前那样好。 对我们来说幸运的是，它只是制作一个与我们的生产服务器相同的testing服务器的过程的一部分，而不是试图恢复丢失或毁坏的数据。
编辑的相关性再次阅读这一点，我意识到我分心，错过了我的答案的答案点。 如果使用事务日志logging进行完整备份，则可以回滚到更精细的时间点。 这确实需要更多的技能作为DBA，但并不难。 如果你没有大量的更新，失去一整天的工作不是世界的尽头，那么你可能没有问题。 其他选项包括更频繁地运行简单备份。 说午夜，上午10点，下午2点，下午6点，或任何工作组织工作周期。 这会吃掉更多的磁盘，但减less数据丢失的风险。 与所有备份一样，在用户可以容忍的和pipe理员可以提供的内容之间取得平衡。
Sharepoint需要像SQL数据库一样对待，因为它是一个SQL数据库，所以在build立商店时要采取所有常规的SQL设置预防措施。 至于备份，您不仅需要定期备份数据库，还需要备份包含所有SP信息的12-hive。
看看这个线程的更多信息： http : //social.technet.microsoft.com/Forums/en-US/sharepointgeneral/thread/102c5c71-38a3-4360-b5cb-9b8b7c07bfea
有一些数据库设置为简单模式。 search数据库，例如。 search数据存储在两个位置：数据库和服务器文件系统上的索引文件。 您需要同时提供search查询，并且同时备份所有恢复的版本。 由于这种可能性非常低，大多数人会select简单地重新抓取内容并重新生成search索引。
在这种情况下，简单模式将工作得很好。