Cinder 的 backup 功能是由 cinder-backup 服务提供的，devstack 默认没有启用该服务，需要手工启用。与 cinder-volume 类似，cinder-backup 也通过 driver 架构支持多种备份 backend，包括 POSIX 文件系统、NFS、Ceph、GlusterFS、Swift 和 IBM TSM。支持的driver 源文件放在 /opt/stack/cinder/cinder/backup/drivers/
- 设置cinder.conf
[default]
backup_driver = cinder.backup.drivers.nfs
backup_mount_point_base = /backup_mount # 注意，这个配置是错误的，下面会说明。
backup_share = 172.24.3.96:/ozb_nfs_glance_volume_236
- 启动进程：
cinder-backup --config-file /etc/cinder/cinder.conf >> /opt/stack/logs/cinder-backup.log
cinder service-list 显示cinder-backup服务状态为UP即成功启动：
尝试创建一个备份：
[ubuntu@localhost ~]$ cinder backup-create iscsi_volume1
发现cinder-backup日志提示：
像是权限异常，为什么会出现这个问题？
检查日志，cinder-backup 做 self._execute('mkdir', '-p', mount_path, check_exit_code=0) 时候出错，这里是调用os_brick.privileged.rootwrap.execute(*cmd, **kwargs)。通过源码：
def execute(*cmd, **kwargs):
"""NB: Raises processutils.ProcessExecutionError on failure."""
run_as_root = kwargs.pop('run_as_root', False)
kwargs.pop('root_helper', None)
try:
if run_as_root:
return execute_root(*cmd, **kwargs)
else:
return putils.execute(*cmd, **kwargs)
需要传入参数run_as_root=True，才会用root权限执行指令。而cinder-backup没有传入这个参数，对于这个指令操作没有要求root权限执行。
而我之前设置的备份目录backup_mount_point_base = /backup_mount，放在根目录了，需要root权限才行操作！说明openstack的设计就是希望备份目录放在用户目录下。
解决方法： 官方文档里定义了backup_mount_point_base 默认为 $state_path/backup_mount， $state_path即cinder.conf里state_path = /opt/stack/data/cinder。我们直接把配置文件里backup_mount_point_base删了，让它使用默认的路径就可以了；或者定义一个用户目录下的路径。
正确的cinder.conf配置：
[default]
backup_driver = cinder.backup.drivers.nfs
backup_share = 172.24.3.96:/ozb_nfs_glance_volume_236
创建备份
指令：
usage: cinder backup-create [--container ] [--name ]
[--description ] [--incremental]
[--force] [--snapshot-id ]
[--force] 如果卷的状态是in-use，被挂载在某虚机上，需要用这个参数强行创建备份
[--name ] 备份的名字
[--incremental] 表示可以执行增量备份，如果不带这个参数就是全量备份。
[--description ] 说明
[--container ] 存放备份文件的目录
例：
[root@node1 cinder]# cinder backup-create netapp_volume1 --force
+-----------+--------------------------------------+
| Property | Value |
+-----------+--------------------------------------+
| id | d445c344-99f2-4b33-a98d-767c77aaa659 |
| name | None |
| volume_id | 43f962b7-f4d4-4f6e-a1fd-c0cc0e7e2c42 |
+-----------+--------------------------------------+
[root@node1 cinder]# cinder backup-show d445c344-99f2-4b33-a98d-767c77aaa659
+-----------------------+--------------------------------------------+
| Property | Value |
+-----------------------+--------------------------------------------+
| availability_zone | nova |
| container | d4/45/d445c344-99f2-4b33-a98d-767c77aaa659 |
| created_at | 2017-07-06T09:39:58.000000 |
| data_timestamp | 2017-07-06T09:39:58.000000 |
| description | None |
| fail_reason | None |
| has_dependent_backups | False |
| id | d445c344-99f2-4b33-a98d-767c77aaa659 |
| is_incremental | False |
| name | None |
| object_count | 21 |
| size | 6 |
| snapshot_id | None |
| status | available |
| updated_at | 2017-07-06T09:46:59.000000 |
| volume_id | 43f962b7-f4d4-4f6e-a1fd-c0cc0e7e2c42 |
+-----------------------+--------------------------------------------+
逻辑流程：
- 启动 backup 操作，创建一个目录/backup_mount/cc25579711b2c5b9989005239d0f15a5 来mount NFS。cc25579711b2c5b9989005239d0f15a5是配置项backup_share的hash值。
- 创建 volume 的临时快照。
- 创建存放 backup 的 Container 目录。目录名为 backup_id[0:2]/backup_id[2:4]/id。比如
backup: 3c49b86d-04bf-4e89-9317-510fee9e39ff
container: 3c/49/3c49b86d-04bf-4e89-9317-510fee9e39ff - 对临时快照数据进行压缩，并保存到 container 目录。
- 创建并保存 sha256（加密）文件和 metadata 文件。
- 删除临时快照。
container目录截图：
container包含三种文件：
- backup-00001，压缩后的 backup 文件。
- backup_metadata，metadata 文件。
- backup_sha256file，加密文件。
恢复备份：
指令：
usage: cinder backup-restore [--volume ] [--name ]
[--volume ] 指定一个空卷对象，用于还原。
[--name ] 如果没有带参数[--volume ]，系统会自动创建一个size等于buckup的、名字为name的空卷，用于还原
根据backup_id恢复卷：
cinder backup-restore 2311d9c7-5bfc-47cb-b2ae-858f67f46733
2311d9c7-5bfc-47cb-b2ae-858f67f46733是由一个volume_type为“vmware-type”的卷创建的backup-id。恢复出的卷的卷类型变成了None。
检查cinder.config里没有配置默认卷类型，所以我加上了配置default_volume_type = vmware-type，再backup-restore一次，还原出来的卷类型就是“vmware-type”了：
总结 backup-restore 两种用法：
（1）cinder backup-restore[--name ] 系统会选用配置好的默认卷类型创建一个空卷用于还原，如果没有配置默认卷类型，那这个空卷的类型会显示None。
（2）先自己用某个卷类型创建一个size不小于backup的空卷，然后cinder backup-restore[--volume ] 还原。
逻辑流程：
- 启动 restore 操作，mount NFS。
- 读取 Container 目录中的 metadata。
- 将数据解压并写到 volume 中。
- 恢复 volume 的 metadata，完成 restore 操作。
==代码分析尚未完成==
rootwrap简单介绍：
使用rootwrap的目的就是针对系统某些特定的操作，让非特权用户以root用户的身份来安全地执行这些操作
rootwrap 的配置文件是/etc/cinder/rootwrap.conf：
[DEFAULT]
# List of directories to load filter definitions from (separated by ',').
# These directories MUST all be only writeable by root !
filters_path=/etc/cinder/rootwrap.d
其中filters_path 指定了若干过滤器文件所在的目录，这个目录有个volume.filters 文件。这个是过滤器文件，定义了很多具体命令的相关信息，如命令的应用场景，命令封装所调用的过滤器，命令的执行权限和命令的执行参数等等。
[Filters]
# cinder/volume/iscsi.py: iscsi_helper '--op' ...
ietadm: CommandFilter, ietadm, root
tgtadm: CommandFilter, tgtadm, root
iscsictl: CommandFilter, iscsictl, root
tgt-admin: CommandFilter, tgt-admin, root
cinder-rtstool: CommandFilter, cinder-rtstool, root
scstadmin: CommandFilter, scstadmin, root
用于命令行封装过滤的过滤器有很多，实际上共有CommandFilter、RegExpFilter、PathFilter、KillFilter、ReadFileFilter、IpFilter、EnvFilter、ChainingFilter和IpNetnsExecFilter共9种；这些过滤器类都以CommandFilter为父类，它们的具体区别主要体现在其方法match上，所以这9种过滤器主要是根据不同命令应用不同的匹配方式而区分实现的。
rootwarp实现的具体步骤就是：
- 命令行解析
- 读取解析配置文件
- 加载过滤器文件中定义的所有命令行过滤对象
- 匹配到具体的命令行过滤对象
- 通过rootwrap的封装获取具体的命令行实现
- 派生一个子进程来执行命令行
实际上就是把命令行：
sudo nova-rootwrap /etc/nova/rootwrap.conf cat /etc/iscsi/initiatorname.iscsi
经过若干参数处理和匹配操作转化为：
sudo -u XXXX /bin/cat /etc/iscsi/initiatorname.iscsi
之后，启动一个子进程来实现这个命令行的执行操作；类似如下：
kolla环境的rootwrap.d可以在容器里的/etc/cinder目录找到
参考：
《Backup Volume 操作 - 每天5分钟玩转 OpenStack（59）》