**摘要：**为了解决Roach的性能问题，提出了CN增量备份手段，从而达到进一步优化RPO目的。

本文分享自华为云社区《GaussDB(DWS)备份容灾之CN增量备份》，作者： zxy_db 。

1. 摘要

在数据量增大时，如果CN每次都做全量备份，则会导致每次的备份数据量很大，不仅会降低备份的性能，也从造成备份集恢复性能的降低。如果改成CN增量备份，则备份集只会备份差异数据，这样不仅会使得备份数据量变小，而且也会提升备份集恢复的性能。

2. CN备份原理

对于主备集群CN备份与恢复的过程，如下图所示：

在备份过程中，只备份主CN的数据，且只发送到备集群对应的主CN所在的节点上。
在恢复过程中，非主CN节点从主CN节点上拷贝rch文件，然后再将备份数据的rch文件恢复到实例目录。
CN备份同集群备份一样，先进行行存备份，后进行列存备份。
对于行存备份过程，首先是准备列表，然后备份文件。
准备列表主要分为3个步骤：第一步是获取CN备份类型，第二步是根据备份类型，决定LSN区间，第三步是根据LSN区间，准备备份列表(全量备份列表和增量备份列表)。
对于列存备份过程，同上述行存。
行存和列存区别在于增量备份LSN区间的取法：
行存文件来说，增量是上次startLSN到本次startLSN之间
列存文件来说，增量是上次barrierLSN到本次barrierLSN之间

3. CN备份判断逻辑

首先，CN增量需要有一个基础备份，因此，集群在做全量备份时，CN仍然做全量备份。
其次，集群在两次增量备份过程中，CN发生删除和加回后，新增的CN需要做全量备份。
对于支持异构的情况下，如果ID最小的CN发生变化，同样需要对CN做一次全量备份。
整体的备份逻辑如下图所示。

3.为了实现上述判断逻辑，通过创建标志文件backup_label.old来控制CN做全量备份还是增量备份。backup_label.old在Python侧创建。即在Python侧，调用gs_roach备份前，在最小的CN上，即要进行备份的CN上，创建backup_label.old文件。根据backup_label.old的修改时间和priorBackupKey转化的时间，判断CN做增量备份还是全量备份。流程图如下图所示。如右半部分所示，如果backup_label.old文件的修改时间比prriorBackupKey转换获得的时间大，则进行全量备份。否则，进行增量备份。