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