18.1 备份类型：全量备份、增量备份、物理备份、逻辑备份

备份是数据库运维的生命线。没有备份的数据库，就像没有刹车的高速列车——一旦出事，后果无法挽回。MySQL 的备份方案可以从两个维度来分类：按备份的数据范围（全量与增量），以及按备份的内容形式（物理与逻辑）。这两个维度是交叉的，比如你既可以做全量的物理备份，也可以做全量的逻辑备份。理解它们的本质区别，才能根据业务需求设计出合理的备份策略。

18.1.1 全量备份

全量备份是指备份数据库在某一时刻的完整副本，包含了该时刻的所有数据、表结构、存储过程等数据库对象。

全量备份的核心特点：

自包含且独立可恢复：一份全量备份本身就是一个完整的数据库快照，不依赖其他备份文件就能直接恢复出一个可用的数据库实例。
恢复速度相对较快：恢复时只需导入或回放这一份文件，不需要逐份应用增量。在争分夺秒的故障恢复中，这是巨大的优势。
备份时间长、体积大：随着数据库规模增长，备份的耗时和磁盘占用量都会线性增加。对于一个 500GB 的库，全量备份可能需要数小时，这是无法回避的物理限制。

全量备份通常作为备份策略的“锚点”。即便你配置了更精细的增量备份，也必须有定期的全量备份作为基础，否则恢复时需要拼接的增量链条太长，既慢又容易出错。在运维实践中，最常见的策略是“每日一次全量备份 + 持续增量备份”，这样恢复时最多只需要全量备份当天加上之后的少量增量。

18.1.2 增量备份

增量备份是指只备份自上一次备份以来发生变化的数据。在 MySQL 中，增量备份主要基于 Binlog（二进制日志）来实现。

Binlog 记录了所有对数据库进行修改的 SQL 语句（或行级别的变更），它本身就是一份连续的变更流。你可以把 Binlog 文件理解为 MySQL 原生的增量备份介质。增量备份的做法通常是：

先做一次全量备份，记录下当时的 Binlog 位点（文件名 + 偏移量）。
之后定期备份在此期间产生的 Binlog 文件，这就是增量。
恢复时，先恢复全量备份，再从定位的位点开始回放 Binlog，将数据滚动到期望的时间点。

增量备份的核心价值在于：

备份速度快、体积小：只备份变化数据，大幅减少了对生产系统的影响和存储开销。对于写操作占比不高的业务，效果尤其明显。
支持时间点恢复（PITR）：全量备份只能恢复到备份时刻的状态，而结合 Binlog，你可以将数据恢复到任意指定的秒。这是应对人为误操作（比如错删了一张表）时最关键的能力。
灵活性高：你甚至可以只备份 Binlog 文件本身，而不对主库做额外的物理拷贝。很多公司会用脚本在从库上解析 Binlog 做备份，完全不干扰主库。

但增量备份也有其脆弱的一面：恢复依赖于全量备份和完整的增量链。如果中间的某一段 Binlog 丢失或损坏，后面的增量就全部无效了。因此，Binlog 文件的妥善保管（异地存储、多副本）与备份文件同等重要。

生产环境中，全量备份和增量备份从来不是二选一，而是必须配合使用：全量提供高效的基础恢复点，增量提供精准的时间点恢复能力。两者缺一不可。

18.1.3 物理备份

物理备份是指直接拷贝数据库的原始数据文件，包括表空间文件（.ibd）、表结构文件（.frm）、日志文件、配置路径等。它备份的是 InnoDB 在磁盘上实际存储的数据块。

物理备份的核心特点：

备份与恢复速度极快：因为是直接拷贝二进制文件，不经过 SQL 解析和重构索引的过程，备份和恢复的效率远高于逻辑备份。一个 500GB 的库，物理恢复可能只需半小时，而逻辑恢复可能需要数小时甚至更久。
与存储引擎紧密相关：物理备份工具需要理解 InnoDB 的页结构和日志机制，跨版本、跨平台的兼容性需要注意。你用 XtraBackup 在 Linux 上备份的文件，通常不能直接在 Windows 上恢复使用。
支持热备份（Hot Backup）：借助 XtraBackup 这类工具，可以在数据库正常提供服务的同时进行备份，不阻塞读写操作。这是物理备份相比早期文件拷贝方案的最大进步。
压缩与增量支持：XtraBackup 支持流式压缩和在物理层面的增量备份（对比 LSN 只拷贝变化过的数据页），进一步降低了空间占用。

物理备份的首选工具是 Percona XtraBackup，它是开源的 MySQL 物理热备份工具，专为 InnoDB 和 XtraDB 设计。它通过后台线程读取数据文件并解析 Redo Log 来确保备份一致性，是生产环境中使用最广泛的 MySQL 物理备份方案。mysqldump 虽然普及，但那是逻辑备份工具，不要混淆。

物理备份最适合用于大面积数据恢复和快速搭建从库的场景。它也通常作为全量备份的常规手段，与增量备份（Binlog）配合，形成“全量物理 + 增量 Binlog”的黄金组合。

18.1.4 逻辑备份

逻辑备份是指将数据库里的数据结构和数据内容导出为可读的 SQL 语句文本。它备份的不是磁盘上的文件，而是逻辑层面的表结构和行数据。

逻辑备份的典型工具是 MySQL 自带的 mysqldump，以及功能更强的 mydumper（多线程并行导出工具）。当你执行 mysqldump --all-databases > backup.sql 时，得到的 backup.sql 文件里就是一堆 CREATE TABLE、INSERT 等语句。

逻辑备份的核心特点：

高度可移植：生成的 SQL 文件是纯文本，跨版本、跨平台、甚至跨数据库系统的迁移都非常方便。你可以把一个 MySQL 5.7 的备份导入到 MySQL 8.0，甚至经过少量修改后导入到其他数据库。
灵活粒度选择：可以只备份某个库、某张表、甚至只备份表结构不含数据。mysqldump 的 --where 参数还支持按条件导出部分行，这是物理备份做不到的。
可读可审查：因为是 SQL 文本，你可以打开文件查看内容，确认导出了什么数据。在数据清洗、审计、测试环境搭建等场景中，这种透明度很宝贵。
备份恢复速度慢：恢复时需要逐条解析并执行 SQL，还要重建索引、校验约束，速度远慢于物理备份。大数据量下恢复耗时会非常长，甚至成为不切实际的方案。
一致性需要额外保证：mysqldump 默认逐表导出，如果导出过程中其他表仍在写入，会出现跨表数据时间点不一致的风险。使用 --single-transaction 参数可以在一个事务中读取数据，保证 InnoDB 表的一致性导出版本，这是生产导出中必须加上的参数。对于 MyISAM 表则只能使用 --lock-tables 加锁导出。

逻辑备份更适合用于数据量较小的库（通常在几十 GB 以内）、跨版本迁移、表级别的数据恢复、或者作为物理备份的补充手段。当物理备份因版本不兼容而无法恢复时，逻辑备份往往是最后的救命稻草。

在实际运维中，备份策略通常是多维组合的，而不是单选一种类型。一个成熟的生产环境备份方案通常包括：

| 备份类型 | 常用工具 | 频率 | 用途 |
|---------|---------|------|------|
| 全量物理备份 | XtraBackup | 每日 | 快速恢复的主备份 |
| 增量逻辑备份 | Binlog 持续归档 | 持续 | 时间点恢复（PITR） |
| 逻辑备份 | mysqldump / mydumper | 按需 / 每周 | 表级恢复、数据导出、跨版本迁移 |