正文

!bin/bash

运维老杨
运维老杨 V管理员 /745阅读/3评论
0824
文章最后更新时间2026年08月24日，若文章内容或图片失效，请留言反馈！

《WordPress网站备份，别再只靠插件！手把手教你从零搭一套“生死无忧”的备份系统》

适用人群：
如果你正在用WordPress经营自己的博客、企业官网或小型电商站，每天花几个小时写文章、调主题、传产品图，但从没想过“万一服务器被黑客删库”或者“手滑更新插件把整站搞白屏”该怎么办——那你就是本文要救的那个人。
这套教程需要你有一台云服务器（或VPS）的SSH权限，用宝塔面板或LNMP环境都行，不需要你是什么运维大神，只要会复制粘贴命令、会改几个路径,照做就能把备份体系搭起来。

开始之前，先把丑话说在前面：
很多人觉得“装个UpdraftPlus插件，定时往网盘传一份”就是备份了，但我告诉你，插件备份有三大坑：一是插件本身可能被攻击或损坏；二是恢复时要求“同型号服务器+同版本PHP+同主题”，换台机器就抓瞎；三是数据库和文件分开备份，经常漏掉某个目录，真正的备份必须“自己动手，服务器级操作”，下面这套流程，我称之为“三二一备份方案”：本地一份、异地一份、冷备一份，重要数据至少覆盖3个版本。

第一步：给数据库做“全量快照”

WordPress的所有文章、评论、设置都存在MySQL数据库里，这是网站的“大脑”，先SSH登录服务器,执行：

!bin/bash

!bin/bash

mysqldump -u你的数据库用户名 -p你的数据库密码 你的数据库名 | gzip > /backup/db_$(date +%F).sql.gz

解释一下：mysqldump是MySQL自带的导出命令，后面跟用户名、密码和数据库名。| gzip是把导出的数据实时压缩，省硬盘空间。$(date +%F)会自动替换成当天日期，比如db_2025-04-05.sql.gz。

如果你的WordPress是用宝塔面板管理的，可以直接在“数据库”菜单里复制数据库名，不用记，但注意：密码尽量别写在命令行里，不然会出现在服务器历史记录中，更安全的方式是：先登录MySQL，再执行mysqldump,或者用下面这种临时变量：

read -s MYSQL_PWD
mysqldump -u数据库用户 -p"$MYSQL_PWD" 数据库名 | gzip > /backup/db_$(date +%F).sql.gz

把备份文件放到/backup目录，这个目录一定不能被web访问到，建议放在/var/backups或者/root/backup。

第二步：把网站文件“打包带走”

数据库备份完了，接下来要备份整个WordPress目录，这里面包括主题、插件、上传的图片、网页源码,找到一个Linux小白也能记住的终极命令：

tar -czf /backup/wp_files_$(date +%F).tar.gz --exclude='wp-content/cache' --exclude='wp-content/backup-db' /var/www/你的网站目录

这里-czf表示创建压缩包，--exclude是排除缓存目录（比如某些缓存插件生成的临时文件，不排除的话包会巨大）。/var/www/xxx替换成你的真实站点路径，如果不知道路径，在网站根目录执行pwd就能看到。

打包完你会有两个文件：一个数据库压缩包、一个文件压缩包，这就是“本地一份”，注意：这两个包不要放在同一个磁盘分区，如果服务器只有一块数据盘,那就至少放在非网站目录的另一个分区下。

第三步：自动同步到异地（别再裸奔了）

本地备份只能防手滑，防不了机房火灾，所以必须把备份传到另一个服务商的对象存储或网盘上，这里强烈推荐rclone，一个命令就能连Google Drive、Dropbox、阿里云OSS、腾讯云COS。

安装rclone（一行命令）：

curl https://rclone.org/install.sh | sudo bash

然后配置远端,以阿里云OSS为例：

rclone config

按提示输入n新建，给这个远程存储起个名，比如alioss，然后选择s3类型（因为OSS兼容S3协议），再填AccessKey、SecretKey、Endpoint等，记不住这些key？去阿里云控制台创建一个RAM子账号，只给目标OSS桶的读写权限,这样即使key泄露也不至于炸了整个账号。

配置完成后,测试同步：

rclone copy /backup alioss:wordpress-backup-2025 --progress

如果能看到上传进度，说明通了，之后这一步就不需要手动干了，交给cron定时任务，执行crontab -e,加入：

0 3 * * * /bin/bash /root/backup_script.sh >> /root/backup_log.txt 2>&1

意思是每天凌晨3点执行一个备份脚本，那怎么把前两步的命令串成一个脚本呢？先用nano /root/backup_script.sh创建文件,把下面内容粘进去：

# 备份数据库
mysqldump -u用户 -p密码 数据库名 | gzip > /backup/db_$(date +%F).sql.gz
# 备份文件
tar -czf /backup/wp_files_$(date +%F).tar.gz --exclude='wp-content/cache' /var/www/你的网站目录
# 同步到异地
rclone copy /backup alioss:wordpress-backup-2025
# 删除本地7天前的备份（保留近一周）
find /backup -mtime +7 -name "*.gz" -delete

保存后执行chmod +x /root/backup_script.sh,再手动跑一次检查有没有报错。

第四步：恢复演练（决定了你前面是白折腾还是救命）

备份搭好了，不测试等于没备份，找一个周末，在服务器上新建一个测试文件夹，解压备份包，把这套“备份”恢复成一套独立的WordPress,具体步骤：

  1. 新建数据库test_wp，导入db_2025-04-05.sql.gz：
    gunzip < db_2025-04-05.sql.gz | mysql -u用户 -p密码 test_wp
  2. 解压文件包到新目录：
    tar -xzf wp_files_2025-04-05.tar.gz -C /var/www/test
  3. 修改新目录下的wp-config.php，把数据库名、密码改成刚才测试库的。
  4. 把站点地址和首页地址临时改成测试域名（或者用本地hosts解析）。

如果你能在浏览器里打开测试站，看到和原来一模一样的页面，那恭喜,你的备份真的能救命。

配置要点（这几点别偷懒）

  • 权限要锁死：/backup目录权限设为chmod 700，仅允许root访问，千万不要放在网站根目录下，否则别人直接访问https://你的域名/backup/db_xxx.sql.gz就能把整站拖走。
  • 数据库密码别明文：上面脚本里我图省事写了明文，但你可以在命令行执行history -c清理记录，然后改成用MYSQL_PWD环境变量或MySQL的my.cnf配置文件。
  • 定时任务的时区：服务器默认可能是UTC时间，你希望每天凌晨3点执行，需要先运行date看看当前时间，如果比北京时间早8小时，就调整系统时区：timedatectl set-timezone Asia/Shanghai。
  • 异地保留策略：rclone同步时，如果本地删除了7天前的备份，异地也会自动删除，但为了防止误删，建议在OSS桶上开启“版本控制”，或者把同步命令改成rclone sync /backup alioss:backup --backup-dir=alioss:backup-history/$(date +%F),这样每次同步前会先把将要覆盖的文件存到历史目录一份。

常见踩坑提醒（每一坑都有人中过）

坑1：备份包里有网站秘密文件
wp-config.php里存着数据库密码和密钥，打包后扔到OSS上等于裸奔，解决办法：在tar命令里把wp-config.php排除掉，或者对备份包进行加密，推荐用openssl enc -aes-256-cbc加密，但会增加复杂度——至少做到把远端目录设为私有访问。

坑2：cron脚本不执行，一查路径不对
很多人写完脚本发现没跑，检查/root/backup_log.txt显示command not found，这是因为cron环境变量里没有/usr/local/bin，解决办法：在脚本开头加上export PATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin，建议不用mysqldump而用mysql的绝对路径，可用which mysql查。

坑3：恢复时忘改wp-config.php里的表前缀
如果你原站点使用了自定义表前缀（比如wp_变成了mywp_），导入备份时记住：新测试库里的第一行`不要盲改，很多人恢复后访问前台出现“Table not found”，就是没改$tableprefix = 'mywp'`。

坑4：备份文件越积越大，把磁盘塞爆
我见过一位站长每天都跑全量备份，一个月后磁盘满了，网站直接挂掉，解决办法：要么用find定期清理（如上文脚本），要么用增量备份工具duply。每周一次全量+每天一次数据库备份性价比最高,文件部分只在改动大时打包一次。

坑5：上传目录太大，备份时间过长
如果wp-content/uploads有几十G，每次全量tar会很慢，建议把这些图片也同步到OSS，并用rclone bisync做双向同步，数据库备份用gzip，文件备份可以加--exclude='wp-content/uploads'，然后单独用rclone copy把uploads目录实时同步到远端，这样既保证图片不丢,又不会拖慢主备份。

最后送你一句我每次说给学员的话：备份不是用来安慰自己的，是用来在绝境中把网站从死神手里拽回来的。 按上述步骤操作，今天就把你的第一个自动备份跑通，如果某条命令报错，别慌，把错误信息复制到搜索引擎里，十有八九能找到解药——但要是哪天服务器真炸了，搜索引擎可救不了你,只有今天这个备份才行。