# DDS新增量备份与恢复方案
#### 操作场景
随着业务规模的持续增长，数据库备份不仅需要满足"可用性"，还需具备更高的可靠性、更少的使用限制以及更快的备份恢复效率。针对DDS实例，华为云现已推出新的增量备份与恢复方案，进一步优化了分片集群场景下的备份能力，为客户提供更加高效、稳定的数据保护体验。与旧方案相比，新方案在分片集群场景下具有更少的限制、更快的增量备份速度和更完整的恢复链路，尤其是在shard数量较多时，其性能优势更为显著。
#### 概述
DDS 备份由全量备份和增量备份构成：
● 全量备份：保存某一时间点的完整数据。
● 增量备份：记录自全量备份后发生的数据变更。
● 恢复：通过结合全量备份和增量备份，将实例恢复至目标时间点。
旧方案：
● 副本集实例基于oplog进行增量备份。
● 分片集群实例基于Change Stream进行增量备份。
新方案：
● 副本集仍基于oplog进行增量备份；
● 分片集群改为基于每个shard的hidden节点和config server的hidden节点分别备份各自的oplog。
新方案的核心变化主要体现在分片集群增量备份架构的升级。
#### 新旧方案区别
在旧方案中，分片集群的增量备份依赖于Change Stream来获取变更数据。而在新方案中，分片集群的增量备份不再依赖Change Stream，而是由各shard的hidden节点以及config server的hidden节点分别备份各自的oplog。
可以简单理解为：
● 旧方案：通过Change Stream统一获取集群变更。
● 新方案：各组件基于自身的oplog分别采集增量数据。
对应关系如下：
表1新旧方案对比 
| **实例类型** | **旧方案**                | **新方案**                                                 |
|:---|:---|:---|
| 副本集      | 基于 oplog 增量备份。         | 基于 oplog 增量备份。                                          |
| 分片集群     | 基于 Change Stream 增量备份。 | 基于各 shard hidden 节点和 config server hidden 节点分别备份 oplog。 |
   
这种变化使得分片集群的增量备份方式更加贴近底层日志结构，整体备份链路也更加清晰。
#### 新方案优势
新方案上线后，分片集群场景主要获得以下收益：
1. 受限场景更少。 在旧方案中，分片集群的增量备份依赖于Change Stream，在某些场景下会受到相关能力的限制。新方案则直接基于各shard和config server的oplog进行增量备份，适用范围更广，受限场景更少。
   
2. 增量备份速度明显提升。 在新方案中，各shard可以并行备份各自的oplog，与旧方案相比，增量备份的效率显著提升。对于分片集群而言，shard数量越多，并行度越高，增备速度的提升也越明显。因此，在拥有较多shard的集群中，新方案的优势更为突出。
   
3. 恢复链路更完整。 新方案不仅涵盖了各shard的数据变更，还涵盖了config server的元数据变更。在恢复时，系统基于全量备份和增量备份进行统一编排，能够更完整地恢复集群状态。
   
 
#### 恢复说明
在恢复场景下，系统会基于备份链完成数据恢复，主要过程包括：
1. 先恢复全量备份。
2. 再按顺序回放增量日志。
3. 协同恢复各shard和config server的相关变更。
因此，新方案不仅提升了增量备份效率，也为分片集群提供了更完整的恢复基础。
#### 从旧增备切换到新增备的操作说明
已使用旧增备方案的实例，可通过以下步骤切换到新增备方案。
1. 该功能当前处于公测阶段，如需使用，请[提交工单](https://console.huaweicloud.com/ticket/#/ticketindex/createIndex)为目标DDS实例所在账户申请开通新增量备份。
2. 新增量备份开通后，将实例升级到支持新增备方案的最新补丁版本。具体升级操作，请参见"[补丁升级](https://support.huaweicloud.com/usermanual-dds/dds_03_0211.html)"内容。
3. 重新开启增量备份。 
   在备份策略中：
   - 先关闭增量备份。
   
   - 再重新开启增量备份。
   
   
   完成后，实例将从旧的增量备份方案切换到新的增量备份方案。
   
   
 
#### 切换注意事项
在切换过程中，请重点关注以下事项：
1. 关闭增量备份将删除历史增量备份文件。
2. 切换后，系统将基于新方案重新建立增量备份链。
3. 建议在近期无恢复需求时进行切换操作。
4. 如果客户短期内可能依赖现有的历史增量备份进行恢复，建议暂时不要切换，等到合适的时间窗口再执行。
#### 日常使用备份与恢复的注意事项
在日常使用备份与恢复功能时，建议关注以下几点，以提高恢复效率并降低恢复失败的风险。
1. 关键删除类操作前，建议先执行一次手动全量备份。 在执行以下关键删除类操作前，建议先进行一次手动全量备份：
   - dropCollection
   
   - dropDatabase
   
   - shardCollection
   
   
   这类操作通常会对数据或数据分布产生较大影响。在操作前保留一份新的全量备份，可以在后续发生误操作或需要恢复时，显著缩短恢复时间。
   
2. PITR 恢复到新实例时，目标实例规格不宜明显低于源实例。 如果源实例规格较大，而在执行 PITR（按时间点恢复） 到新实例时选择了明显更小规格的目标实例，可能带来以下问题：
   - 恢复耗时明显增加。
   
   - 恢复过程中资源压力较大。
   
   
   在极端情况下，可能会因为内存不足导致OOM（Out of Memory），从而造成恢复失败。因此，建议在进行PITR恢复到新实例时，目标实例的规格不应明显低于源实例，特别是在数据量较大、增量日志较多的场景下，更应合理评估目标实例的CPU和内存资源。
   
3. 新增备方案下，PITR 恢复性能与目标实例 CPU 规格相关。 在新的增量备份方案中，恢复阶段通过多线程回放oplog的方式执行增量数据恢复。因此，在PITR恢复到新实例时，目标实例的CPU核数越多，增量日志回放速度通常越快。对于恢复效率要求较高的场景，建议优先选择CPU规格更高的目标实例，以尽快完成PITR恢复并定位关键数据。待恢复完成并确认所需数据后，再根据实际需要将实例变更为较小规格，以兼顾恢复效率和资源成本。