备份数据一致性概念：
首先我们先来了解一下备份一致性的概念：
不一致备份：云服务器中文件或磁盘数据的备份，不在同一时间点产生。
崩溃一致性备份：云服务器中文件或磁盘数据的备份，在同一时间点产生，但不会静默数据库等应用系统、不会备份内存数据，不保证应用系统备份的一致性。
应用一致性备份：文件/磁盘数据在同一时间点，并静默数据库刷新内存数据，保证应用系统备份的一致性。
应用一致性备份需要在云主机中安装对应的agent才能实现
工作原理：
友商实现分析：
对一台虚机进行整机备份时，备份服务对所有云盘发起打快照操作，这样一组快照会被组织成一个整机的恢复点，这些快照在快照控制台是可见的。若该虚机所有盘都是ESSD，这些盘会组成一致性快照组后打快照来保障整机的一致性。对于非ESSD云盘，备份服务则是同一时间为每块盘打快照，实际快照时间点可能会略有差异，不保障所有盘的快照时间点完全相同。
友商有个云盘一性快照组的概念： 一致性快照组
通过创建快照一致性组，您可以为一台或多台虚机实例中的多块云盘同时创建快照。快照一致性组能够保证在业务系统跨多块云盘的场景下，数据写入云盘的时序一致性，并保证其崩溃一致性。
- 业务系统部署在跨虚机实例的集群文件系统中，且要求时序一致性以及崩溃一致性的数据库或企业级应用的场景。例如，基于虚机自建的MySQL集群，基于多个卷搭建LVM、Oracle、SAP HANA上云场景等。
- 大型项目、多应用协同系统等分布式应用系统所需的统一创建快照的场景。
- 需要对同一地域下多台虚机实例的云盘数据进行批量备份，且对时序一致性有较高要求的场景。
分析：
针对单台虚机备份，且对一致性要求不高的场景，可以实现崩溃一致性备份，对虚机先执行冻结IO，再对每一块盘进行快照。
针对多台虚机同时进行备份，或者对时序一致性有较高要求的，需要借助ceph的一致性组特性 ，而且需要实现应用一致性
否则，只能建议关机再执行备份。
ceph的一致性组：
一致性组可用于数据保护（快照，备份）和远程复制（镜像）。
镜像支持
将允许在同一个一致性组中设置多个卷的镜像（即将多个RBD图像附加到同一个日志以确保一致的重放）。
快照支持
将允许在同一时间点采集同一一致性组中的多个卷的快照，以确保数据一致性。
常用操作：
rbd group create
创建组
rbd group ls [-p | –pool pool-name]
列出组
rbd group image add
添加镜像到组
rbd group image list
列出组的镜像
rbd group image remove
从组移除镜像
rbd group rename
组改名
rbd group rm
删除组
rbd group snap create
一致性组打快照
rbd group snap list
列出一致性组的快照
rbd group snap rm
删除一致性组的快照
rbd group snap rename
一致性组改名
rbd group snap rollback
一致性组回滚
实现思路：
基于kubevirt + ceph实现
单台虚机崩溃一致性备份：
1.新建一个crd，参考VirtualMachineSnapshot逻辑（不能复用VirtualMachineSnapshot，会导致单盘快照依赖整机快照）
2.调用kubevirt接口冻结虚机-》打快照 -》等各个盘快照成功后 -》 解冻虚机 -》快照进行备份
3.整机恢复，默认只恢复挂载在虚机的磁盘，新建一个crd，参考VirtualMachineRestore实现，把整个恢复任务包装起来
多台虚机崩溃一致性备份：
1.需要用到ceph 一致性组功能，对多个盘同时创建一致性快照
2.k8s层需要创建新的快照组crd，进行逻辑控制
3.创建一致性组
4. 云盘加入到一致性组-》打快照 -》等各个盘快照成功后 -》快照进行备份
应用一致性备份：
1、开发虚机内部agent，实现边缘通过虚机agent调用虚机内脚本 （涉及子网访问，部署等问题）
qemu agent 有对应的接口，可以参考qemu-guest-agent/fsfreeze-hook
2、整机备份需要把虚机的所有云盘加入一致性组
3、调用agent冻结应用 -》 打快照 -》等各个盘快照成功后 -》调用agent解冻应用 -》快照进行备份
