编者注:备份是为了增强企业关键数据可靠性和数据冗余性,备份的必要性不言而喻。今天我们来探讨下备份常用的技术和分类。开始内容之前,先介绍下整理的备份专题总结:<数据备份和副本管理技术>(目录如下)。
第1章 数据备份技术的发展 6
1.1 备份技术发展介绍 6
1.1.1 Host备份方式 6
1.1.2 LAN备份方式 6
1.1.3 LAN-free备份方式 7
1.1.4 Server-free备份方式 8
1.1.5 Server-less备份方式 8
1.2 主流备份软件介绍 9
1.2.1 EMC备份软件 10
1.2.2 CommVault备份软件 12
1.2.3 Symantec备份软件 13
1.2.4 IBM备份软件 15
1.3 备份软件功能分析 16
1.3.1 备份归档功能 16
1.3.2 数据重删 17
1.3.3 NDMP备份 17
1.3.4 兼容性和易维护性 17
1.3.5 NAS备份和NDMP技术 17
1.3.6 传统NAS备份如何实现 17
1.3.7 NDMP具体实现 18
第2章 CV SimPana 11特性解读 22
2.1 一体化数据管理平台 22
2.2 海量文件管理流程 24
2.3 文件系统块级备份 25
2.4 全方位支持虚拟机保护 26
2.5 Live系列特性 27
2.6 云备份和恢复 29
第3章 备份软件体系架构解析 31
3.1 备份技术概述 32
3.2 备份软件架构 32
3.3 多备份域管理 34
3.4 数据归档和恢复 36
3.5 备份和归档的区别 39
第4章 备份软件分布式索引架构 39
4.1 备份和恢复对索引操作 42
4.2 数据索引的维护 44
第5章 备份软件关键特性 44
5.1 SimPana重删压缩原理 45
5.2 介质服务器并行重删 46
5.3 数据复制功能 47
5.4 硬件快照IntelliSnap 48
5.5 AnyBackup重删原理 50
5.6 AnyBackup远程复制技术 51
5.7 AnyBackup虚拟机即时恢复 51
第6章 备份软件方案可靠性解析 52
6.1 备份介质可靠性 53
6.2 介质服务器可靠性 54
6.3 备份管理服务器可靠性 55
6.3.1 冷备份方案 55
6.3.2 高可用方案 56
第7章 虚拟机备份原理解析 58
7.1 VMware备份接口和原理 58
7.2 Hyper-V备份接口和原理 63
7.3 Citrix备份接口和原理 65
第8章 数据重删在备份场景应用 67
8.1 重删在备份设备上的实现 67
8.2 重删在备份软件上的实现 68
第9章 备份存储配置原理和实践 69
9.1 备份策略设计方法 70
9.2 容量计算方法 70
9.3 性能计算方法 72
第10章 SnapVault和SnapDiff技术 73
10.1 SnapDiff技术分析 74
10.2 SnapVault技术分析 76
10.3 Open Systems SnapVault技术 77
第11章 无代理备份技术分析 78
11.1 虚拟环境下无代理备份 78
11.2 物理环境下无代理备份 79
第12章 数据持续保护(CDP)技术分析 82
12.1 基准参考数据模式 84
12.2 复制参考数据模式 85
12.3 合成参考数据模式 85
12.4 基于应用实现持续数据保护 85
12.5 基于文件实现持续数据保护 85
12.6 基于数据块实现持续数据保护 86
12.7 EMC RecoverPoint解决方案 86
12.7.1 RecoverPoint CDP 86
12.7.2 RecoverPoint CRR 87
12.7.3 RecoverPoint CLR 87
12.7.4 RecoverPoint原理分析 87
12.7.5 数据库一致性保证 89
12.8 飞康CDP解决方案 89
12.8.1 Side-Band旁路方式 91
12.8.2 远程Filesafe/Disksafe方式 91
12.8.3 In-Band带内方式 91
12.8.4 SANTap数据分流方式 92
12.8.5 多时间点自动连续快照技术 92
12.8.6 数据库一致性确认技术 92
12.8.7 磁盘读/写优化技术 93
第13章 CDM技术和产品分析 93
13.1 CDM技术背景 93
13.2 CDM技术架构 94
13.3 EMC iCDM 95
13.4 Cohesity技术 96
13.5 鼎甲InfoSemper 97
第14章 备份方案实践和趋势 97
14.1 eBackup备份软件 97
14.2 SimPana虚拟机备份 99
14.3 超融合一体机备份 100
14.4 Asigra云备份方案 100
感兴趣的读者,可通过文末“阅读原文”获取详情。下面开始今天正式内容。
所谓数据保护技术是指对当前时间点上的数据进行备份,如果说原始数据被误删除了,可以通过备份数据找回或恢复数据。从底层来分,数据保护可以分为文件级保护和块级保护。
文件级备份:将磁盘上所有文件通过调用文件系统接口备份到另一个介质上。也就是把数据以文件形式读出,然后存储在另一个介质上面。此时备份软件只能感知到文件这一层。
我们知道一般来说,文件在原来的介质上,可以是不连续存放的,通过文件系统来管理和访问。当备份到新的介质上以后,文件完全可以连续存放。正因为如此,没有必要备份元数据,因为利用新介质进行恢复的时候,反正会重构文件系统。
块级备份:就是不管块上是否有数据,不考虑文件系统的逻辑,备份块设备上的每个块。
这样好处是不通过调用文件系统接口,速度更快,缺点的是备份的时候会把所有的块复制一遍,但是实际上很多扇区的数据是不对应真实文件的,也就是会备份很多僵尸扇区。而且备份之后,原来不连续的文件一样是不连续的文件,有很多的碎片。
远程文件复制:通过网络传输到异地容灾点。典型的代表是rsync异步远程文件同步软件。可以监视文件系统的动作,将文件的变化,同步到异地站点。增量复制。
这是基于块的远程备份。与远程文件复制
不同的地方在于,是把块数据备份到异地站点。又可以分为同步和异步复制。
同步复制:必须等数据复制到异地站点以后,才通报上层IO成功消息
异步复制:写入成功即可回复成功,然后通过网络传输到异地。不能保证一致性,但是上层响应快。
基于块的备份措施,一般都是在底层设备上进行,不耗费主机资源。
远程镜像确实是对生产数据一种非常好的保护,但是需要镜像卷一直在线,主卷有写IO,那么镜像卷也需要有写IO。
如果想对镜像卷进行备份,需要将停止主卷的读写,然后将两个卷的镜像关系分离。所以当恢复主卷的IO的时候,镜像卷不会再被读写。然后才可以备份镜像卷的数据。
这样会存在一个问题,主卷上还继续有IO,将会导致数据与备份的镜像不一致。所以主卷上所有的写IO动作,会以位图BitMap方式记录下来,BitMap上的每个位表示卷上的一个块,0表示未写入,1表示已写入,所以当拆分镜像以后,被写入了数据,程序将BitMap文件对应位从0变为1。备份完成以后,再做数据同步即可。
可以看出上述过程比较的繁琐,而且需要占用一块和主卷一样大小的镜像卷。
快照技术就是为了解决这种问题,其基本思想是抓取某一时间点磁盘卷上的所有数据。
快照分为:基于文件系统的快照和基于物理卷的快照,下面介绍一下快照的底层原理。
文件系统管理的精髓:链表、B树、位图,也就是元数据。
文件系统
将扇区组合成更大的逻辑块来降低管理规模。NTFS最大块可以到4KB,也就是8个扇区一组一个簇(Block),这样可以减少管理成本。
文件系统会创建所管理存储空间上所有簇的位图文件。每个位代表卷上的簇(或者物理扇区)是否被使用,如果被使用,则置1。
文件系统保存一份文件和其对应簇号的映射链。因为映射链本身和簇位图也是文件,也有自己的映射链,所以针对重要的元数据,有一个固定的入口: root inode。
写入新数据
查找簇位图,找位值为0的簇号
计算所需空间, 分配簇号给文件
将数据写入簇,再去文件——簇号映射图
更新
将对应的簇映射关系记录下来,到簇位图将对应位置改为1。
删除数据
直接在簇号映射链中抹掉
簇位图对应簇改为0。
可以看出删除数据实际上不会抹掉实际的数据。所以,最重要的不是数据,而是文件——簇号映射链和位图
等元数据。
也就是说我们要做备份,只需要把某时刻的文件系统中的映射图表保存下来。但是必须保证卷上的数据不被IO写入了,同时又要不应用还不能中断。既然原来的空间不能再写了,我们可以写到其他的空闲区域。
思路一:Copy on First Write (CoFW),在覆盖数据块之前,需要将被覆盖的数据块内容复制出来,放到空闲的空间。
系统中将有两套元数据链,原来的元数据指向当前,快照的元数据链指向历史。原来的存储空间永远是最新的数据,历史数据会逐渐搬出到空闲空间里面。
思路二:Redirect on First Write (RoFW)。先复制元数据,然后将针对源文件的更改都重定向到空余空间,同时更新元数据。
与CoFW
不同的是,原来的数据块不会被覆盖。同样的,系统也有两套元数据,一套是快照保存下来的,永远不更新,一套是源文件系统的,不断的更新。
其实只有首次覆盖的时候,才重定向,因为重定向以后的数据块,哪怕被覆盖了,也不影响之前快照保存的数据了。
到这一步,看上去挺完美,实际上存在一个问题: 如果元数据
特别大怎么办?对于海量庞大的文件系统,元数据量可能到GB级别。如果复制的话,时间上仍然太多。
我们可以回头想想,实际上元数据可以看做指针,指向具体存储的位置。我们复制到元数据,相当于复制了一堆指针。现在元数据太多了,我们能不能把这个元数据链的指针给复制了?当然可以,元数据有个根入口块
,或者称为Super Block,这个块是固定不变的,里面存放有指向下一级元数据链块的指针。
那么操作系统每次载入元数据的时候,都需要从这个地址读入Super Block,从而一层一层的遍历。
基于物理卷的快照比文件系统快照要简单得多。因为LUN一般在底层磁盘上是恒定的,不像文件系统一样可以随机细粒度的分布。所以可以认为LUN的元数据就是在底层磁盘的起始和结束地址。这样在快照的时候,需要复制的元数据就更少了,但是完成了以后,需要按照一定粒度来做CoFW或者RoFW,还需要记录更多数据映射指针,就比较难受了。
对于实现了块级虚拟化的系统如NetApp、XIV、3PAR等,它们的LUN在底层位置是不固定的,LUN就相当于一个文件,存在元数据链来进行映射管理的维护,所以这些系统实现快照的原理与文件系统快照类似。
基于物理卷的快照,相当于给物理卷增加了“卷扇区映射管理系统”。在底层卷实现快照,可以减轻文件系统的负担。
卷扇区方都是用LBA来编号的,实现快照的时候,程序首先保留一张初始LBA表,每当有新的写入请求的时候,重定向到另一个地方,并在初始的LBA表中做好记录,比如:
原始LBA:卷A的10000号,映射到LBA:卷B的100号。
值得说明的是,文件系统无法感知重定向,文件系统在它的映射图里面还是记录了原始的LBA地址。此时如果来了新的写IO,有两种方式一种是Write Redirect,另外一种是Copy on Write。
所谓Write Redirect就是将文件系统的读写请求,重定向到卷B,这样每次IO其实都会查找快照映射表,降低了性能。所以引入了Copy on Write。
所谓Copy on write,就是当写请求来的时候,先把原来的扇区的数据复制一份到空闲卷,然后将新数据写入原卷。不过这种复制操作只发生在原卷某个或者快照之后从未更新过的块上面,若是某个块在快照之后更新过了,说明之前的数据已经转移走了,可以放心的覆盖。
所以Copy on Write实际上是让旧数据先占着位置,等新数据来了以后先把原来的数据复制走,再更新,而且一旦更新了一次,可以直接覆盖。
带来的好处是 ,原卷上的数据随时是最新的状态,每个IO可以直接访问原卷的地址,而不需要遍历映射表。
不管是RoFW还是CoFW,只要上层向快照后没有更新过的数据块进行写,都需要占用一个新的块。所以如果将所有扇区块都更新了,新卷的容量和原来的容量应该一样大,但是通常不会覆盖百分之百,所以只要预设原容量的30%即可。
IO资源消耗:
CoFW方式下,如果要更新一个从未更新的块,需要复制出来,写到新卷,然后覆盖原来的块,需要一次读,2写。
RoFW方式下,只需要一次写即可,也就是直接重定向到新卷上,然后更新映射图中的指(在内存中进行)。
所以RoFW相对CoFW方式在IO资源消耗与IO延迟上有优势。
由于只有首次覆盖才会Copy或者Redirect,那么如何区分是否是首次覆盖呢?可以使用记录表(文件级快照)或者位图(卷快照)来记录每个块是否被覆盖过。
对于读IO:
CoFW:因为总是更新的源卷,所以源卷总是代表最新的状态,所以任何读IO都会发到源来执行。
RoFW:需要首先查询位图来确定目标地址是否被处理过,如果是,则转向重定向后的地址。
RoFW会影响读性能,因为重定向出去以后,数据块排布都是乱的,如果把快照删除后,不好清理战场,严重影响后续的读写性能。
综合来说,RoFW比较吃计算资源,而CoFW比较耗费IO资源。我们知道其实一般来说读比写多,当覆盖第二次以后:
CoFW不会发生IO惩罚,读IO一直没有惩罚
对于RoFW,就算完全被Redirect过了,对于读或者写IO,均需要遍历位图,永远无法摆脱对计算资源的消耗。
尤其在LUN卷级快照下,原本卷在底层磁盘分布式是定死的,寻址非常迅速。但是RoFW引入了,LUN的块随机定向到其他的空间的,所以需要记录新的指针链,而且被写出的块不是连续排列的。对性能影响非常明显的。
绝大多数的厂商使用的还是CoFW,但是一些本来就使用LUN随机分块分布模式的存储系统比如XIV、NetApp等,都使用RoFW,因为原本其LUN的元数据链就很复杂,而且原来就是随机分布的,RoFW的后遗症对它们反而是正常的。
快照所保存下来的卷数据,相当于一次意外掉电之后卷上的数据。怎么理解?
上层应用和文件系统都有缓存,文件系统缓存的是文件系统的元数据和文件的实体数据。每隔一段时间(Linux一般是30s)批量Flush到磁盘上。而且不是只做一次IO,有可能会对磁盘做多次IO。如果快照生成的时间恰恰在这连续的IO之间,那么此时卷上的数据实际上有可能不一致。
文件系统的机制是先写入数据到磁盘,元数据保存在缓存里面,最后再写元数据。因为如果先写元数据,突然断电了,那么元数据对应的僵尸扇区的数据会被认为是文件的,显然后果不堪设想。
总之,快照极可能生成不一致的数据。
那么为什么还要用快照呢?
因为快照可以任意生成,而且占用的空间又不大,更重要的是可以在线恢复,不用停机只需要在内存中做IO重定向,那么上层访问就变成以前时间点的数据了。
但是快照会存在不一致的问题,如何解决?既然快照无异于一次磁盘掉电,那么利用快照恢复数据之后,文件系统可以进行一致性检查,数据库也会利用日志来使数据文件处于一致。
另外,现在主流的快照解决方案是在主机上安装一个代理
,执行快照前,先通知文件系统将缓存中的数据全部Flush到磁盘,然后立即生成快照。
快照还可以预防数据逻辑损坏,也就是比如T1时刻,做了快照,T2时刻,因为管理员操作不当,误删了一个文件,T3的时候,进行了全备份操作。此时,这个文件看似永久丢失了,其实,此时还可以通过快照恢复这个文件。
快照还可以降低一致性备份的窗口。如果没有快照,要对某个卷进行一致性备份,需要暂停写IO,所以备份窗口
比较长,需要等待备份停止以后才能继续写IO。使用快照的话,只需要复制元数据,然后在后台进行备份,降低了影响。
备份完毕以后,如何能检测数据是否是真一致的?若没有快照,需要将备份数据恢复到独立的物理空间里面,挂载到另一台机器上。有了快照,可以将快照直接挂载到另一台主机,避免了数据物理恢复导入的过程。
快照类似于某时刻的影子,而克隆则是某时刻的实体。每时刻生成了一份可写的快照,就叫对卷某时刻的一份Clone。然后这份Clone内容每被修改的部分是与源卷共享的,所以源卷没了,则Clone就没了,所以叫虚拟
Clone。如果把数据复制出来,生成一个独立的卷,则就叫Split Clone,也就是可以得到实Clone
。
卷Clone最大的好处在于可以瞬间生成针对某个卷可写的镜像,而不管卷的数据量有多大。数据备份系统的基本要件:
备份对象:需要进行备份的备份源。
备份目的:磁盘、磁带等介质
备份通路:网络
备份执行引擎:备份软件
备份策略
下面重点介绍一下备份目的、备份通路、备份引擎等技术细节。
备份目的地
备份目的地是在本地的磁盘,则只需要将数据备份到本地磁盘的另外分区中或者目录中。这样不需要网络,缺点是对备份对象自己的性能影响大。还会对其他的IO密集型程序造成影响。
这种方式一般用于不关键的应用和非IO密集型应用。比如E-mail,对转发实时性要求不高。
备份到SAN上的磁盘,就是将需要备份的数据,从本次磁盘读入内存,再写入HBA卡缓冲区,然后再通过线缆传送到磁盘阵列上。
优点:只耗费SAN公用网络带宽,对主体影响小。
缺点:对公共网络资源和出口带宽有影响。
备份到NAS目录就是将数据备份到远程共享目录中。比如window中常用的文件夹共享。因为数据一般是通过以太网进行传递的,占用了前端的网络带宽,但是相对廉价,不需要部署SAN。
现在出现一种虚拟磁带库,即用磁盘来模拟磁带,对主机来说看到的是一台磁带库,实际上是一台磁盘阵列,主机照样使用磁带库一样来使用虚拟磁带库。要做到这点,就必须在磁盘阵列的控制器上做虚拟化操作,也就是实现协议转换器的作用。可以带来了的好处是:
速度提升
避免机械手这种复杂的机械装置
管理方便
将使用不频繁的数据移动到低速、低成本的设备上。比如只给视频应用分配20GB的空间,但是报告有500GB的空间,剩下的空间是在在磁带库上。
一线磁盘阵列
二线虚拟磁带库:近期不会被频繁调度。利用大容量SATA盘,性能适中的控制器。
带库或者光盘库:几年甚至几十年都不访问到。
数据流向:本地磁盘—>总线—>磁盘控制器—>总线—>内存—>总线—>磁盘控制器—>总线—>本地磁盘。
也即数据从本地磁盘出发,经过本地的总线 和内存,经过CPU少量控制逻辑代码之后,流回本地磁盘。
经过前端网络备份的数据流向是:本地磁盘—>总线—>磁盘控制器—>总线—>内存—>总线—>以太网卡—>网线—>以太网—>网线—>目标计算机的网卡—>总线—>内存—>总线—>目标计算机的磁盘。
数据从本地磁盘出发,流经本地总线和内存,然后流到本地网卡,通过网络传送到目标计算机磁盘。
前端网络:服务器接受客户端连接的网络,也就是服务网络,是服务器和客户端连接的必经之路。
后端网络:对客户封闭,客户的连接不用经过这个网络,用与服务器和存储、应用服务器、数据库服务器的连接。可以是SAN,以太网
通过后端网络备份的数据流向是:本地磁盘—>总线—>控制器—>总线—>内存—>总线—>后端HBA卡—>线缆—>后端交换设备—>线缆—>备份目的的后端网卡—>总线—>内存—>磁盘。
备份的时候不经过LAN,也就是不流经前端网络,也叫Frontend Free。这样的好处是不耗费前端网络的带宽,对客户终端接受服务器的数据不影响。
因为前端网络一般是是慢速网络 ,资源非常珍贵。无论是本地、还是网络,都需要待备份的服务器付出代价,即需要读取备份源数据到自身的内存,然后从内存写入备份的目的地。对主机CPU、内存都有浪费。能否不消耗服务器的性能呢?可以,使用Server Free备份。
Server Free备份的时候,数据不用流经服务器的总线和内存,消耗极少,甚至不消耗主机资源。备份源和备份目标都不会在服务器上,因为如果在服务器上,数据从磁盘读出,要流将总线,然后到内存,这就不是Server Free?那怎么做呢?
用SCSI
的扩展复制命令,将这些命令发送给支持Server Free的存储设备,然后这些设备会提取自身的数据写入备份目的设备,而不是发送给主机。
使用另一台专门做数据移动的新服务器,来代替原来服务器移动备份数据。释放运算压力很大的生产服务器。
备份引擎:决定整个数据备份系统应该怎么运作,备份那些内容,什么时候开始备份,备份时间有没有限制等的策略。
备份引擎以什么形式体现呢?当然是运行在主机上的程序,所以需要一台计算机来做引擎的执行者。
那么备份服务器的备份策略和规则,怎么传给整个数据备份系统中的服务器?通过以太网,因为以太网扩展性好,适合节点间通信。相对于以太网,SAN更适合传送大量的数据。所以常用前端网络来连接待备份的服务器和备份服务器,因为备份策略的数据包不多。
备份服务器如何与每个待备份的服务器建立通话?怎么通话?规则怎么定?需要待备份服务器上运行一个代理程序,专门解释备份服务器发来的命令,根据命令作出动作。
这个运行在待备份服务器上的程序,就叫备份代理,监听端口,接收备份服务器发来的命令。
若数据备份系统中有一台SCSI磁带机,且多台主机想备份到这台磁带机上。而SCSI磁带机只能同时接到一台主机上。
那么怎么办呢?可以引入一台专门的计算机,只能由这台计算机来操作磁带机。
需要备份的计算机通过以太网将数据发给这台掌管磁带机的计算机,然后写给磁带机。
这样磁带机成为了公用设备,而在整个系统中,只有一台计算机能掌管备份目标,它就类似于一个代理,代理其他服务器执行备份。我们把它称为介质服务器。
还有一个问题,如果有多台服务器向介质服务器发出请求,怎么办?当然需要一个协调员
,也就是备份服务器,它可以指挥安装在待备份服务器的代理,让每台服务器按照顺序有条理的使用介质服务器提供的备份介质进行备份。
差量备份:只备份从上次完全备份以来发生变化的数据。差量备份要求必须做一次完全备份,作为差量的基准点
对于数据库的备份,备份软件想知道每个数据文件的变化是不可能的,因为数据库文件内部格式非常复杂,只有自己才能分析和检测出来。所以数据库管理软件有自己的备份工具。第三方备份软件只能调用数据库软件自身提供的命令。
链接:
https://www.jianshu.com/p/b14ece444676
来源:简书,编译:架构师技术联盟
版权由原作者所有,转载请注明来源和出处
推荐阅读:
实现超级计算机系统,通过堆CPU就行吗?
多活分布式数据中心如何实现DNS域名解析和负载均衡?
SCM和NVM是什么鬼,与NVMe是什么关系?
温馨提示:
请识别二维码关注公众号,点击原文链接获取“数据备份和副本管理技术”电子书资料详情。