mysqldump 能否直接远程备份数据库
可以，但前提是 MySQL 服务器允许远程连接，且客户端有对应账号权限。默认
mysqldump支持通过
-h指定远程主机、
-P指定端口、
-u和
-p提供凭证。
常见错误现象：
ERROR 2003 (HY000): Can't connect to MySQL server on 'x.x.x.x' (111)，多因防火墙拦截、
bind-address配置为
127.0.0.1或用户无远程 host 权限（如只授权了
'user'@'localhost'）。
实操建议：
确认服务端my.cnf中
bind-address不是
127.0.0.1（或设为
0.0.0.0），且已重启
mysqld创建远程用户：
CREATE USER 'bkp'@'%' IDENTIFIED BY 'pwd'; GRANT SELECT, LOCK TABLES, SHOW VIEW ON *.* TO 'bkp'@'%'; FLUSH PRIVILEGES;本地执行：
mysqldump -h 192.168.1.100 -P 3306 -u bkp -p --single-transaction --routines --triggers mydb > mydb.sql
mysql 命令行能否直接远程恢复 SQL 文件
可以，但要注意路径和权限限制：远程恢复时，
mysql客户端读取的是**本地**的 SQL 文件，不是服务器上的文件。也就是说，
mysql -h remote_ip -u user -p db_name 是标准做法；而 <code>SOURCE /path/on/server.sql在远程连接下会失败，因为
SOURCE只在本地客户端解析并执行，且路径是相对于客户端机器的。
容易踩的坑：
误以为SOURCE能加载远程服务器磁盘上的文件 —— 实际上它只认客户端本地路径 大文件恢复时卡住或超时：需调大客户端参数，例如加
--max-allowed-packet=512M --net-buffer-length=1M字符集不一致导致乱码：建议导出时加
--default-character-set=utf8mb4，导入时也显式指定
mysql --default-character-set=utf8mb4 -h ...
有没有更安全/自动化的远程备份方案
纯
mysqldump远程调用适合轻量场景，但生产环境建议分层处理：备份动作仍在服务端执行（避免网络传输敏感数据），再把备份文件拉到本地或对象存储。
推荐组合方式：
在 MySQL 服务器上用mysqldump+
gzip生成压缩文件，加时间戳命名，例如：
mysqldump --single-transaction mydb | gzip > /backup/mydb_$(date +\%F_\%H).sql.gz用
rsync或
scp定期同步备份目录到跳板机或备份服务器：
rsync -avz user@192.168.1.100:/backup/ /local/backup/配合
crond和简单清理策略（如保留最近 7 天）
注意：不要在公网直接开放 3306 端口；应通过 SSH 隧道或内网/VPC 网络完成通信。若必须走公网，至少启用强制 SSL 连接（
REQUIRE SSL）并限制 IP 白名单。
Percona XtraBackup 是否支持远程热备
不支持直连远程备份。XtraBackup 必须运行在 MySQL 数据目录所在服务器本地，因为它需要直接访问 InnoDB 的 ibdata1、redo log 等物理文件，并做文件系统级拷贝。所谓“远程”，只能是通过 SSH 执行远程命令，本质仍是本地操作。
典型用法：
ssh user@db-server "sudo xtrabackup --backup --target-dir=/backup/full_$(date +\%F) --parallel=4"再用
rsync拉回备份集，或直接在远端压缩归档后上传至 S3/OSS
关键点：XtraBackup 的
--host参数仅用于连接 MySQL 实例获取元数据，**不能替代本地文件访问**。试图绕过本地执行会导致
failed to access xtrabackup_binary或
cannot open dir类错误。
复杂点在于权限与 SELinux/AppArmor：xtrabackup 需要读取数据目录、写入备份目录，且常需
sudo权限；恢复时更要严格校验 datadir 所有权和 selinux 上下文，这些在远程自动化中极易遗漏。
