推荐做法是先用 mysqldump 导出 SQL 文件再 tar.gz 打包，确保数据一致、可移植、支持跨版本恢复；直接 tar 数据目录仅限停库的测试环境，生产环境不推荐。
直接用 tar 备份 MySQL 数据库文件（如 /var/lib/mysql/）是可行的，但必须满足两个前提：数据库已停止或处于只读状态，且文件系统一致。否则可能备份出损坏或不一致的数据。更推荐的方式是先用 mysqldump 导出逻辑备份，再用 tar + gzip 打包压缩——这种方式安全、可移植、支持跨版本恢复。
推荐做法：mysqldump 导出后 tar.gz 打包
这是最通用、最稳妥的组合方式：
- 用
mysqldump导出 SQL 文件（含结构和数据），确保一致性 - 用
tar -zcf将 SQL 文件打包并 gzip 压缩，便于归档与传输 - 文件名建议带日期，避免覆盖
示例命令：
mysqldump -u root -p --databases appdb blogdb > /backup/mysql_$(date +%Y%m%d_%H%M).sqltar -zcf /backup/mysql_$(date +%Y%m%d_%H%M).sql.tar.gz /backup/mysql_$(date +%Y%m%d_%H%M).sql
快速合并写法（一行完成）
省略中间 SQL 文件，直接管道压缩：
mysqldump -u root -p --databases appdb | gzip > /backup/appdb_$(date +%Y%m%d).sql.gz注意：gzip 生成的是纯压缩文件，不是 tar 包；若需 tar.gz 格式（比如统一管理多个备份、保留元信息），仍建议先生成 SQL 再 tar。
不推荐但有时用的：直接 tar MySQL 数据目录
仅限开发或测试环境，且必须停库（或使用 FLUSH TABLES WITH READ LOCK + mysqldump --single-transaction 配合）：
- 确认 MySQL 已停止：
systemctl stop mysqld - 打包数据目录（保留权限和路径）：
sudo tar -czvpf /backup/mysql_data_$(date +%Y%m%d).tar.gz /var/lib/mysql - 恢复时需停库，并解压覆盖原目录：
sudo tar -xzf backup.tar.gz -C /（因含绝对路径，-P 选项慎用）
⚠️ 生产环境强烈不建议此方式：InnoDB 表空间未正常关闭时，直接拷贝可能导致恢复失败。
自动化定时备份示例
写成脚本配合 cron，每天凌晨 2 点执行：
#!/bin/bashDATE=$(date +%Y%m%d)
DUMP_FILE="/backup/mysql_full_${DATE}.sql"
TAR_FILE="/backup/mysql_full_${DATE}.tar.gz"
mysqldump -u root -p'yourpass' --all-databases > "$DUMP_FILE"
tar -zcf "$TAR_FILE" "$DUMP_FILE"
rm -f "$DUMP_FILE"
find /backup -name "mysql_full_*.tar.gz" -mtime +7 -delete
加入 crontab：0 2 * * * /usr/local/bin/backup_mysql.sh
