在线备份适合业务不能停、数据量中等的场景
在线备份指 MySQL 服务持续运行时执行的备份，典型方式是
mysqldump --single-transaction（InnoDB）或
mysqlbackup（企业版），也包括基于 binlog 的逻辑复制或 Percona XtraBackup 的热备。
它不锁表（或仅短时锁 MDL），适合读写混合、无法接受停机的线上系统。但要注意：
mysqldump --single-transaction依赖事务一致性快照，若备份过程中有长事务未提交，会导致快照延迟、备份变慢甚至失败；而 XtraBackup 在备份期间仍会持续写入 redo log，需确保磁盘 I/O 能力足够，否则可能拖慢主库响应。 适用：Web 应用、API 服务、中小规模 OLTP 系统（单库 不适用：存在大量 DDL 操作（如频繁
ALTER TABLE）的窗口期，
--single-transaction会失效并退化为全局读锁 注意：备份文件是逻辑 SQL 或物理文件，恢复时需重放，耗时远高于离线恢复
离线备份只在可停机维护窗口内使用
离线备份要求 MySQL 完全停止，然后直接拷贝
datadir下的文件（如
ibdata1、
ib_logfile*、
.frm/
.ibd）。这种方式本质是文件系统快照，无任何数据库层开销。
但它对业务影响是硬性的：停服时间 = 关库时间 + 文件拷贝时间 + 启动时间。哪怕只有几十 GB 数据，拷贝过程也可能因磁盘吞吐受限而持续数分钟——这在多数生产环境不可接受。
适用：内部管理库、测试环境、历史归档库等允许长时间停机的场景 关键前提：必须确认innodb_fast_shutdown = 0（即彻底刷脏页、关闭 redo log），否则直接拷贝的
ibdata1可能损坏，启动时报错
InnoDB: Database page corruption on disk风险点：若备份前未执行
FLUSH LOGS，binlog 位置信息丢失，无法做基于时间点的恢复（PITR）
混合策略才是真实生产中的常见做法
纯在线或纯离线都难覆盖所有需求。实际中更常见的是“在线物理备份 + binlog 增量”组合：用 XtraBackup 做周度全量热备，再每小时
mysqlbinlog --read-from-remote-server拉取 binlog 并归档。这样既避免停机，又能实现秒级 RPO。
但要注意版本兼容性：
xtrabackup8.0 版本不能备份 MySQL 5.7 实例，反之亦然；且 8.0 默认开启
innodb_redo_log_encrypt时，XtraBackup 必须匹配对应密钥配置，否则解密失败导致备份无效。 备份脚本中必须校验
mysqld进程状态和
datadir权限，否则
xtrabackup --backup会静默失败于
Failed to open ./ibdata1恢复前务必先
xtrabackup --prepare，否则直接拷回
datadir启动会报
InnoDB: Ignoring data file ./ibdata1binlog 备份路径需独立于 MySQL 数据目录，防止磁盘满导致主库 hang 住
备份验证比备份本身更容易被忽略
很多团队定期跑通
mysqldump或
xtrabackup --backup就算完成任务，但从没验证过能否真正恢复。一次真实故障中，某集群备份脚本里漏写了
--databases参数，导致
mysqldump默认导出所有库，但恢复时只指定了单个库名，结果导入空库还误以为成功。
验证不是“看看文件大小”，而是要实打实拉起临时实例，执行
mysql 或 <code>xtrabackup --copy-back后启动，并至少查一条带时间戳的业务记录是否一致。
最容易被跳过的一步：检查备份中是否包含
CREATE DATABASE和
USE语句。
mysqldump --no-create-db默认不写库定义，跨环境恢复时容易进错 schema。
