直接用s3存mysql海量备份可行，但必须避开mysqldump直传（导致半截文件报error 1064）、不压缩（tb级裸传成本高、超时）、不分层校验（缺失binlog位点/版本等元数据）三大坑；物理备份应改用xtrabackup+xbstream打包加密上传，并严格执行prepare与checksum校验流程。
直接用 S3 存储 MySQL 海量备份可行，但必须绕开 mysqldump 直传、不校验、不分层这三大坑，否则恢复时大概率失败或超时。
为什么不能直接 mysqldump | aws s3 cp - s3://bucket/backup.sql
这种写法看着简洁，实际埋了三个硬伤：
-
mysqldump输出是流式 SQL，S3 不支持“追加写”，一旦网络中断或进程被杀，文件就是半截状态，mysql恢复时直接报ERROR 1064语法错误 - 没压缩：TB 级数据裸传 SQL，S3 存储成本翻 3–5 倍，且上传耗时指数增长（实测 1TB 数据未压缩上传常超 8 小时）
- 无元数据记录：不知道这个文件对应哪次
binlog位置、MySQL 版本、是否含--routines，恢复前无法判断兼容性
物理备份必须走 xtrabackup + xbstream 打包再上传
对 TB 级 InnoDB 实例，xtrabackup 是唯一能兼顾热备、增量、快速恢复的方案。但注意它默认输出是目录，不能直接丢给 S3：
- 先用
xbstream打包成单文件：xtrabackup --backup --target-dir=/backup/full --stream=xbstream | gzip > full_$(date +%F).xbstream.gz - 上传前必须计算校验和：
sha256sum full_2026-09-05.xbstream.gz > full_2026-09-05.xbstream.gz.sha256，连同 .sha256 文件一起上传 - S3 的
metadata字段要填关键信息，比如：x-amz-meta-mysql-version: 8.0.33、x-amz-meta-binlog-pos: mysql-bin.000123:123456789 - 别用
aws s3 cp，改用aws s3api put-object，才能精确控制 metadata 和 server-side encryption（推荐AES256）
恢复时最容易卡在“准备阶段”
从 S3 下载回来的 .xbstream.gz 不能直接 mysql 导入，必须走完整 prepare 流程：
- 先解压解包：
gunzip -c full_2026-09-05.xbstream.gz | xbstream -x -C /restore/full - 再 apply log：
xtrabackup --prepare --target-dir=/restore/full（注意：这里不能加--apply-log-only，除非你后面还要合并增量） - 校验 checksum：
xtrabackup --check-privileges --target-dir=/restore/full，它会检查datadir权限、innodb_log_file_size是否匹配 - 最后才是停库、替换
datadir、重启——千万别跳过 prepare，否则启动时报InnoDB: Database page corruption
真正难的不是上传或下载，而是每次恢复前确认三件事：S3 上那个文件的 binlog 位点是否还在本地日志归档里、mysql 版本小版本号是否一致、innodb_page_size 是否与原集群相同。漏掉任意一项，restore 就会卡在启动阶段不动。
