📚 课程目录第1章备份基础概念

1. 备份基础概念：为什么需要备份、RPO与RTO的定义、备份的3-2-1原则

1.1 为什么需要备份？—— 不是选择题，是生存题

说实话，我入行头两年也犯过嘀咕：备份这活儿，又占磁盘又耗CPU，天天跑，真有必要吗？

直到有一次，我在一家电商公司做运维。凌晨三点，某位同事手滑，一条 DROP TABLE 直接落在了线上订单库。整个运营团队炸了锅，老板拍桌子问「数据能恢复吗？」。我打开备份目录一看——上次全量备份是七天前，增量日志因为磁盘满已经三天没写进去了。结果？丢了将近四万条订单记录。

那次之后，我养成了一个习惯：任何系统上线，第一件事不是调性能，而是确认备份策略。

血的教训： 数据丢失的原因远不止「手滑」。硬件故障（磁盘坏道、电源烧毁）、软件Bug（存储引擎崩溃）、人为误操作（删表、改错数据）、勒索病毒加密、甚至机房火灾/水淹——任何一条都足以让一家公司直接关门。备份不是「万一」，而是「一万」。

你想想看，数据库里存的是什么？用户信息、交易记录、财务报表。这些数据丢了，不是重装个系统就能解决的。备份，说白了就是给数据买了一份「意外险」。保费（存储成本）远低于理赔（数据丢失）的代价。

1.2 RPO 与 RTO：两个你必须背下来的数字

聊备份，绕不开两个词：RPO 和 RTO。我面试DBA时，必问这两个概念。答不上来的，基本可以判断没做过真正的容灾演练。

指标	全称	通俗理解	核心问题
RPO	Recovery Point Objective	你能容忍丢多少数据	最后一次备份到故障时刻，丢了多久的数据？
RTO	Recovery Time Objective	你能容忍停多久业务	从故障发生到业务恢复，花了多长时间？

举个例子你就明白了。假设你的RPO是1小时，那就意味着每1小时必须做一次备份（或者至少把binlog/归档日志完整保留1小时）。如果凌晨2:05数据库崩了，而最后一次备份是2:00，那最多丢5分钟的数据——在RPO容忍范围内。

RTO呢？如果业务方说「最多停30分钟」，那你的恢复流程必须在30分钟内跑完。从发现故障、切换备库、恢复全量、应用日志到验证数据，每一步都要卡秒表。

我的经验： 很多团队把RPO/RTO写在文档里，但从来没验证过。我建议你至少每季度做一次「真刀真枪」的恢复演练——关掉主库，掐表计时，看能不能在规定时间内把业务拉起来。纸上谈兵和实战是两码事。

这里有个常见的坑：RPO和RTO是矛盾的。RPO越小，备份频率越高，占用的存储和网络带宽越大；RTO越小，恢复手段越贵（比如实时同步的灾备集群）。你需要跟业务方坐下来，算一笔账：丢1小时数据损失多少钱？停1小时业务损失多少钱？然后倒推出合理的RPO/RTO。

1.3 备份的 3-2-1 原则：黄金法则

这个原则我几乎在每个项目里都会强调。它不是什么高深理论，就是一个简单到不能再简单的规则：

3 —— 保留至少 3 份 数据副本
2 —— 使用 2 种不同 的存储介质
1 —— 至少 1 份 存放在异地

为什么是3份？因为两份不够。我曾经见过一个案例：某公司把主库和备份库放在同一台物理机的两个磁盘分区上。结果磁盘控制器坏了，两个分区同时挂掉——等于没备份。3份副本，意味着即使其中两份同时出问题，你还有最后一张底牌。

为什么是2种介质？磁带、磁盘、SSD、云存储、光盘……不同介质的故障模式不同。磁盘可能坏道，磁带可能受潮，云存储可能遇到厂商服务中断。混搭能降低「一锅端」的风险。

为什么是1份异地？这个不用多说了吧。机房火灾、洪水、地震——虽然概率低，但一旦发生，本地所有副本全灭。异地备份就是你的「诺亚方舟」。

落地建议： 我个人的习惯是：本地磁盘保留一份最近7天的增量备份，NAS或另一台服务器保留一份全量备份，云存储（比如阿里云OSS或AWS S3）再放一份跨区域的归档备份。这样即使本地机房被端了，云上还有数据。

下面这张图帮你把 3-2-1 原则串起来：

1.4 备份类型：全量、增量、差异，怎么选？

搞清楚了「为什么备份」和「备份原则」，接下来得聊聊「怎么备份」。常见的备份类型有三种，我直接给你列个对比：

备份类型	备份内容	恢复速度	存储空间	典型场景
全量备份	整个数据库	最快（只需恢复一份）	最大	每周一次，作为恢复基线
增量备份	上次备份后变化的数据	最慢（需全量+所有增量链）	最小	高频备份（每小时/每天）
差异备份	上次全量备份后变化的数据	中等（需全量+最后一次差异）	中等	全量之间的补充备份

我个人习惯的组合是：每周日全量 + 每天差异 + 每小时增量。这样恢复时，先恢复最近一次全量，再应用最近一次差异，最后回放增量日志。既控制了存储成本，又保证了恢复速度。

注意： 增量备份有个「链式依赖」问题。如果中间某个增量文件损坏了，它之后的所有增量都无法应用。我曾经遇到过备份脚本Bug，导致某天的增量文件写了一半就结束了，结果恢复时卡在那一点，后面的数据全废了。所以，定期做增量备份的完整性校验，别等到恢复时才发现。

1.5 备份策略设计：从理论到落地

光有原则还不够，得落地。我一般按以下步骤设计备份策略：

跟业务方对齐 RPO/RTO —— 这是所有决策的输入
选择备份工具 —— mysqldump、XtraBackup、pg_dump、pgBackRest、SQL Server 原生备份等
制定备份计划 —— 全量频率、增量频率、保留周期
选择存储方案 —— 本地 + 异地，磁盘 + 云存储
编写自动化脚本 —— 定时任务 + 告警通知
定期演练 —— 至少每季度一次完整恢复测试

嗯，这里要特别强调一点：备份脚本一定要有告警。我见过太多「备份静默失败」的案例——脚本跑了，但磁盘满了、权限不对、网络断了，备份文件是0字节，运维却完全不知道。等到恢复时才发现，已经晚了。

我的小技巧： 每次备份完成后，除了检查返回码，还要做两件事：一是校验备份文件的大小是否在合理范围内（比如全量备份至少应该大于某个阈值）；二是随机抽取一个备份文件，尝试恢复到一个临时实例上，验证数据可读性。自动化脚本里加上这两步，能拦截90%的「假备份」。

好了，这一章的内容就这些。记住三个核心：为什么备份（生存问题）、RPO/RTO（量化指标）、3-2-1原则（黄金法则）。后面的章节，我们会深入具体的备份工具和恢复实战。