数据同步原理

本⽂档旨在详细介绍源端同步的原理，涵盖代理(Agent)和无代理(Agentless)两种模式的底层实现技术。作为数据备份与恢复解决方案的核心技术之一，源端同步的效率与可靠性直接影响灾备系统的整体性能。本文将重点解析本产品在这两种模式下的核心实现机制，并深入阐述增量数据获取的原理，以帮助读者更全面地理解数据同步的关键技术。

数据一致性与可恢复性设计说明

1. 设计理念与总体原则

在灾难恢复领域，数据一致性并非最终目标，业务系统在灾难发生后是否能够被成功恢复并稳定运行，才是衡量灾备方案有效性的核心标准。

产品在设计之初即确立了"以恢复为中心、以一致性为基础"的总体原则。该原则强调：

• 数据一致性是灾难恢复的必要条件，但不是充分条件
• 理论层面的"一致性保证"必须通过实际恢复验证来确认
• 灾备能力应以工程验证结果为依据，而非仅依赖同步机制或一致性模型的假设

基于这一理念，产品在数据获取阶段严格遵循操作系统、数据库及云平台所提供的原生数据采集与快照机制，避免对业务系统引入非标准或强侵入式的数据控制方式；在灾备侧，通过周期性、可重复的灾备演练，持续验证数据的可恢复性与业务系统的可运行性，并将演练结果作为评估灾备能力有效性的最终判断依据。

2. 灾备演练与数据完整性验证

产品将灾备演练视为灾难恢复体系中的基础能力，而非可选功能。

系统提供完整的灾备演练机制，用于周期性验证灾备侧数据在真实恢复路径下的可用性。演练过程通常包括：

• 在灾备环境中启动完整的业务系统或数据库实例
• 执行操作系统或数据库所支持的原生恢复流程
• 验证系统是否能够正常启动、数据是否可访问、核心业务服务是否可运行

通过在不影响生产系统的隔离环境中执行演练，产品能够提前发现潜在问题，例如：

• 数据库日志不完整或顺序异常
• 操作系统无法启动
• 应用运行所依赖的服务、配置或组件缺失

相关问题可在真实灾难发生前完成定位和修复，从而显著降低灾难发生时的恢复风险。 在产品的设计体系中，演练结果本身即构成数据完整性与可恢复性的最终验证标准。

3. 数据采集方式与一致性保障策略

产品根据操作系统类型及部署模式的不同，提供差异化的数据一致性保障策略，以适配不同业务系统的实际运行特性。

1. Windows Agent 模式

在 Windows 平台中，产品代理(Agent)与系统自带的卷影复制机制进行集成：

• 对于支持该机制的应用或数据库

  • 在数据采集前协调系统完成 I/O 冻结与缓存刷新
  • 获取应用级一致性的数据状态

• 当目标系统或应用未提供相关接口时

  • 数据一致性级别自动回退为崩溃一致性

该模式适用于对应用或数据库一致性要求较高的业务系统。

2. Linux Agent 模式

由于 Linux 平台缺乏统一的应用一致性协调接口，产品在 Linux 环境中提供的是文件系统一致性的数据保护能力：

• 数据状态等价于操作系统异常重启后的磁盘状态
• 系统不强制介入数据库事务或应用内部逻辑
• 数据恢复过程依赖数据库自身的日志机制和自恢复能力

在此模式下，产品的核心职责是提供一个稳定、可重复的数据基础状态，并通过灾备演练验证数据库或应用是否能够完成其原生恢复流程。

3. 无代理模式（Agentless）

在云环境或虚拟化平台中，产品无代理(Agentless)模式基于平台原生磁盘快照能力获取数据：

• 提供崩溃一致性的数据状态
• 无需在虚拟机内部署任何组件
• 不与操作系统或应用进行交互

该模式具备高度兼容性和低侵入性，适合大规模环境快速部署。 对于无代理(Agentless)模式，产品明确建议结合定期灾备演练，用于验证业务系统在灾备环境中的实际可恢复性。

4. 数据库场景适用性说明

对于依赖日志完成恢复的数据库系统，其恢复成功高度依赖日志的完整性和一致性。

在数据库场景中，产品的技术定位如下：

• 不替代数据库原生备份或归档机制
• 不承诺完全自动化、零人工干预的数据库恢复
• 不支持特定集群或特殊存储架构的数据库部署模式

产品的核心价值在于： 通过灾备演练，验证数据库实例是否能够按照其原生启动与恢复路径成功完成恢复。 只有在演练中验证通过的数据库恢复结果，才被视为具备实际业务可用性的灾备数据。

总结

产品并未将灾难恢复能力简单等同于某一种一致性模型，而是构建了一套以工程验证为核心的数据保护与恢复体系：

• 在数据源侧，遵循操作系统、数据库及平台的原生机制进行数据采集
• 在灾备侧，通过持续、可重复的灾备演练验证数据的真实可恢复性
• 以实际恢复结果作为评估数据完整性和灾备能力的最终标准

该设计模式不仅提升了系统整体稳定性，也有效降低了灾难恢复方案在实际落地过程中所面临的不确定性风险。

数据同步原理

Linux 代理(Agent)

Linux 代理(Agent)主要由用户态和内核态模块组成。内核态模块负责捕获 I/O 变化，实时监控文件系统的读写操作；用户态模块则将捕获到的数据通过不同协议传输至目标存储，并管理全量和增量备份的流程。通过内核态和用户态模块的协同工作，Linux 代理(Agent)能够高效地执行数据同步和备份任务。

Linux 代理(Agent)内核模块通过实现写时复制（COW）系统来管理快照并跟踪更改。当首次为块设备初始化时，内核模块会在驱动器上创建一个 COW 数据存储文件。内核模块拦截所有块级写操作，并在写入完成之前将即将被更改的数据复制到快照存储中。通过这种方式，即使写操作正在进行，该模块也可以维护文件系统的完整和一致的快照。快照数据由内核模块通过位于磁盘上 COW 文件开头的索引进行管理和访问。此实现使我们的写时复制系统能够在块级别可靠地维护驱动器的完整时间点镜像，从而比其他方法更稳定和一致。

Linux Agent Data Sync

Windows 代理(Agent)

Windows 代理(Agent) 分为两个主要层次：内核态和应用层。

1. 内核态驱动：负责采集所有被保护磁盘的写入I/O操作，并提供接口供应用层使用。通过两次时间标记，内核驱动能够统计所有写入I/O的序列。

2. 应用层：主要负责读取磁盘块数据并将目标数据写入（如通过iSCSI或OSS）。为提高数据同步效率并解决一致性问题，应用层采用微软的卷影复制服务（VSS）技术，支持创建卷快照并利用写时复制（COW）原理保持快照数据的一致性。

3. 快照与同步：数据同步基于块级别，应用层分析每个被保护磁盘，识别每个卷的起始和结束位置，实现位置映射，从而快速定位读取磁盘的每一块数据。

4. 有效数据同步：应用层仅同步卷中的有效数据。通过读取每个卷的元数据中的位图（bitmap），计算有效和无效数据扇区，系统在数据同步时跳过无效区域，以优化同步过程。

Windows Agent Data Sync

VMware无代理(Agentless)方式

VMware 无代理(Agentless)方式的数据同步主要通过 VMware 的 Changed Block Tracking (CBT) 技术实现。CBT 是一种高效的虚拟机磁盘变更追踪技术，它能够在增量同步时，识别并捕获自上次同步以来发生变化的磁盘数据块，从而仅同步这些已变更的数据部分，极大提高了备份效率。

通过 vCenter API 或者 ESXi API，系统可以获取主机的元数据信息，如虚拟机配置、磁盘信息和虚拟机运行状态（如电源状态）等。这样，无需在每台主机上安装代理程序，就能够集中管理所有平台中的虚拟机，为后续的数据同步做好准备。

在每次同步之前，为确保磁盘数据的一致性和完整性，系统需要先调用主机的快照接口，创建虚拟机的快照。这一步骤能够确保在同步过程中，磁盘数据保持一致，避免了虚拟机在同步时被修改而导致的同步数据不一致问题。

在增量备份过程中，CBT 机制会标记磁盘中已修改的数据块（Changed Blocks）。通过这种方式，系统能够高效地识别并仅同步这些变化的数据，而无需重新传输整个虚拟机的磁盘内容。这样，不仅节省了带宽和存储空间，还显著减少了备份所需的时间。

VMware Agentless Data Sync

OpenStack Ceph无代理(Agentless)方式

在无代理(Agentless)模式下，基于Ceph存储的OpenStack云平台的数据同步依赖于源端同步代理节点、Ceph存储和OpenStack API接口之间的协作。该同步方式通过增量快照技术，确保数据同步过程高效且带宽利用最大化。以下是该数据同步原理的详细描述：

注意：当前该同步模式仅适用于使用Ceph存储并支持RBD连接的OpenStack平台，且OpenStack API未做修改。对于采用商业化存储的OpenStack平台，该模式暂时不支持。

OpenStack Ceph Agentless Data Sync

1. 源端同步代理节点

源端同步代理节点需要具备以下两种访问能力：

• OpenStack API接口访问：用于获取OpenStack虚拟机的状态信息，执行虚拟机实例的快照操作，以及查询虚拟机的其他相关信息。
• Ceph存储网络访问：用于读取Ceph存储池中的元数据信息，特别是Ceph快照的增量数据，通过差异比较来识别和同步变化的数据块。

源端同步代理节点通过OpenStack API获取虚拟机的状态信息并触发快照操作。同时，该节点还需要通过Ceph存储网络获取与快照相关的元数据（包括块设备的版本信息、修改时间戳等），以便进行增量数据的比较和同步。

2. 快照操作

在增量同步过程中，首先，源端同步代理节点会通过OpenStack API接口对目标虚拟机执行快照操作，生成虚拟机当前状态的完整数据快照。接着，系统通过调用Ceph的RBD接口，获取与该快照关联的Ceph快照元数据信息。通过这些元数据，系统能够识别哪些数据块在上次快照之后发生了变化。

3. 差量数据比较

在获取当前快照和上次快照的元数据信息后，系统将对比两者的差异，识别出已发生变化的数据块。差异比较过程基于Ceph增量快照机制，系统通过对比元数据中的版本信息、修改时间戳等特征，精确识别需要同步的数据块。变化的数据块被标识后，源端同步节点将通过Ceph存储网络读取这些数据块的内容，并准备将其同步到目标存储。

4. 数据同步至目标存储

一旦变化的数据块被识别，源端同步代理节点将这些差异数据同步到目标存储。通过增量同步的方式，系统仅同步发生变化的数据，显著降低了带宽需求并减少了不必要的存储占用。此策略确保了数据同步的高效性和最小化的资源消耗。

5. 快照清理

数据同步完成后，源端同步节点会执行快照清理操作。具体而言，它将删除上一次的快照，并保留当前快照，以便用于下一次的差量数据比较。此操作有助于有效释放存储空间，同时确保同步过程的连续性与一致性，避免了存储的冗余与不必要的资源占用。

AWS无代理(Agentless)方式

AWS EC2 无代理(Agentless)同步模式的优势主要得益于 AWS 云平台提供的 AWS EBS Direct API。这项技术使用户能够在无需安装任何代理(Agent)的情况下，快速高效地对 EC2 实例进行备份和数据同步。AWS EBS Direct API 的工作原理与 VMware CBT（Changed Block Tracking）有一定的相似性，利用 REST API 提供接口，使得这一功能不仅灵活且易于集成。与传统的代理(Agent)方式相比，EBS Direct API 无代理(Agentless)备份模式显著降低了操作复杂度，并提升了备份任务的性能。

需要特别指出的是，当前在全球范围内的主要云平台（无论是公有云还是私有云），只有 AWS 提供了这种无代理(Agentless)接口的能力，允许用户在不部署代理(Agent)程序的情况下，对云主机进行备份和数据同步。这一模式极大简化了运维流程，减少了部署和维护代理(Agent)的负担，同时也有效降低了对主机性能的影响。

尽管 Oracle Cloud 也提供了类似的解决方案，但其实现方式与 AWS 的有所不同。Oracle Cloud 并没有通过 REST API 提供无代理(Agentless)备份功能，而是通过 SCSI（Small Computer System Interface）协议中的底层特性来实现。这种方式相比于 AWS 的 REST API 方法，在集成和应用上显得更加复杂，且灵活性较差。

对于其他云平台，如微软 Azure、Google Cloud、阿里云、华为云等，当前依然主要依赖代理(Agent)方式进行数据同步。尽管这些云平台也提供了强大的云存储服务，但它们尚未支持通过 REST API 或类似的无代理(Agentless)技术，直接对云主机进行备份和数据同步。因此，用户在这些平台上进行备份时，仍然需要通过代理(Agent)来实现增量同步或全量备份。如果要实现无代理(Agentless)的同步方式，需要云平台主动开放相关接口和能力，现阶段其他平台尚无法通过无代理(Agentless)方式进行数据同步。

综上所述，AWS 通过 EBS Direct API 提供的无代理(Agentless)同步模式，是目前唯一支持这一技术的云平台之一。这一创新功能为用户提供了更加便捷、可靠的备份解决方案，同时也推动了无代理(Agentless)备份技术在云计算领域的发展。随着无代理(Agentless)同步技术的成熟，我们有理由相信，未来会有更多的云平台跟随 AWS 的步伐，推动这一技术的普及。

更多详细的内容请参考：深入AWS无代理模式

Huawei FusionCompute无代理(Agentless)方式

Huawei FusionCompute 是一款虚拟化平台，支持通过无代理(Agentless)方式进行数据同步，其增量快照功能与 VMware 的 Changed Block Tracking（CBT）技术相似。FusionCompute 通过 API 和 Socket 接口获取增量快照数据，进而进行数据同步。具体而言，API 用于请求增量快照信息，而 Socket 接口则用于实时传输增量数据。

与 VMware 不同，FusionCompute 并未抽象出虚拟机存储层（Datastore）。VMware通过虚拟化管理程序（hypervisor）直接与虚拟机的磁盘（VMDK）交互，它能够感知虚拟机磁盘的变化并进行增量追踪， 因此在实现增量快照（CBT）时，必须在每台物理主机上安装一个轻量级的代理(Agent)。这个代理(Agent)负责监控本地主机的存储层，并捕获每个虚拟机的增量变化数据。由于缺少存储层抽象，FusionCompute 依赖主机级代理(Agent)作为补充来实现类似 VMware 的增量同步功能。

Huawei FusionCompute Agentless Data Sync

Oracle Cloud无代理(Agentless)方式

Oracle Cloud提供的无代理(Agentless)备份方案利用SCSI协议的GET LBA STATUS命令实现块级别的差量复制。该方案通过SCSI协议的底层硬件控制能力，精确检测存储卷上的数据块变化。具体实现流程如下：

1. 创建卷组备份：为确保数据完整性，首先创建主机卷的一致性备份组。
2. 生成增量卷：基于前后两次备份的OCID，创建包含变更数据块的增量卷。
3. 挂载存储卷：通过iSCSI协议将增量卷挂载至Linux实例。
4. 识别变更数据并同步：利用SCSI GET LBA STATUS命令扫描挂载卷，识别并提取变更数据块，并同步至目标存储。
5. 清理资源：完成同步后，依次执行卷的断开连接、卸载和删除操作。

Oracle Cloud Agentless Data Sync

参考文档

• Announcing OCI Block Volume Direct APIs for changed block tracking between backups
• Direct APIs for Changed Block Tracking Between Two Backups

代理与无代理方式对比

HyperMotion 与 HyperBDR 提供两种部署模式：无代理(Agentless)模式和代理(Agent)模式。根据迁移或灾备需求选择最适合的方案。

使用场景

无代理(Agentless)模式（推荐）

• 迁移场景：适合大规模虚拟机迁移和跨平台迁移。集中控制和块级访问提升效率。
• 容灾场景：无侵入式部署，集中管理，快速恢复，运维负担低。

代理(Agent)模式（备选）

• 特殊环境：节点或操作系统不支持无代理(Agentless)部署，或对应用/数据库完整性要求严格时使用。
• 高一致性要求：关键业务应用或数据库需要高一致性时，提供更精细的控制和保障。

快速决策参考

• 大规模环境或运维成本敏感 → 无代理(Agentless)模式
• 关键应用或数据库一致性要求高 → 代理(Agent)模式
• 迁移效率优先 → 无代理(Agentless)模式
• 快速恢复需求 → 两种模式均支持

功能对比

功能/属性	无代理(Agentless)模式	代理(Agent)模式
部署架构	无需在被保护节点安装代理(Agent)。通过虚拟化/云 API 实现集中管理和数据捕获。部署快速，依赖少。	需在每个被保护节点安装备份代理(Agent)。直接访问文件系统和应用，提供细粒度数据捕获和管理。
安装与维护	无需逐节点安装。集中管理，升级简单。适合大规模快速部署。	需在每个节点安装、升级和维护代理(Agent)。大规模环境下运维负担较高。
部署前置条件	无需提供操作系统用户名密码、主机安全软件配置或操作系统权限。	需要提供操作系统用户名和密码、配置主机安全软件（防火墙、杀毒软件等）、授予操作系统权限（root/Administrator）。
资源开销	低。不占用节点本地 CPU/内存。对生产负载影响小。	代理(Agent)占用节点本地资源。节点数量多时性能影响明显。
管理复杂度	低。统一策略调度，无需单独管理代理(Agent)。	高。需跟踪每个节点的代理(Agent)状态、版本和兼容性。
一致性保障	通过存储快照实现崩溃一致性（Crash Consistent）。适合快速恢复虚拟机和块数据。	直接访问节点系统和应用，实现文件系统一致性。Windows 平台结合 VSS 可提供有限的应用和数据库一致性。
RPO	分钟级。依赖快照或代理节点调度。支持批量快速数据捕获。	分钟级。代理(Agent)执行备份策略，可动态调整。
RTO	支持 Boot-in-Cloud 自动恢复。	支持 Boot-in-Cloud 自动恢复。
安全性	攻击面小。无需在节点安装额外软件，减少安全风险和开放端口。	风险较高。代理(Agent)运行需开放端口和权限，需要额外安全控制。
运维负担	低。集中管理，易于快速上线和扩展。	中到高。每节点需部署、监控和升级代理(Agent)。复杂环境下运维成本增加。

数据压缩功能原理介绍

使用方法

在我们的系统中，用户可以在主机同步开始之前，通过前端的同步设置来启用或关闭压缩功能。具体来说，在选择主机后，进入同步设置界面，在这里可以看到一个压缩选项。通过勾选或取消勾选该选项，用户可以开启或关闭压缩功能。

需要注意的是，默认情况下，为了考虑到压缩对资源的消耗，系统默认是关闭压缩功能的。如果用户希望在同步过程中启用压缩，则需要在同步开始之前进行设置，或者在同步开始后暂停同步，再重新启用压缩。

技术原理

在我们的数据同步技术中，我们采用块级别的数据同步方式。默认情况下，数据会按照每个数据块约1MB的大小进行切分。在传输过程中，如果启用了压缩功能，系统会对每个1MB的数据块进行压缩，从而提升网络传输效率。

与传统的文件级压缩不同，我们的压缩是基于块级别的，这使得操作系统的存储特性对压缩比率产生影响。同时，数据类型也会影响压缩的效果。不同类型的数据（如文本、图像、二进制数据等）在压缩时的效果各异，有些数据类型更容易被压缩，而有些则不那么明显。

此外，操作系统的存储机制也会导致实际写入的数据量与感知到的同步数据量之间的差异。这种写放大效应会让实际的同步数据量可能高于原始数据量。而我们的压缩功能，正是为了平衡这种由操作系统存储特性带来的数据膨胀，从而避免数据量的过度增加。

因此，压缩的主要目的是为了抵消操作系统带来的写放大效应，而不是单纯地追求传统的压缩比率。

压缩比例说明

根据我们的实际测试经验，不同类型的数据在块级压缩下的效果存在差异。但由于实际环境中数据通常是混合的，以下压缩比仅用于参考：

• 文本与结构化数据（日志、JSON、CSV 等）：大约可减少 30% 的数据量。
• 数据库文件（MySQL/PostgreSQL 数据文件、WAL、SQLite 等）：大约可减少 10% 的数据量。
• 已压缩多媒体与二进制数据（JPEG、PNG、MP3/MP4、压缩包等）：额外压缩空间有限，一般减少不到 10%。
• 混合型与应用数据（应用目录、虚拟机镜像、容器数据、缓存文件等）：大约可减少 10%–20% 的数据量，具体取决于数据构成。

说明： 这些压缩比为保守参考值，实际效果会因数据混合比例、写入模式以及操作系统存储机制而有所不同。在真实混合数据环境下，压缩收益可能低于上述范围。

数据传输及存储占用说明

在数据传输阶段，无论是块存储还是对象存储，系统都会先对数据进行压缩，然后传输压缩后的数据，以降低网络带宽占用。

• 块存储模式：数据在接收端的块设备上会被解压缩后存储，因此存储占用量通常大于传输量。
• 对象存储模式：数据以压缩后的形式直接存储在对象存储中，只有在恢复或读取时才进行解压缩，因此存储占用量与传输量基本一致。

这种设计确保了传输过程的高效，同时根据存储模式不同，优化存储占用和恢复性能。