首页 > 代码库 > 选择哪种方式进行SharePoint的备份
选择哪种方式进行SharePoint的备份
关于SharePoint的备份还原功能,大家可能都有所了解。但是SharePoint一共有多少种备份方式呢,哪种备份方式是更适合你的呢,本文主要为大家梳理,并且深入的研究一下常见的几种备份方式,以便大家能有所了解,以及了解使用场合。
SharePoint提供了哪些级别的备份
- Web级别的备份
- SiteCollection级别的备份
- 数据库级别的备份
Web级别的备份
对于Web级别的备份,我们常用的命令行是:
我们下面主要反编译一下,看看他这个方式是如何实现的,过程省略,直接找到备份的核心类:
看到这几个类图相比大家已经心里了解到,SharePoint分别对站点中上面的内容进行序列化,并且存储的,序列化的过程是什么样的呢?这里简单以Web为例:
这里基本能看到,SharePoint是通过API取属性的方式把站点集里面的内容按照功能一步一步的进行序列化的,因此备份还原都是通过API来进行的,这个例子也证明了SharePoint API本身的强大。
具体里面的实现内容不再赘述,大家可以自己了解一下。到了这里我们大体可以总结一下,Web级别备份的特点:
- 基于SharePointAPI 进行的
- 备份的顺序按照结构及其功能
- 还原也是通过SharePoint API进行的,因此如果使用这种备份数据进行还原,Id等表示不会重复。
SiteCollection级别的备份
对于SiteCollection级别的备份,我们常用的命令行是:
同样的过程,我们反编译代码,看一下这个命令行的实现:
红线中标识的,看起来和ContentDatabase 有关吧,再看一下核心的方式 manager.Serialize方法。
红线中标识的关键字已经很明显的告诉了我们,SharePoint是通过对ContentDatabase里面的每一张表进行序列化,然后保存到本地了。
因此到这里,我们可以简单的归纳一下SiteCollection级别备份的特点:
- 基于SiteCollection级别进行的,不能细化
- 备份过程是按照数据库中表的顺序的
- 这种方式决定了还原之后,某些Id会重复,但是实际测试结果发现SiteCollectionId不会重复
数据库级别的备份
这个就无需赘述了,他的特点是:
- 基于Database级别的,不能细化
- 备份过程中按照数据块进行,或者快照
- 这种方式还原之后,Id,主键等信息和备份时完全一样
如何选择我们要使用哪种备份方式呢?
下面的列表可以帮助大家选择
内容的重复性(和备份数据进行比较):
SiteCollectionId | WebId | DocumentId | |
Web级别 | 不相同 | 不相同 | 不相同 |
SiteCollection级别 | 不相同 | 相同 | 相同 |
数据库级别 | 相同 | 相同 | 相同 |
这个列表已经列出了数据重复性,因此在使用时,我们需要考虑一下几点:
- 同一个SPFarm中,不可以有两个Id相同的SPSite,因此数据库级别的备份,备份还原数据在同一个SPFarm中是不兼容的
- 同一个SPContentDatabase中,不能有相同的WebId,因此SiteCollection级别的备份,备份还原数据再同一个SPContentDatabase中是不兼容的
- Web级别的备份没有以上两个问题
效率对比:
理论速度 | |
Web级别 | 最慢 |
SiteCollection级别 | 中等 |
数据库级别 | 快 |
效率对比,相信大家也可以理解,是用SharePointAPI的备份效率<按照Table进行备份<通过SQL进行快照备份。
因此通过比较,大家可以清晰的看出,每种备份方式的优缺点,及其效率。由于SharePoint不止提供很多接口进行了备份还原,甚至有很多第三方软件也支持了SharePoint的备份还原,但万变不离其宗,基本思路主要就是这3种,当你了解了你使用的是哪种备份方式,就可以了解到他的效率,以及可能带来的问题了。
选择哪种方式进行SharePoint的备份