当我们想要做备份...

如果我们要备份一个资源对象，首先要做的，就是要创建一个备份任务，配置好对应的参数，如备份代理、存储介质等等，然后就可以针对这个备份任务执行备份了。每备份一次便会产生一个备份副本。

备份任务有两个必要的策略，一个是数据保留策略，历史的备份数据无需全部保留，一般用户仅需保留最近的几个备份副本，或最近一段时间内的备份副本即可。另一个是备份策略（有的产品也叫做备份计划等），即什么时候启动备份，用于自动控制备份任务的执行。我们以虚拟机备份为例：

后来呢，有多个对象需要备份，并且期望使用相同的配置和策略。很简单，只需要在备份任务里再关联这些新的对象。这种情况下，备份任务每执行一次，都会将任务中的所有虚拟机纳入备份。

再后来呢，我们发现要把一个个虚拟机关联到备份任务里也很麻烦，于是我们发现部分虚拟机属于同一个宿主机，有没有可能备份任务直接关联宿主机？当宿主机下有新的虚拟机出现时，可以自动纳入备份任务的下次备份。这是不错的想法，于是我们看到很多产品都支持了这样的能力。

由此，一个看起来还不错的备份系统由此就产生了。

当事情开始变得复杂 ...

随着越来越多的用户开始使用这个备份系统，各种各样的场景也就开始出现，慢慢的我们会发现这个备份系统其实并不友好，它存在很多问题。

问题1： 错乱的备份时间点

基于任务模式的备份，一般会将任务的启动时间或结束时间设为备份时间点。但是，当备份任务中包含多个虚拟机时，虚拟机的实际快照时间与任务的启动或结束时间并不一致。如下图所示，备份任务 20:00 启动备份并产生备份副本，标记时间点为 20:00。实际上，虚拟机a1于20:00执行快照，虚拟机a2于21:00执行快照，虚拟机a3于22:00执行快照。

这里我们需要知道的是，虚拟机的快照时间才代表了虚拟机在那一时刻的状态，备份副本的备份时间（图中20:00）对于我们了解虚拟机的真实 RPO 并不能给予直接的帮助。这一点，会给用户在灾难恢复演练或恢复的时候带来困惑。

问题2：暗藏陷阱的时间点管理

基于任务模式的备份，一般会将整个任务的备份数据作为一个完整副本。如上文所述，当备份任务下有新的虚拟机产生时，此虚拟机会自动纳入下次备份。由此，新生成的备份副本里自然也就包含了这个新虚拟机了。

但若是有虚拟机从备份任务中移除了呢？我们来分析一下下图这个场景：

倘若备份任务原先需要备份a1, a2, a3 三台虚拟机，用户设置了保留2个备份副本。

• 第1次备份，顺利备份3台虚拟机，产生备份副本1
• 第2次备份，虚拟机a3被移除，备份任务仅成功备份a1和a2两台虚拟机，产生备份副本2
• 第3次备份，同第2次，产生备份副本3。

第3次备份完成后，由于备份任务仅需要保留2个备份副本，此时就需要清理备份副本1。这时候我们发现，备份任务再也无法恢复虚拟机a3了。这似乎与我们最初保留2个备份副本的预期相悖，我们的预期应当是这3个虚拟机都能保留2个可恢复的副本。显然，备份任务的这种管理模式给我们留下了陷阱。

问题3：无法删除的无效数据

基于备份任务的管理模式，往往也会出现无法删除无效数据的情况。如下图所示，当备份任务选定 a1，a2，a3 三台虚拟机做备份，并要求保留3个月内的备份副本数据。一段时间后，用户备份存储空间紧张，并发现 a3 虚拟机上并无重要数据，于是选择将虚拟机 a3 从任务中移除，以期能够清理出一部分存储空间。

这个时候我们会发现，存储空间并不能被释放，虚拟机 a3 的备份数据分布在备份任务的各个备份副本中，难以单独清理，似乎只能无奈等待新的副本替换旧的副本。

问题4：难以忍受的异常处理

备份任务的执行受到很多因素的影响，出现异常在所难免，但能否有效处理任务异常后的善后工作，就成了用户会关注的事情。我们来看下，基于任务模式的管理，是如何在任务异常后变得让人难以忍受的。

我们首先来看第一个异常场景，如下图所示，当我们创建好备份任务，执行备份的时候，任务报错告诉我们某个虚拟机不支持备份（如图中a3），那么我们就需要调整备份任务所管理的数据源。除了白白做了配置之外，我们还必须小心翼翼，充分了解备份产品的限制性，才能确保任务中的虚拟机都是可备份的。

我们来看第二个异常场景，如下图所示，当执行备份的时候，某个虚拟机备份失败（如图中a3），整个任务部分成功。这似乎也没啥，但如若我们需要确保虚拟机的 RPO 符合要求，我们就需要对 a3 进行补偿备份。这个时候，我们会发现，补偿备份似乎没那么容易。要么，我们基于整个备份任务再做一次备份，这明显不是很必要，且会拉长备份时间。要么，我们针对虚拟机 a3 再创建一个备份任务，单独做一次备份，这显然也很复杂，并且会造成混乱。

我们再来看第三个异常场景，如下图所示，当备份执行到虚拟机 a3 的时候，因为某些原因出现进程崩溃，致使整个任务备份失败。备份任务失败，自然不会产生备份副本，于是已经备份的虚拟机 a1 和虚拟机 a2 此次的备份数据也都会被一起清理。两三个虚拟机似乎无所谓，但虚拟机量一大，数据量一多，那这样的备份浪费就有些让人痛心疾首了。

问题5：令人困惑的备份任务

基于备份任务的管理，为了提供灵活性，往往会允许不同的任务绑定相同的数据源。数据源一旦没有了限制，随着任务数量越多，管理的难度就就越高。如下图所示，备份任务A中的“虚拟机a2” 属于备份任务B中的“资源池2”；备份任务B中的“资源池1”属于备份任务C中的“宿主机1”；备份任务A与备份任务C同时包含数据源“虚拟机a3”。

这样的场景看似极端，但存在大量任务的情况下，数据源重叠的情况屡见不鲜。这样的模式显然会让我们在管理时感到困惑：

• 创建备份任务时，我们会困惑：虚拟机是否已经存在于其他备份任务里了？是否已经备份过？
• 执行备份任务时，我们会困惑：两个任务备份同一台虚拟机会不会互相影响？会不会造成任务异常？
• 恢复备份数据时，我们会困惑：要恢复的虚拟机到底存在哪个备份任务？哪个备份任务才有最新的备份数据？

问题6：无法感知的备份成效

当我们基于备份任务来管理备份，自然而然的，我们会基于备份任务来操作归档任务和远程复制任务。当数据开始在不同的存储介质中来回传输，备份任务所产生的备份副本将散落在各处，如下图所示。

这个时候，我们发现事情变得更加复杂。当我们需要了解某个虚拟机是否已经备份、是否已经归档、是否在异地保留了足够的副本，或者当我们需要从某个介质恢复虚拟机、需要清理某个虚拟机的所有副本，我们似乎都无从下手。似乎所有的操作都需要追溯到“备份任务”才行，这不仅给备份管理带来了麻烦，更使我们难以了解备份的成效。

什么才是更有效的备份系统？

基于任务的管理模式显然给我们带来了很多的问题，我们需要寻找更合适的备份管理方案。从上文来看，所有的问题似乎都脱离不了“备份任务”，而仔细观察我们会发现，我们需要真正关注的，是那些需要被保护的对象，如“虚拟机”。

“新近效应”的影响

心理学上有个“新近效应”的概念，意思是说我们的思维会被最近关注的内容所影响，而导致我们容易忽视事物的本质。

以上述问题为例，我们被最开始的“备份任务”的概念所牵引，以此设计了不那么合理的备份管理系统；如若用户真的用上这个备份系统（事实上，现在的大部分备份系统都是这种管理模式），同样的，用户也就会开始关注备份任务，关注每天的任务执行情况，而无意识的忽视了要保护的对象是否真的得到了预期的保护。

基于资源的备份管理

从上文其实我们就可以发现，更好的管理方式，应当是基于资源（要保护的对象）的管理方式。基于资源发起备份与恢复、基于资源归档与复制、基于资源清理副本、基于资源统计分析。由此，我们才能更直观的了解我们的备份成效。

我们仍以虚拟机备份为例。基于资源的备份管理系统如下图所示：

首先，备份系统需要同步虚拟化平台上的虚拟机信息，之后针对需要备份的虚拟机（如图中a1和a3）配置对应的备份策略和数据保留策略。如此，用户可直接针对虚拟机a1和a3启动备份，所产生的备份副本也将仅包含其自身的备份数据。

在这样的管理模式下，我们发现，之前的问题几乎都迎刃而解了。唯一需要关注的异常，就是当虚拟机从原虚拟化平台上被删除后，我们要如何处理。这也并不复杂，将这些虚拟机统一归类并标记为“已删除”即可，还可以帮助用户快速找到误删的虚拟机，或清理那些不必要虚拟机的数据，这在任务管理模式下可不是那么容易做到。

提供灵活多变的分组

基于任务的管理模式有个不错的能力，就是“自动发现”，它可以备份资源池或者宿主机，以期自动将对应位置下新增的虚拟机自动纳入备份，这可以简化用户的备份管理。

那么，基于资源的管理自然不能落下这个能力。如何做呢？其实也简单，我们仔细思考就会发现：

• 针对资源池备份，其实就是针对处于同一资源池下的所有虚拟机做备份
• 针对宿主机备份，其实就是针对处理同一宿主机下的所有虚拟机做备份

如此，我们仅需要 根据位置找到其下的所有虚拟机，并批量配置备份策略、数据保护策略，或批量启动备份 即可。批量操作是基础能力，那么重点就变成了：如何筛选出对应的虚拟机清单？

这里我们需要引入一个“虚拟机组”的概念，主要用于管理虚拟机的筛选规则。在上一章节中，我们有讲到，备份系统需要同步虚拟化平台虚拟机的信息，为了方便筛选呢，我们可以在同步过程中采集虚拟机的很多信息，如下图所示，可采集的信息包括：名称、位置、电源状态、操作系统 等等。

基于采集到的虚拟机信息，我们就可以在虚拟机组中添加丰富的筛选规则。如图中所示，我们可以筛选出“位置处于资源池a”的所有虚拟机，也可以筛选出“位置处于资源池a 并且 电源状态为开机”的虚拟机。如此，我们便提供了比任务模式更灵活多变的分组能力，实用性也更强。

结语

基于资源的管理模式，帮助我们将核心关注点从备份任务切换到资源对象，将更有助于我们管理备份。做到这一点，备份产品的体验将大大提升。