xtrabackup是tb级mysql在线增量物理备份最成熟方案：基于lsn而非时间或文件差异，依赖全量备份起始点，通过--incremental-basedir链式叠加增量，配合--parallel、--compress、--throttle等参数保障性能与稳定性，恢复需严格按序prepare并校验xtrabackup_checkpoints。
对TB级MySQL数据库做在线增量物理备份，Xtrabackup是目前最成熟可靠的选择。它不锁表、不中断业务，且增量只复制变化页，大幅降低I/O和存储压力——关键在于理解其基于LSN（Log Sequence Number）的增量机制，而非简单“比上次多备份点数据”。
全量备份是增量的前提
所有增量备份都依赖一次干净、可准备（prepare）的全量备份。TB级数据必须确保：
- 使用
--parallel=4或更高值（根据CPU核数调整）加速备份过程，避免单线程拖慢整体耗时 - 添加
--compress（如用qpress）减少磁盘占用，TB级备份压缩后通常能节省30%–50%空间 - 指定
--target-dir=/backup/full_$(date +%Y%m%d)，目录名带日期便于后续识别和清理 - 执行完立即运行
xtrabackup --prepare --target-dir=/backup/full_20260428，确认备份一致性；这步不可跳过，否则增量无法应用
增量备份依赖LSN，不是时间或文件差异
Xtrabackup的增量不是按“新增了哪些表”判断，而是读取上一次备份结束时的LSN（记录在xtrabackup_checkpoints中），再从当前InnoDB redo log里找出所有大于该LSN的变更页。
- 第一次增量：用全备目录作为
--incremental-basedir，例如xtrabackup --backup --incremental --incremental-basedir=/backup/full_20260428 --target-dir=/backup/inc_20260429 - 后续增量：以上一次增量目录为
basedir，形成链式依赖（full → inc1 → inc2） - 每次增量完成后，务必检查生成的
xtrabackup_checkpoints，确认to_lsn比上一次的to_lsn大，这是增量有效的直接证据
TB级环境需特别注意资源与稳定性
大库下容易因内存、IO或超时导致失败，建议主动控制：
- 限制IO：加
--throttle=100（每秒100个IO请求），防止备份压垮线上业务 - 控制内存：用
--use-memory=2G（根据服务器总内存合理分配，一般设为1/4～1/3） - 跳过非核心库：通过
--databases="db1 db2"显式指定，避免误含日志库、测试库等干扰LSN链 - 监控进度：备份时查看
ps aux | grep xtrabackup和iostat -x 1，及时发现卡顿
恢复流程必须严格按顺序重放
TB级数据恢复不是“把文件拷回去就完事”，而是四步不可逆操作：
- 先对全量备份执行
--prepare --apply-log-only（禁止回滚未提交事务） - 按时间顺序，对每个增量备份执行
--prepare --apply-log-only --incremental-dir=inc_xxx，逐个合并到全量中 - 最后一次
--prepare去掉--apply-log-only，完成最终一致性校验 - 用
--copy-back恢复到datadir，注意权限：恢复后chown -R mysql:mysql /var/lib/mysql
整个过程无需停机，但恢复阶段需停服务。TB级数据建议在低峰期执行恢复，并提前验证目标磁盘空间是否充足（通常需1.5倍于备份总大小）。
