Paul Randal提出了一些有关SharePoint SQL数据库最佳实践的非常好的问题。今天,在帮助客户维护SharePoint安装的同时,他问我一个有关SharePoint数据库最佳SQL恢复模型的问题。
这是我的实践(我不是数据库管理员:))))使用简单恢复模型。如果定期备份SharePoint数据库,并且您还具有基于项目级别的第三方工具备份,则实际上不需要保存整个日志。
我在这里想念什么吗?这是正确的方法吗?您是否曾经使用SharePoint DB日志恢复数据?
Paul Randal提出了一些有关SharePoint SQL数据库最佳实践的非常好的问题。今天,在帮助客户维护SharePoint安装的同时,他问我一个有关SharePoint数据库最佳SQL恢复模型的问题。
这是我的实践(我不是数据库管理员:))))使用简单恢复模型。如果定期备份SharePoint数据库,并且您还具有基于项目级别的第三方工具备份,则实际上不需要保存整个日志。
我在这里想念什么吗?这是正确的方法吗?您是否曾经使用SharePoint DB日志恢复数据?
Answers:
这完全取决于您愿意丢失多少数据以及所需的管理工作量。如果您使用简单的恢复模型并在周日每周进行一次备份...如果您在周六11:59发生崩溃,那么您将失去一周的工作。增加备份频率(或采取差异)将减少数据丢失量。
通过执行常规的完整/差异备份,但将完整恢复模型与事务日志一起使用,您可以还原上一个备份,然后将事务日志重播到崩溃之前的某个时间点,并且几乎不会丢失任何数据。
说到保罗·兰德尔(Paul Randal),他本月刚刚在《 TechNet杂志》上就此主题撰写了一篇很棒的文章:) http://technet.microsoft.com/zh-cn/magazine/dd822915.aspx
仅备份数据库不会获得您的所有共享点信息。当然它将获取数据库中的所有内容,但是所有自定义项和外观都将丢失。作为管理员,这对您而言并不重要,但我向您保证,您的用户将不满意。
选项包括获取可以读取备份软件共享点数据库的备份代理,或执行一些脚本备份来获取配置信息,并将其以及SQL数据库备份放在安全的地方。
http://technet.microsoft.com/zh-cn/library/cc288330.aspx包含 一些信息。
测试您的备份。恢复它们。看看有什么变化,什么有效,什么无效。我们的第一次还原不如预期的好。对我们来说幸运的是,这只是制作与生产服务器重复的测试服务器的过程的一部分,而不是尝试恢复丢失或破坏的数据。
编辑的相关性 在再次阅读本文时,我意识到我分心了并且错过了答案的答案。如果使用事务日志记录进行完整备份,则可以回滚到更精细的时间点。作为DBA,这确实需要更多技能,但并不难。如果您没有大量更新,而整天丢失的工作并不是世界末日,那么您可能还不错。其他选项包括更频繁地运行简单备份。说午夜,上午10点,下午2点,下午6点,或适用于组织工作周期的任何方法。这样会消耗更多的磁盘,但会降低数据丢失的风险。与所有备份一样,用户可以容忍的内容与管理员可以提供的内容之间是一个平衡。
Sharepoint必须被视为SQL数据库,因为它是一个SQL数据库,因此在建立车间时要采取所有常规的SQL设置预防措施。至于备份,您不仅应该定期备份数据库,还需要备份保存所有SP信息的12个配置单元。
请查看此线程以获取更多信息:http : //social.technet.microsoft.com/Forums/zh-CN/sharepointgeneral/thread/102c5c71-38a3-4360-b5cb-9b8b7c07bfea