始于能备，臻于全面｜Kubernetes 数据保护的演进与突破

Kubernetes 让应用的部署、调度和扩缩容更加灵活，也改变了数据保护的方式。

在 Kubernetes 环境中，应用的运行状态不仅取决于持久卷中的业务数据，还与集群控制面维护的资源对象、对象之间的关联关系，以及数据库自身的数据状态密切相关。发生误删除、数据损坏或集群故障时，仅有一份卷数据，或者一套历史 YAML 配置，并不一定能让应用回到故障前的状态。

如何让数据找得回、集群接得上、应用恢复后能够正常运行？

鼎甲迪备（DBackup）围绕 Kubernetes 数据保护与恢复，形成了从数据级、集群级到应用级的分层保护能力，并结合分布式重删存储、远程复制和归档机制，为 Kubernetes 业务提供从数据恢复到异地容灾的保护方案。

01 数据级保护：让持久卷中的业务数据可恢复

持久卷（PersistentVolume，PV）承载着 Kubernetes 应用的持久化数据。对于有状态应用而言，工作负载可以重新创建，但卷中的数据一旦丢失或损坏，应用仍然无法正常运行。

鼎甲迪备将 Kubernetes 持久卷数据备份到独立的备份存储池，与生产存储形成隔离。首次执行完全备份，后续按照数据变化执行增量备份，支持按备份时间点恢复卷数据。

数据保护不再只依赖生产环境中的原始卷及其快照。即使原存储发生故障，也可以从备份存储中取回相应时间点的数据。

数据级保护解决的是：业务数据有独立的备份副本，并且能够按需恢复。

但卷数据只是恢复的一部分。对于 Kubernetes 应用来说，数据存放在哪里、由哪个 PVC 引用、对应哪个工作负载，同样决定着恢复后能否重新运行。

02集群级保护：支持跨集群恢复与历史状态还原

Kubernetes 通过控制面维护集群资源及其关联关系。命名空间、工作负载、Service、PVC 等对象共同构成应用的运行基础。

当资源对象被误删，或者需要将应用恢复到另一套集群时，除了取回数据，还需要处理集群状态、资源依赖、环境差异和恢复范围等问题。

鼎甲迪备通过 etcd 灾难恢复、时间点恢复、转换集和过滤器等能力，分别应对这些问题。

1. 恢复集群元数据，找回原有资源关系

etcd 存储 Kubernetes 集群的资源状态，包括命名空间、工作负载、Service，以及 PVC 与卷之间的关联信息。对于线上已经调整过的副本数、配置和 Service 等信息，仅依赖较早的 YAML 文件重建，可能无法还原故障前的运行状态。

例如，命名空间或工作负载被误删后，原有卷数据可能仍然存在，但集群已经失去了相应的资源对象及其关联关系。此时，即使找回卷数据，也不代表应用能够直接恢复运行。

针对原集群控制面故障或资源状态丢失的场景，鼎甲迪备提供 etcd 灾难恢复能力，将 etcd 元数据恢复到原集群，为后续恢复工作负载和重新关联卷数据提供基础。

2. 通过环境适配方案，降低跨集群恢复的环境差异

当业务需要恢复到异集群，或者在演练环境中验证恢复结果时，源集群与目标集群的配置差异可能成为障碍。

例如，备份时使用的 StorageClass 在目标集群中不存在，PVC 就可能无法按原配置完成绑定，进而影响工作负载启动。类似的问题还可能出现在命名空间、标签和配置参数等资源属性上。

鼎甲迪备支持通过环境适配方案，在恢复过程中调整资源的命名空间、标签、配置参数和 StorageClass 等信息。源集群与目标集群的存储类名称不一致时，可以将其转换为目标集群已有的存储类名称，并通过转换预览核对写回结果。

通过环境适配方案，恢复过程不必完全依赖源集群与目标集群具有相同的资源命名和配置，可以根据目标环境的实际情况调整资源定义。

3. 通过对象级精准恢复，按需还原指定资源

当一个命名空间中运行着多个工作负载时，如果只需要找回其中一个误删的应用，却直接恢复整个命名空间，就可能对其他正常运行的资源产生影响。尤其是在选择覆盖已有同名资源时，目标资源可能先被删除，再按备份状态恢复。

鼎甲迪备支持对象级精准恢复，可以按照资源组、资源类型和指定名称设置包含或排除条件，将恢复范围限定在需要处理的对象内。例如，可以只恢复指定工作负载或 PVC，而不必恢复整个命名空间。

环境适配方案解决的是“恢复到目标环境后如何适配”，对象级精准恢复解决的是“需要恢复哪些资源”。两者配合，可以在执行恢复前明确目标环境的配置调整和资源恢复范围，减少不必要的写回操作。

集群级保护不仅要找回数据，还要恢复资源关系，并通过环境适配方案与对象级精准恢复，支持目标环境适配和指定资源的按需还原。

03应用级保护：让数据库数据具备可用的一致性基础

对于数据库等有状态应用，卷数据能够成功恢复，并不必然意味着数据库可以正常打开。

数据库运行过程中，部分数据可能仍处于内存或缓存中，尚未写入持久卷。如果直接对正在写入的卷进行备份，恢复得到的文件虽然来自同一个备份时间点，却未必满足数据库自身的恢复要求。

因此，数据库保护需要考虑应用的运行状态，而不仅是存储层的数据复制。

1. 应用一致性备份：在卷备份前协调数据库状态

鼎甲迪备支持在备份持久卷之前，通过应用一致性机制冻结数据库的新写入，将相关数据刷新到磁盘；卷备份完成后，再解除冻结。

通过这种方式，备份过程能够在应用与存储之间建立必要的协调，降低因数据尚未落盘而导致恢复异常的风险。恢复时，再结合工作负载和持久卷的时间点恢复流程，使数据库能够基于已备份的数据重新启动。

应用一致性机制的实际效果取决于数据库类型及相应的冻结实现，不能将其等同于所有数据库场景下的完整事务一致性保证。

2. 数据库逻辑备份：支持数据库对象级保护

除基于持久卷的备份方式外，鼎甲迪备还支持数据库自身的备份方式。例如通过逻辑备份方式对容器中的数据库提供数据保护。

逻辑备份以数据库逻辑对象为基础，适用于需要按数据库对象进行备份与恢复的场景，可满足相应的数据保护需求。

3. 数据库物理备份：满足大容量数据库备份需求

对于数据量较大的数据库，逻辑备份通常需要经过数据读取、逻辑解析和导出等过程，备份耗时可能随数据规模增长。物理备份则以数据库的物理数据为基础进行备份，减少逻辑层处理带来的额外开销，更适合大容量数据库的备份场景。

鼎甲迪备支持容器中 MySQL 等数据库的物理备份，为大容量数据库提供另一种备份选择，并与 Kubernetes 资源及持久卷保护相互补充，满足不同场景下的数据库保护需求。

应用级保护不仅关注 Kubernetes 资源和持久卷能否恢复，也关注数据库自身的数据状态及其备份、恢复需求。

04完善灾备体系，筑牢 K8s 数据安全防线

Kubernetes 本身具有分布式特征，数据保护也不能只关注单个卷或单个工作负载。随着集群规模扩大，备份数据的存储与加密、长期留存、异地保护、跨集群迁移和恢复演练，同样需要纳入整体方案。

鼎甲迪备将 Kubernetes 持久卷、资源对象和数据库卷等备份数据统一纳入分布式重删存储体系，并结合归档、存储池复制、跨集群迁移和恢复演练能力，形成从备份到异地保护的完整链路。

分布式存储与横向扩展： 备份数据写入分布式重删存储池，由多台存储服务器分担备份负载，并支持通过增加存储节点扩展存储能力。

全局数据重删： 对重复数据进行去重，减少备份数据的实际存储占用。

备份数据加密：备份数据可在进入存储前于代理端加密，也可在到达存储服务器后加密，算法支持 AES 与 SM4。备份集在传输和落盘后以密文保存。

归档留存： 支持将备份集归档到磁带库，构建磁盘到磁盘再到磁带的 D2D2T 留存链路。

远程复制与异地容灾： 支持将备份数据复制到异地存储池，为异地数据保护提供基础。

集群迁移： 支持将指定命名空间或工作负载恢复到另一套集群。源集群与目标集群的存储类、命名空间或标签不一致时，通过环境适配方案完成转换。

恢复演练： 支持按计划将备份集恢复到异集群，并复用预先配置的转换集和过滤器，验证恢复流程。

这些能力并非孤立的功能组合。数据级保护确保业务数据有据可依，集群级保护处理资源状态和恢复范围，应用级保护进一步考虑数据库自身的数据状态；分布式存储、重删、加密、归档与远程复制则为这些备份数据提供统一的存储和保护基础。

图

Kubernetes 数据保护的难点，不只是备份持久卷，而是如何在不同故障场景下，让数据、集群资源和应用状态重新衔接起来。

鼎甲迪备围绕数据级、集群级和应用级三个层次，提供从持久卷备份、etcd 灾难恢复、资源转换与范围过滤，到数据库一致性备份及逻辑、物理备份的多层次保护能力。

从数据找回，到资源关系重建，再到应用恢复，鼎甲让 Kubernetes 数据保护覆盖更完整的恢复链路。