手里有15个WordPress站和8个静态页站，靠一个Shell脚本加宝塔计划任务每天自动打包传到腾讯云COS，半年没丢过任何数据
23个网站，分布在两台服务器上。每天凌晨3点，一个不到80行的Shell脚本准时启动，把所有站点的文件打包、数据库导出、压缩加密、上传到腾讯云COS，整个流程跑完大概18分钟。这套方案跑了半年多，中间经历过一次服务器硬盘故障，从COS把备份拉回来恢复，前后只花了不到两小时。
说这个不是炫耀脚本多厉害，而是想讲一件事：批量备份这件事，方案选对了、流程搭好了，后面几乎零维护成本。怕的是你一开始没想清楚，23个站一个一个手动去面板里点"备份"，点完还要下载到本地——那时间成本就不是备份工具的问题，是流程设计的问题。
23个站批量备份方案效果速览
| 日均备份耗时（23站全量） | 约18分钟 |
| 单次备份数据量 | 约8.6 GB（压缩加密后约4.2 GB） |
| COS月度存储费用 | 约¥14（保留最近7天备份） |
| 备份保留策略 | 本地保留3天 + COS保留7天 + 每月一份归档保留12个月 |
| 历史故障恢复记录 | 1次（硬盘故障），恢复耗时约2小时，零数据丢失 |
一、批量备份和单站备份，差的不只是数量
单个网站备份很简单：进面板、点备份、下载、完事。三分钟搞定。
但当站点数量超过5个，事情就变了。逐个登录面板、逐个点击备份、逐个下载——一个来回至少要十几分钟。这还是你记得做的前提下。更常见的情况是：想起来的时候备份一下，想不起来就当没这回事。等服务器出了问题才发现，最近一次备份是三个月前的。
批量备份解决的核心问题就三个：
· 统一调度：不用逐个站点操作，一个任务把所有站点覆盖到位
· 自动执行：设定好时间和频率，到点自动跑，不需要人盯着
· 异地存储：备份文件自动上传到对象存储/云盘，不跟源站放在同一台机器上
说白了，批量备份的本质是把"人肉备份"变成"机器备份"。人力成本降到零，遗漏概率降到零。
二、备份什么：不是所有东西都需要备份
批量备份之前，先搞清楚一个站到底有哪些东西需要备份。很多人上来就把整个服务器打包——几十个G、上百个G，结果每天备份跑两个多小时，存储费用一个月几百块，实际上大部分空间被日志文件、缓存文件、临时文件占满了。
一个网站的备份内容分成四块，优先级和频率不一样：
| 备份内容 | 变更频率 | 备份建议 | 典型大小 |
|---|---|---|---|
| 数据库 | 高（每次发布/用户操作都变） | 每日备份 丢失数据库等于丢失全部内容 | 几十MB~几百MB |
| 上传文件/附件 | 中（每次上传图片/文件才变） | 每日备份 但可做增量，不必每次全量 | 几百MB~几十GB |
| 主题/插件代码 | 低（只有手动更新才变） | 每周备份 或每次修改后手动备份 | 几十MB~几百MB |
| 配置文件 | 极低（初次配置后基本不动） | 一次备份 改配置时再更新 | 几KB~几MB |
所以批量备份脚本里，核心操作是两条：mysqldump导出数据库 + tar打包网站文件目录。配置文件（nginx配置、.env等）一次性备份到安全位置，不需要每天跑。
三、六种批量备份方案，从零代码到全自动
按技术门槛从低到高排，每个站长都能找到自己能上手的那一档。
1. 宝塔面板批量操作（零代码，最省事）
宝塔面板从7.x版本开始支持网站列表页多选批量操作。进"网站"页面，勾选需要备份的站点，右键选择"备份"即可一键打包。
优点：完全可视化，不需要写任何代码
缺点：每次都要手动操作，站点超过10个还是很累；备份文件存在本地服务器上，没有异地副本
进阶用法是配合宝塔的"计划任务"功能：添加Shell脚本类型的计划任务，用宝塔内置的bt命令遍历所有站点并执行备份。
#!/bin/bash# 宝塔计划任务批量备份脚本BACKUP_DIR="/www/backup/site_$(date +%Y%m%d)"mkdir -p "$BACKUP_DIR"# 获取所有网站域名websites=($(bt 10 | awk 'NR>2 && NF>=2 {print $2}'))for site in "${websites[@]}"; doecho "正在备份: $site"tar -czf "${BACKUP_DIR}/${site}_files.tar.gz" \-C /www/wwwroot "$site" 2>/dev/nulldone# 删除7天前的旧备份find /www/backup -type d -name "site_*" -mtime +7 -exec rm -rf {} \;这个脚本放到计划任务里，设置每天凌晨执行，就能实现最基本的批量自动备份。
2. 宝塔面板 + 对象存储插件（零代码 + 异地）
上面方案的致命问题是备份和源站在同一台机器上——服务器挂了，备份也一起没了。解决方法是加一层对象存储上传。
宝塔面板自带腾讯云COS、阿里云OSS、七牛云等存储插件。配置好存储桶和密钥后，在计划任务里把"备份到"选为对应的云存储，备份文件会自动上传。整个过程同样是可视化的，不需要写一行代码。
腾讯云COS标准存储，50GB数据一个月大概几块钱。如果数据量不大（单日备份压缩后在5GB以内），月度费用可以控制在10元以下。
3. WordPress多站点管理 + 统一备份
如果你管理的站点全都是WordPress，可以考虑用一个集中管理面板来统一调度备份。主流方案有两个：
· MainWP + UpdraftPlus扩展：MainWP是一个自建的管理面板，装在一个单独的WordPress站点上，通过它管理所有子站。配合UpdraftPlus扩展，可以在一个界面里给所有子站设置备份计划、触发备份、监控备份状态。MainWP本体免费，UpdraftPlus扩展免费版功能基本够用
· ManageWP：SaaS形态的WordPress管理平台，免费版支持每月一次自动备份，付费版支持按需备份和异地存储。好处是不需要自己部署，缺点是备份频率和存储空间受限于套餐
4. Shell脚本 + crontab（灵活度最高）
脱离了面板的束缚，直接写Shell脚本控制备份全流程，自由度最高，但也需要一定的Linux基础。这是我自己在用的方案，核心逻辑如下：
#!/bin/bash# 多站点批量备份 + 上传COSDATE=$(date +%Y%m%d_%H%M)BACKUP_ROOT="/data/backups/${DATE}"COS_BUCKET="cos://my-backups-1234567890"RETENTION_DAYS=7# 站点配置：域名=数据库名declare -A SITESSITES=(["site1.com"]="db_site1"["site2.com"]="db_site2"["site3.com"]="db_site3")mkdir -p "${BACKUP_ROOT}"for domain in "${!SITES[@]}"; dodb="${SITES[$domain]}"# 导出数据库mysqldump -u backup_user -p'password' \--single-transaction --quick "$db" \| gzip > "${BACKUP_ROOT}/${domain}_db.sql.gz"# 打包网站文件（排除缓存）tar --exclude='cache' --exclude='tmp' \-czf "${BACKUP_ROOT}/${domain}_files.tar.gz" \-C /www/wwwroot "$domain"# 上传到COS/usr/local/bin/coscli cp \"${BACKUP_ROOT}/${domain}_db.sql.gz" \"${COS_BUCKET}/${DATE}/${domain}_db.sql.gz"/usr/local/bin/coscli cp \"${BACKUP_ROOT}/${domain}_files.tar.gz" \"${COS_BUCKET}/${DATE}/${domain}_files.tar.gz"echo "[$(date)] ${domain} 备份完成"done# 清理COS上超过保留天数的备份/usr/local/bin/coscli rm "${COS_BUCKET}/" \--older-than "${RETENTION_DAYS}d"echo "[$(date)] 全部站点备份完成"把这个脚本放到crontab里：
0 3 * * * /data/scripts/backup_all_sites.sh >> /var/log/backup.log 2>&1
每天凌晨3点自动执行，日志写入文件方便排查。
5. Restic / Duplicati（开源专业备份工具）
Shell脚本方案灵活但需要自己处理去重、增量、加密、校验这些问题。如果不想自己写，可以上专业的开源备份工具。
· Restic：命令行工具，支持增量备份、去重、AES-256加密、快照管理。后端支持本地、SFTP、S3/COS/OSS、Backblaze B2等几十种存储。一条命令搞定备份：restic -r s3:cos.ap-guangzhou.myqcloud.com/bucket backup /www/wwwroot
· Duplicati：有Web管理界面的开源备份工具，支持定时任务、加密、压缩、增量备份。同样是后端支持S3/COS等云存储。适合不太熟悉命令行的用户
这两个工具的共同优势是增量备份：第一次跑全量，之后每次只上传变化的部分，大大减少了存储空间和上传时间。以23个站为例，全量约8.6GB，增量通常只有几百MB。
6. UpdraftPlus（WordPress站专用，最简单）
如果只有WordPress站点，UpdraftPlus是目前生态最成熟的备份插件。免费版支持：
· 定时自动备份（每天/每周/每月）
· 备份到Google Drive、Dropbox、S3等多个远程存储
· 数据库和文件分开备份
· 一键恢复
付费版（约$70/年）多了增量备份、多站点支持、更多存储后端。对于10个以内的WordPress站点，一个免费版装到每个站上，各自配置定时任务和远程存储，完全够用。
四、六种方案怎么选：一张表说清楚
| 方案 | 适合站点数 | 技术门槛 | 异地备份 | 月均成本 | 一句话评价 |
|---|---|---|---|---|---|
| 宝塔面板批量操作 | 3~20个 | ★☆☆☆☆ | 需额外配置 | 免费 | 上手最快，但不异地等于白备 |
| 宝塔+对象存储 | 3~50个 | ★★☆☆☆ | ✅ 支持 | ¥5~20/月 | 可视化操作 + 异地存储，站长首选 |
| MainWP/ManageWP | 5~100个(WP) | ★★☆☆☆ | 取决于插件 | 免费~$15/月 | 纯WordPress站群的最佳方案 |
| Shell脚本+crontab | 不限 | ★★★☆☆ | 自行对接 | ¥5~30/月 | 灵活度天花板，适合有Linux基础的 |
| Restic/Duplicati | 不限 | ★★★☆☆ | ✅ 原生支持 | 免费(工具)+存储费 | 增量去重加密一条龙，专业首选 |
| UpdraftPlus | 1~20个(WP) | ★☆☆☆☆ | ✅ 支持 | 免费~$70/年 | WordPress单站备份的不二之选 |
五、批量备份最容易踩的四个坑
只备文件不备数据库
这个错误我见过不止一次。tar打包了整个wwwroot目录，心想"全站都备了"，结果恢复的时候发现文章、用户、设置全部丢失——因为数据库不在wwwroot目录里，它存在MySQL的数据目录里。
数据库和文件是两套独立的备份流程，缺一不可。批量脚本里必须同时包含mysqldump（或pg_dump）和tar两个步骤。宁可多写两行代码，也别等恢复的时候才发现数据是空的。
备份文件放在源服务器上
把备份文件放在/www/backup/目录下，服务器硬盘坏了、机房断电了、被勒索病毒加密了——备份和源数据一起完蛋。备份文件必须有至少一份离机副本，不管是对象存储、网盘还是另一台服务器。
⚠ 3-2-1备份原则
至少保留3份数据副本（1份源数据+2份备份），使用2种不同的存储介质（如本地磁盘+对象存储），其中1份放在异地（不在同一机房、不在同一城市）。这应该作为所有备份方案的底线标准。
只备份不验证
备份文件每天都在生成、每天都在上传，看起来一切正常。三个月后服务器挂了，信心满满去恢复——发现备份文件损坏了、解压报错了。
脚本里加一个验证环节：备份完成后，随机抽取一个站点的备份文件，尝试解压并检查数据库文件是否完整可导入。或者在每月做一次全量恢复演练——把某个月的备份拉到一台测试服务器上完整恢复一遍。这花不了多少时间，但能在灾难真正发生前发现问题。
备份频率一刀切
所有站点每天全量备份，听起来很稳妥。但如果一个站有20GB的上传图片，每天全量打包，一个月就是600GB的流量和存储。实际上图片文件几乎不变，不需要每天全量。
更合理的做法是分层备份：数据库每天全量（几十MB到几百MB，成本极低）；上传文件每周全量 + 每天增量（用rsync或Restic的增量功能）；代码和配置每周全量或每次变更后手动备份。这样总体备份数据量可以降到原来的1/5以下。
六、一份可以直接用的备份检查清单
不管选哪种方案，上线前对着下面这个清单逐条确认：
- 1数据库和网站文件是否都纳入了备份范围？
- 2备份文件是否至少有一份存储在源服务器之外的介质上？
- 3备份任务是否设为自动定时执行（crontab/计划任务）？
- 4备份失败时是否有通知机制（邮件/企业微信/钉钉）？
- 5是否设置了旧备份自动清理策略，避免存储空间无限增长？
- 6最近一个月内是否做过一次完整的恢复演练？
- 7备份文件是否加密？（对象存储上的备份建议开启加密）
七、三种典型场景的推荐组合
5个以内WordPress站，新手站长
每个站装UpdraftPlus免费版 → 配置备份到Google Drive → 设置每日自动备份 → 搞定。零成本，零代码，手机就能查看备份状态。
10~30个混合站点（WP+静态+其他CMS）
宝塔面板 + 腾讯云COS插件 + 计划任务Shell脚本 → 数据库每天全量备份到COS → 文件每周全量 + 每天rsync增量 → 成本控制在¥20/月以内。
30个以上站点，有专职运维或技术合伙人
Restic + 自定义Shell编排脚本 → 增量备份 + 去重 + AES加密 → 后端对接S3兼容存储 → crontab定时调度 → 失败自动告警。工具免费，只有存储费用。
不管选哪个组合，上线后第一件事不是等它自动跑，而是手动触发一次完整备份，然后尝试恢复一个站点。恢复成功、数据完整、网站正常打开——这才算备份方案真正就绪。没有经过恢复验证的备份，都只是心理安慰。
备份这件事，和买保险一样：平时觉得是成本，真出事的时候才觉得值。区别在于，保险赔的是钱，备份保的是你过去几个月甚至几年的内容积累。服务器可以重买，域名可以重新解析，但数据库里几万篇文章、几百万条用户数据丢了，基本上就是从头再来。
花半天时间把批量备份方案搭好，后面每天自动跑，半年都不用看一眼。这半天时间，可能是你在网站运维上性价比最高的投入。
