Openstack 中cinder backup三种backend的对比

K版Openstack的Cinderbackup service新增加NFS作为backend，同时增加对增量备份的支持。这样当前已经支持四种backend，这里主要对其中三种ceph、nfs、swift的备份实现机制做一下对比介绍。另外一种TSM是IBM的存储，如果以后能有幸接触到再做研究和介绍。

先看下面的表格有一个整体了解。

 

增量备份

备份之间依赖关系

增量恢复

Ceph

特特定条件下支持

没有依赖关系

特定条件下支持

Swift

支持

备份链

不支持

NFS

支持

备份链

不支持

Ceph、Swift、NFS三种cinderbackup backend的特点对比

根据备份实现的特点，将这三种backend分为两类，其中NFS和Swift分为一类，Ceph单独作为一类。

一、基于Chunk的backend

首先介绍一下Swift和NFS，这两个放在一起说，是因为他们都继承自ChunkedBackupDriver，二者的实现机制完全一样，都是将原始的volume拆分成chunk，然后保存到对应的存储上。不同点只在于存放数据的方式。

在介绍之前先了解两个重要的参数：

Chunk_size:表示将volume分成多大的块进行备份。在NFS中这个值叫做backup_file_size，默认是1999994880 Byte，大约1.8G。在Swift中这个值叫做backup_swift_object_size，默认是52428800Byte，也就是50M。在Ceph中这个值叫做backup_ceph_chunk_size，默认值是128M。

Sha_block_size:这个值用于增量备份，它决定了增量备份的粒度。在NFS中，这个值叫做backup_sha_block_size_bytes，在Swift中，这个值叫做backup_swift_block_size。默认都是32768Byte，也就是32K。在Ceph，没有对应的概念。

1.1全量备份

对一个volume做全量备份的时候，每次从volume读入Chunk_size字节的数据，然后从头开始，每Sha_block_size（Chunk_size必须是Sha_block_size的整数倍）个字节做一次SHA计算，并将结果保存起来，然后会把Chunk_size的数据进行压缩（可以配置不压缩），并保存到对应的存储上，这就形成了NFS上的一个文件或者Swift中的一个object。这样循环，直到把整个volume都保存到backend上。最后还会生成两个文件，一个是metadata，其中记录了这个volume对应存储上哪些文件（或objects），每个文件（或object）的大小、压缩算法、长度、偏移量等；另一个是sha256file，其中按顺序记录了每次SHA计算的结果。这两个文件也会随之前的Chunk一起保存。至于metadata和sha256file这两个文件有什么用，且见下面分析。

1.2增量备份

增量备份实现思路很简单，对一个volume进行增量备份时，会读取前一次备份（全量或增量）的sha256file，备份时会将每Sha_block_size数据SHA计算的结果与上次备份的值比较，如果相同，就只保存计算结果，如果不同就会将对应的Sha_block进行备份。连续SHA计算结果不同的Sha_block会保存成同一个文件。其中metadata中会注明每个文件的大小以及在原始volume中的偏移量。

由以上描述可以知道，sha256file是实现增量备份的关键。这个文件记录了原始卷每个Sha_block_size数据的SHA值，每次增量备份时，将新的SHA值和上次备份记录的值进行比较，只需要备份SHA值不同的数据。另外，我么也可以知道，增量备份之间是有依赖的，新创建的备份会依赖于上一次的备份，多次增量备份会形成一个依赖链，在这里我们可以称之为备份链。在给volume创建增量备份时，总是会基于这个volume最新备份去创建。每次创建一个全量备份，都意味着增加一个备份链。

1.3全量备份的恢复

备份恢复时，如果指定了volume id，会恢复到指定的volume中，如果没有指定会新创建一个volume，并恢复到对应的volume中。

全量备份的恢复很简单，只需要找到对应的备份，将其内容写回对应的volume即可。那么这里有个问题，每个备份都对应存储上哪些文件呢，每个文件又对于原始volume中哪些数据？还记得创建备份时生成的metadata文件吗，答案就在其中。恢复备份时，会读取这个文件，然后将每一个备份文件恢复到对应的位置。当然，如果有压缩也会根据metadata中的描述，先解压再写入对应的volume中。

1.4增量备份的恢复

增量备份的恢复稍微复杂一些，正如之前的描述，增量备份之间有依赖，会形成备份链，我们需要恢复所选备份及其在备份链上之前所有的数据。在恢复时，需要查询数据库，获取当前备份及备份链上之前的所有备份，其顺序是[所选备份，父备份，父父备份，……全量备份]，恢复的时候会按照相反的顺序依次进行，即首先恢复全量备份，接着创建的第一个增量备份，第二个增量备份，直到所选的备份。每个备份恢复时依赖创建备份时生成的metadata文件，将备份包含的文件，恢复到volume中。每个备份的恢复和全量备份的恢复方式一样。

1.5相关命令行

创建一个全量备份：

cinderbackup-create [--display-name <display-name>] <volume>

创建一个增量备份：

cinderbackup-create [--display-name <display-name>] --incremental True <volume>

恢复一个备份：

cinderbackup-restore [--volume-id <volume>] <backup>

二、使用Ceph作为backend。

按照cinder-volume所用的backend分两种情况介绍，一种是cinder-volume使用非rbd作为backend，这种情况和上面的Swift、NFS情况类似；另一种是cinder-volume使用rbd作为backend，这中情况下备份充分利用了ceph的特性，我们单独介绍。

2.1 cinder-volume使用非rbd作为backend

这种情况下比较简单，并且仅支持全量量备份。在创建备份时，首先创建一个base backup image，然后每次从源卷读入chunk_size（即backup_ceph_chunk_size，默认是128MB）大小的数据，写入到backup image，直到把整个源卷都复制完。注意，这里不支持对chunk的压缩。因为volume上的数据都会写入到创建的这个backup image上去，也就是说volume和backup是一对一的，因此也不需要metadata文件。

2.2 cinder-volume使用rbd作为backend

在这种情况下，即cinder-volume和cinder-backup都是用rbd作为backend，是支持增量备份的。增量备份的实现完全依赖于ceph处理差量文件的特性，这里对此先做个简单介绍。

所谓ceph处理差量文件的能力，即ceph可以将某个rbd image不同时刻的状态进行比较，并且将其差量导出成文件。另外，ceph也可以将这个差量文件导入到某个image中。

2.2.1 Ceph使用差量文件的三种方式

Ceph生成差量文件的三种方式

1、rbd export-diffvolumes/image1  image1diff   将volumes/image1从创建到此刻的变化保存image1diff这个文件。

2、rbd export-diff volumes/image1@snap1 image1s1diff 将volumes/image1创建时和快照snap1的不同保存在image1s1diff这个文件。

3、rbd export-diffvolumes/image1 –from-snap snap1 image1s1diff2   将现在volumes/image1和快照snap1的不同保存在image1s1diff2.

 Ceph导入差量文件的三种方式

对应上面三种生成差量文件的方式，有三种导入差量文件的方式。导入的前提是先创建一个image2，然后将diff文件导入这个image。

1、 rbdimport-diff  image1diff  volumes/image2   此时image2和生成diff时的image1相同

2、rbd import-diff  image1s1diff volumes/image2  此时image2和创建snap1后的image1相同，也就是说image2也有一个叫做snap1的快照

3、 rbdimport-diff  image1s1diff2  volumes/image2   这个可以执行的前提是image2有一个叫做snap1的快照

注意：生成diff和使用diff的1、2、3是分别对应的

2.2.2 备份的实现

现在知道了ceph是如何使用差量文件的，下面来看看如何利用这个特性实现备份，这里同样分为两种情况：

一、对一个volume第一次进行备份

1、创建一个新的base rbd image，名称格式："volume-%s.backup.base"% (volume_id

2、将soure-rbd创建一个snap，名称格式："backup.%s.snap.%s"% (backup_id, time.time())

3、利用第2种生成diff的方式生成diff文件

4、利用第2种导入diff的方式导入第一步生成的image中  （代码中并不会生成diff文件，而是采用类似于管道方式直接diff到目标位置）

5、备份完成

可以看出，第一次备份，也是类似于差量备份。

二、第二次及以后再备份

1、  找出soure-rbd image上最近一个满足r"^backup\.([a-z0-9\-]+?)\.snap\.(.+)$"的快照

2、  在base rbd image上查找是否有一个和第1步找到的快照相同名称的快照（正常应该是有的，见上面导入diff文件的第2种方式，没有就抛出异常）

3、  在source-rbd 创建一个snap，名称格式："backup.%s.snap.%s" % (backup_id, time.time())

4、  利用第3种方式生成diff文件，所用的snap即第1步中找到的那个快照，也就是说每次的diff都是相对于上一次备份而言的，这也就达到了增量备份的目的。

5、  将diff文件导入到base rbd image上

6、  备份完成

由上可知，同一个volume的所有备份对应同一backup rbd image，创建备份时，会在原始卷上创建一个快照，通过比较新建快照和上一次备份的快照形成差量文件，将这个差量文件导入到backup rbd image即完成了备份。由上面ceph处理差量文件的特性可知，这个快照也会存在于backup rbd image上，也就是说每个备份对应的是backup rbd image上的一个快照。

2.2.3备份的恢复

这里分两种情况，diff方式（增量恢复）和非diff方式（全量恢复），只有满足一定条件时才能使用diff方式。

使用diff方式的条件：

1、   Cinder-volume使用rbd作为backend，并且不是恢复到创建备份的原始卷；

2、   目标卷必须和源卷相同大小，不能有扩容；

3、   备份上存在backup rbdimage（第一次备份时创建）；

4、   备份上有backup id对应的snapshot

利用diff方式恢复备份，本质上也是利用了ceph处理差量文件的能力。非diff方式的恢复则同NFS、Swift类似。

非diff方式的恢复

这个其实就是全量恢复，和之前的NFS、Swift差不多，就是每次从备份读入chunk_size的数据，写入到对应的volume，知道复制完整个备份。没有metadata文件，也不支持解压。

diff方式的恢复

这个利用了ceph的特性，首先找到第一次备份时创建的base image和所选备份的snapshot，利用上面讲述的第2种生成差量文件的方式生成diff文件，将diff文件导入到新的volume（cinder-volume上新创建的volume）就完成了volume的恢复。

2.2.4相关命令行

创建一个全量备份：

cinderbackup-create [--display-name <display-name>] <volume>

恢复一个备份：

cinderbackup-restore [--volume-id <volume>] <backup>

    backup-create时先尝试创建增量备份，如果不成功，会创建全量备份，不需要指明专门的参数。