流式备份能省本地磁盘空间，因为--stream将备份数据直接输出到stdout，跳过落盘再传输的中间步骤；必须用xbstream而非tar，因其支持并发页拷贝与checkpoint对齐；压缩须通过管道（如gzip）在流后进行，不可混用--compress。
流式备份为什么能省本地磁盘空间
因为 --stream 会把备份数据直接输出到 stdout，跳过“先写满磁盘再压缩/传输”的中间步骤。默认全量备份会把所有 .ibd、.frm 等文件原样复制到 --target-dir，目录大小基本等于 datadir，动辄几十GB。而流式模式下，你只需要一个临时缓冲（比如管道或内存），真正落盘的只有最终目标文件（如压缩包或远程接收端）。
必须用 xbstream 而不是 tar
tar 流不支持并发写入和部分校验，xbstream 是 Percona 专为 XtraBackup 设计的流格式，能正确处理 InnoDB 的并发页拷贝、redo 日志截断点对齐，以及后续 prepare 阶段所需的元数据结构。用 --stream=tar 备份后，xtrabackup --prepare 很可能报错 Failed to open file 'xtrabackup_checkpoints' 或提示 checkpoint 丢失。
- 正确命令示例：
xtrabackup --backup --stream=xbstream --target-dir=./ /data/backup/ > backup.xbstream - 错误写法（会导致恢复失败）：
xtrabackup --backup --stream=tar /data/backup/ > backup.tar -
--target-dir=./必须存在且可写，它只是xtrabackup内部创建临时工作子目录的父路径，不是最终备份存放地
压缩必须在流之后做，不能靠 --compress
--compress 是对备份目录内文件逐个用 quicklz 压缩成 .qp，它不兼容流模式——一旦启用，--stream 会被忽略，xtrabackup 会退回到普通目录备份流程，本地磁盘照样爆满。真正零中转压缩，得靠 shell 管道链：
- 推荐组合：
xtrabackup --backup --stream=xbstream /data/backup/ | gzip > backup.xbstream.gz - 若需并行压缩（如服务器有多核）：
xtrabackup --backup --stream=xbstream /data/backup/ | pigz -p 4 > backup.xbstream.gz - 解压还原时顺序不能反：先
gunzip或pigz -d，再用xtrabackup --decompress（仅当用了--compress）或直接xbstream -x
流备份后直接传到从库，避免本地存两份
生产中最常见的误操作是：先流式生成 backup.xbstream 存本地，再 scp 到从库。这等于又占一遍磁盘。更优做法是管道直传：
- 主库执行：
xtrabackup --backup --stream=xbstream /data/backup/ | ssh 192.168.184.152 "xbstream -x -C /data/backup/recover/" - 注意从库提前建好目录：
ssh 192.168.184.152 "mkdir -p /data/backup/recover" - 该方式下主库内存只缓存单个 stream chunk，从库磁盘只存解包后的原始文件，全程无额外备份包落地
- 失败重试成本高，建议加
timeout和重定向日志：... | timeout 7200 ssh ... 2> backup.log
xbstream 格式、压缩时机、管道中断处理这三个点，线上出过太多恢复不了的事故。尤其是误用 tar 流或混用 --compress，问题往往要等到真正恢复那天才暴露。
