作者Q先生·2023-07-19 23:32

研发总监·某公司

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

字数 4972阅读 775评论 2赞 4

内容摘要：

备份系统应基于资源而非任务管理，避免时间点错乱、管理陷阱、无法删除无效数据等问题。基于资源的备份管理系统提供灵活多变的分组和直观的备份成效统计，虚拟机组可用于管理虚拟机的筛选规则，实现更精细化的资源管理，提高备份产品的管理效率和体验。

当前摘要为AI生成

# 当我们想要做备份...

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

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

![](/home/attachment/202307/19/1236661_168978047986222.png)

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

![](/home/attachment/202307/19/1236661_168978049287774.png)

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

![](/home/attachment/202307/19/1236661_168978050213148.png)

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

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

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

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

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

![](/home/attachment/202307/19/1236661_168978052559063.png)

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

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

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

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

![](/home/attachment/202307/19/1236661_168978053413487.png)

倘若备份任务原先需要备份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 从任务中移除，以期能够清理出一部分存储空间。

![](/home/attachment/202307/19/1236661_168978058129991.png)

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

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

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

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

![](/home/attachment/202307/19/1236661_168978059924737.png)

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

![](/home/attachment/202307/19/1236661_168978060585460.png)

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

![](/home/attachment/202307/19/1236661_168978061437565.png)

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

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

![](/home/attachment/202307/19/1236661_168978062535197.png)

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

- 创建备份任务时，我们会困惑：虚拟机是否已经存在于其他备份任务里了？是否已经备份过？

- 执行备份任务时，我们会困惑：两个任务备份同一台虚拟机会不会互相影响？会不会造成任务异常？

- 恢复备份数据时，我们会困惑：要恢复的虚拟机到底存在哪个备份任务？哪个备份任务才有最新的备份数据？

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

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

![](/home/attachment/202307/19/1236661_168978064731504.png)

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

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

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

## “新近效应”的影响

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

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

## 基于资源的备份管理

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

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

![](/home/attachment/202307/19/1236661_168978066377423.png)

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

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

## 提供灵活多变的分组

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

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

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

- 针对宿主机备份，其实就是针对处理同一宿主机下的所有虚拟机做备份

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

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

![](/home/attachment/202307/19/1236661_168978067629194.png)

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

# 结语

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

灾备技术备份灾备

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！

添加新评论2 条评论

a59011572存储工程师广州
2024-05-07 23:21

写的很不错

yulu4314技术支持长春
2023-07-29 08:50

写的很详细，值得一看！

Ctrl+Enter 发表

匿名评论

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

添加新评论2 条评论

文章目录展开目录

作者其他文章

相关文章

相关问题

相关资料