宝塔面板不支持全量冷备份，实际需先停用站点、再打包文件+导出数据库、最后上传FTP；必须手动串联脚本，确保停运彻底、排除缓存、加时间戳命名、用lftp断点续传并校验完整性。
宝塔面板本身不支持“全量冷备份”这个概念——它没有内置的原子级快照、文件系统冻结或数据库一致性停写机制。所谓“冷备份”，在宝塔场景下实际是指：先确保网站停止响应（如停用站点）、再打包全部文件+导出数据库、最后上传到外部 FTP 服务器。整个过程必须手动串联，否则容易出现文件正在写入、数据库被修改导致备份损坏。
停用站点再打包，避免热备份数据不一致
直接对运行中的 WordPress 或 Laravel 站点执行 zip 或 tar，很可能打进去半截正在生成的缓存文件、未 flush 的 session 数据，甚至正在写入的 wp_options 表。数据库若在备份中途被更新，mysqldump 也拿不到事务一致快照（除非加 --single-transaction，但宝塔默认不启用）。
- 必须先在「网站」模块中点击目标站点右侧的「停止」按钮，状态变为「已停止」后再操作
- 确认 Nginx/Apache 进程不再监听该站点端口：
ss -tuln | grep :80或查ps aux | grep example.com - 如果用了 Redis/Memcached，也要清空对应缓存库，否则恢复后可能读到脏数据
- 停用后不要立刻打包——等 2~3 秒，让 PHP-FPM 最后一批请求彻底退出
用 Shell 脚本串联打包 + mysqldump + FTP 上传
宝塔「计划任务」里的“备份网站”类型只支持本地保存，无法控制压缩格式、排除路径或触发 FTP；而“上传到远程服务器”类型又不支持先执行命令再上传。所以必须写 Shell 脚本，由「Shell 脚本」类型的计划任务来调用。
- 脚本开头加
#!/bin/bash，并用chmod +x赋执行权限 - 打包网站目录时用
zip -r比tar -zcf更稳妥：Windows 用户解压无兼容问题，且支持-x排除临时文件（如-x "*/cache/*" -x "*/logs/*"） - 导出数据库务必加
--single-transaction --routines --triggers，避免锁表，同时保留存储过程和触发器 - FTP 上传别用
ftp命令行（交互式、难调试），改用lftp：支持断点续传、并行、失败重试，命令形如lftp -c "set ftp:ssl-allow false; open ftp://user:pass@host; put /path/to/file.zip" - 所有关键步骤后加
|| exit 1，任一环节失败就终止，防止上传了空包或旧包
FTP 目标服务器需支持被动模式且开放对应端口
宝塔服务器主动连外部 FTP 时，默认走被动模式（PASV），这意味着 FTP 服务端要随机开一个高端口（如 50000–51000）返回给客户端。如果目标 FTP 服务器防火墙没放开这个范围，lftp 会卡在 Waiting for welcome message 或报 Connection timed out。
- 检查 FTP 服务端是否启用了 PASV 模式，并配置了明确的 PASV 地址和端口范围（不能用 0.0.0.0）
- 宝塔所在服务器的出口防火墙（如
ufw或云厂商安全组）也要放行 FTP 控制端口（21）及 PASV 端口段 - 别用 root 用户直连 FTP：创建专用子账户，仅授权指定目录写入权限，密码别含特殊字符（
@、/会破坏 URL 解析） - 测试连接用
lftp -d开启 debug，看实际协商的 PASV IP 和端口是否可达
备份文件名必须带时间戳且不可覆盖
计划任务反复执行时，如果脚本里写死文件名为 backup.zip，每次都会覆盖前一次，等于只留最后一份。更糟的是，若上传中途失败，还可能留下损坏的同名文件，后续恢复时无法识别。
- 用
date +%Y%m%d_%H%M%S生成唯一文件名，例如example.com_20260426_022501.zip - 数据库 SQL 文件同样命名，如
example_com_20260426_022501.sql - 上传成功后，用
rm -f清理本地临时包，避免磁盘撑满；但别删源目录，那是“冷”的前提 - 如果 FTP 服务器支持，可在上传前先
ls检查是否存在同名文件，有则加序号（_v2）避免冲突
真正可靠的冷备份，核心不在“有没有上传”，而在“停得够不够干净、打得够不够全、传得够不够稳”。哪怕脚本多加三行判断、FTP 多配两个端口、文件名多拼几个字符，都比事后发现恢复不了强。
