📚 课程目录第1章云原生备份概述

云原生环境的数据备份方案快照恢复恢复对象存储部署实战 - 第1节

1. 云原生备份概述：为什么传统备份在K8s中失效

各位同学好。我是老张，在SRE和云原生这块摸爬滚打了快十年。今天咱们聊一个很实在的话题——云原生环境下的数据备份。

说实话，我见过太多团队把传统备份方案直接搬到Kubernetes上，结果呢？要么备份出来的数据根本用不了，要么恢复的时候发现数据早就坏了。为什么会这样？

咱们先搞清楚一个问题：传统备份在K8s里到底哪里不行？

我刚开始接触K8s备份时，也踩过不少坑。后来总结下来，传统备份在云原生环境里失效，主要有三个原因。

问题	传统备份做法	K8s环境下的困境
Pod是临时性的	备份Agent安装在固定IP的服务器上	Pod随时可能被调度到其他节点，Agent跟着漂移，备份任务断掉
存储是解耦的	直接备份本地磁盘或SAN存储	PV/PVC是动态分配的，底层可能是NFS、Ceph、云盘，传统工具认不出来
应用是多实例的	单机备份，顺序执行	StatefulSet有3个副本，每个副本的数据必须保持一致，否则恢复后数据错乱

嗯，这里要注意。传统备份工具大多是为物理机或虚拟机设计的。它们假设：服务器是固定的、磁盘是直连的、应用是单体的。但在K8s里，这些假设全都不成立。

我曾经踩过的坑： 有一次帮客户做MySQL集群备份，直接用传统的mysqldump脚本在每个Pod里跑。结果备份到一半，Pod被重新调度了，备份文件只写了一半。恢复的时候才发现数据不一致，差点酿成事故。从那以后，我再也不敢用这种"土办法"了。

说白了，K8s备份要解决三个问题：

你想想看，如果一个备份方案还需要你手动指定每个Pod的IP、手动挂载每个PV，那它根本不适合云原生环境。

经过这些年的实践，我个人认为，一个合格的云原生备份方案必须遵循三大原则：应用一致性、数据持久性、可移植性。下面我一个个讲。

什么叫应用一致性？简单说，就是备份出来的数据，在应用层面是完整且可用的。

举个例子。一个数据库有3个Pod，每个Pod写不同的分片。如果你只备份了其中两个Pod的数据，恢复后数据就不完整。更糟糕的是，如果备份时数据库正在写入，备份文件可能包含部分事务，恢复后数据就乱了。

应用一致性的关键点：

我个人习惯的做法是：在备份前通过K8s的PreStop Hook或自定义Operator，先通知应用进入备份模式，等所有写操作完成后，再开始备份。这样能最大程度保证一致性。

数据持久性，说白了就是备份数据不能丢，而且要能扛得住各种故障。

我记得有一次，客户把备份数据存在同一个集群的另一个PV里。结果集群挂了，生产数据和备份数据一起丢了。这就是典型的"把鸡蛋放在一个篮子里"。

持久性等级	做法	适用场景
L0 - 同集群	备份到集群内的另一个PV	临时测试，不推荐生产
L1 - 跨集群	备份到另一个K8s集群的存储	同机房容灾
L2 - 跨地域	备份到异地对象存储（如S3、MinIO）	异地容灾，推荐生产使用
L3 - 不可变存储	备份到WORM（Write Once Read Many）存储	防勒索病毒，合规要求

我的建议： 生产环境至少做到L2级别。我一般会把备份数据同时存到两个不同的对象存储（比如AWS S3和自建MinIO），这样即使一个挂了，另一个还能用。

可移植性，就是备份数据要能在不同的环境里恢复。不能只在一个集群里能用，换个环境就废了。

你想想看，如果你的备份方案强依赖某个云厂商的存储快照API，那换到另一个云厂商或者自建机房，备份数据就恢复不了。这叫什么？这叫厂商锁定。

可移植性要求备份数据满足以下条件：

注意： 可移植性不等于"一次备份到处恢复"。不同环境的K8s版本、存储类、网络配置可能不同，恢复时可能需要做一些适配。但至少备份数据本身不能有环境依赖。

这三个原则不是孤立的，它们互相支撑。我画了一张图，帮你理解它们的关系。

从图上你能看出来，这三个原则是等价的，没有哪个更重要。我见过一些团队只关注数据持久性，把备份存到三个不同的存储后端，但备份时没做一致性处理。结果恢复出来的数据全是错的，存再多副本也没用。

好了，这一章的内容就这些。咱们总结一下：