📚 课程目录第3章数据块追踪技术

3. 数据块追踪技术：如何识别变化的数据块？CTP（Change Tracking Pointer）原理

增量备份的核心问题，说白了就一个：你怎么知道哪些数据块变了？

全量备份简单粗暴——把所有数据读一遍，管它变没变。但增量备份不行，你得精准地找到“变化的部分”。我早年做存储系统时，第一次实现增量备份，天真地以为用文件修改时间就够了。结果呢？一个大文件只改了 4KB，我却要扫描整个文件，性能惨不忍睹。

后来我接触到了 CTP（Change Tracking Pointer）技术。这玩意儿，才是真正解决“如何识别变化数据块”的利器。

在讲 CTP 之前，我们先看看为什么传统方法不行。你想想看，要判断一个数据块是否变化，最直接的办法是什么？

我在一个项目中遇到过这种情况：一个 10TB 的 NAS 存储，每天只有不到 1% 的数据变化。但用传统哈希比对法，每次增量备份要跑 6 个小时，因为光算哈希就把磁盘 IO 打满了。用户问我：“你们这增量备份，怎么比全量还慢？” 我哑口无言。

注意： 不要依赖文件修改时间做增量判断。数据库、虚拟机镜像、日志文件等场景下，时间戳的“假阳性”率极高，会导致备份数据量暴增。

CTP 的思路很直接：与其事后去算数据变没变，不如在数据变化的那一刻就记下来。

它维护一个指针结构，指向存储系统中的每一个数据块。当有写入操作发生时，CTP 会自动标记对应的指针为“已变化”。备份软件只需要读取这些指针，就能知道哪些块需要备份，完全不用去碰数据本身。

我习惯把 CTP 理解成一个“脏位表”。就像你洗衣服前，在脏衣服上贴个标签。洗的时候，你只看标签，不用把每件衣服都闻一遍。

CTP 的实现通常分为三个层次：

备份软件在运行时，只需要扫描这个位图，找到所有脏位为 1 的块，读取它们，然后备份。备份完成后，将脏位清 0。

整个过程，数据只读一次，而且只读变化的部分。效率极高。

关键点： CTP 的粒度决定了备份的精度和开销。块越小，备份越精细，但位图越大，管理开销也越大。块越大，位图越小，但可能备份了未变化的数据（内部碎片）。

下面这张图，是我当年做项目时画的架构草图。它展示了 CTP 在备份系统中的位置。

CTP 的块大小，是个需要权衡的参数。我见过不少团队在这个问题上栽跟头。

我个人习惯，对于大多数通用场景，64KB 的块大小是一个不错的起点。如果发现备份数据量偏大，可以调小；如果发现 CPU 开销过高，可以调大。

CTP 虽然强大，但也不是银弹。我踩过几个坑，分享给你：

位图持久化：CTP 的脏位图必须持久化存储。如果系统崩溃，位图丢失，下次备份就只能全量了。我曾经因为位图存储在内存中，一次断电导致所有脏位信息丢失，第二天备份跑了 8 小时全量。
并发写入冲突：多个线程同时写入同一个块，CTP 驱动需要保证脏位的原子性更新。否则可能漏标记。
快照与 CTP 的配合：如果底层使用了快照，CTP 的脏位需要和快照的 COW（写时复制）机制协同。否则可能出现“快照已经记录了变化，CTP 又记录一次”的重复工作。

经验之谈： 实现 CTP 时，建议将脏位图存储在非易失性内存（NVDIMM）或 SSD 上的专用区域。既保证性能，又保证持久性。我曾在项目中用 NVDIMM 存储位图，重启后位图还在，增量备份直接继续，体验极好。

CTP 技术本身也在进化。现在的存储系统，比如 VMware 的 CBT（Changed Block Tracking）、微软的 RCT（Resilient Change Tracking），都是 CTP 思想的变体。

它们不仅记录“哪些块变了”，还记录“变化发生在哪个时间点”。这样，你可以实现任意时间点的增量恢复，而不只是基于上一次备份。

嗯，这里要注意：CTP 的粒度决定了恢复的精度。如果你用 1MB 的块，恢复时可能多恢复一些未变化的数据，但整体速度更快。如果你用 4KB 的块，恢复更精准，但元数据操作更频繁。