QEMU/KVM磁盘在线备份(5)

在备份操作前，可以另外再开一个shell窗口，实时监听qmp的事件

# 始终监听事件 virsh qemu-monitor-event DOMAIN --timestamp --loop # 当收到特定事件后停止监听 virsh qemu-monitor-event DOMAIN --event BLOCK_JOB_COMPLETED

开始备份时会收到的事件

2019-01-29 03:14:54.516+0000: event JOB_STATUS_CHANGE for domain DOMAIN: {"status":"created","id":"drive-virtio-disk0"} 2019-01-29 03:14:54.516+0000: event JOB_STATUS_CHANGE for domain DOMAIN: {"status":"running","id":"drive-virtio-disk0"}

备份完成时收到的事件

2019-01-24 06:25:21.629+0000: event JOB_STATUS_CHANGE for domain DOMAIN: {"status":"created","id":"drive-virtio-disk0"} 2019-01-24 06:25:21.629+0000: event JOB_STATUS_CHANGE for domain DOMAIN: {"status":"running","id":"drive-virtio-disk0"} 2019-01-24 06:26:34.935+0000: event JOB_STATUS_CHANGE for domain DOMAIN: {"status":"waiting","id":"drive-virtio-disk0"} 2019-01-24 06:26:34.935+0000: event JOB_STATUS_CHANGE for domain DOMAIN: {"status":"pending","id":"drive-virtio-disk0"} 2019-01-24 06:26:34.935+0000: event BLOCK_JOB_COMPLETED for domain DOMAIN: {"device":"drive-virtio-disk0","len":21474836480,"offset":21474836480,"speed":0,"type":"backup"} 2019-01-24 06:26:34.935+0000: event JOB_STATUS_CHANGE for domain DOMAIN: {"status":"concluded","id":"drive-virtio-disk0"} 2019-01-24 06:26:34.935+0000: event JOB_STATUS_CHANGE for domain DOMAIN: {"status":"null","id":"drive-virtio-disk0"}

▷ 重点看上面的BLOCK_JOB_COMPLETED事件，该事件从qemu-1.1就已经出现的
▷ 遗憾的是，事件内容并不详细，无法识别出是full、top、none还是bitmap，也看不到备份产生的文件路径

16. 备份链、数据恢复、合并

其实，本章节应该放到本文最后面，但本文篇幅较多，放后面担心容易被遗漏

备份链

经过增量备份后，会形成一条备份链：full.qcow2 <- inc.0.qcow2 <- inc.1.qcow2 <- inc.2.qcow2

数据恢复

当需要使用备份进行数据恢复时候，就可以使用该链上的文件进行恢复，比如要恢复到inc.1.qcow2的末尾，那么有2种方案：保持链、合并

▷ 保持链

1️⃣ 将full.qcow2、inc.0.qcow2、inc.1.qcow2拷贝到目标宿主机上
2️⃣ 通过qemu-img rebase -u来确保链的顺序
3️⃣ 虚拟机xml里指定inc.1.qcow2

▷ 合并

1️⃣ 将full.qcow2、inc.0.qcow2、inc.1.qcow2合并成为一个qcow2

# 将inc.1.qcow2合并到inc.0.qcow2 qemu-img commit inc.1.qcow2 # 将inc.0.qcow2合并到full.qcow2 qemu-img commit inc.0.qcow2

2️⃣ 然后xml里指定这个合并好的qcow2（即full.qcow2）就行