宝塔定时备份到对象存储，以及一次真实的恢复过程

去年三月，我在后台点错了一次，把主站的数据库删了。

宝塔的回收站没开。本地备份是三天前的。也就是说，三天内的数据全没了。

最后是从对象存储里拉回来的，丢了大概两小时的内容。

这次之后我把备份流程整个重做了一遍，写下来。

为什么本地备份等于没备份

宝塔默认的备份路径是 /www/backup/，和站点在同一块硬盘上。

硬盘挂了、机器被释放了、误删了整个 /www，备份跟着一起没。

这不算备份，算"多一份拷贝"，只能防手滑，防不了灾难。

真正的备份必须满足一条：和源数据不在同一台机器上。

用对象存储

腾讯云 COS、阿里云 OSS、七牛都行，原理一样。我用的是 COS，因为站点图片本来就存在那。

宝塔面板里有现成的对接：软件商店里装"腾讯云 COS"，填 SecretId 和 SecretKey，然后去"计划任务"里新建一条备份任务，存储位置选 COS。

这样面板自己会每天把网站文件和数据库打包上传，不用写脚本。

但面板的备份有两个毛病：

• 只保留最近几份，历史版本有限
• 附件目录大的时候，打包容易超时失败，而且失败了只会在日志里记一行，不看不知道

我自己写的脚本

后来我改用脚本，因为要控制保留策略，也想留个自己能看懂的东西。

思路很简单：打包、上传、删旧。

#!/bin/bash
DATE=$(date +%Y%m%d)
DIR=/www/backup/tmp
mkdir -p $DIR

# 数据库
mysqldump -uroot -p密码 --single-transaction 数据库名 | gzip > $DIR/db-$DATE.sql.gz

# 站点文件
tar -czf $DIR/site-$DATE.tar.gz /www/wwwroot/站点目录

# 上传（coscmd 是腾讯云官方命令行工具）
coscmd upload $DIR/db-$DATE.sql.gz /backup/db/
coscmd upload $DIR/site-$DATE.tar.gz /backup/site/

# 删本地临时文件
rm -f $DIR/*-$DATE.*

# 删 30 天前的远程备份
coscmd delete -r /backup/db/ -f --before 30d

挂到 crontab，每天凌晨三点跑：

0 3 * * * /bin/bash /root/backup.sh >> /var/log/backup.log 2>&1

注意 >> /var/log/backup.log 这句别省。没有日志，脚本失败了你还以为在备份。

比备份更重要的事：演练恢复

大部分人备份了从来不恢复，真出事的时候才发现备份是坏的。

我现在的习惯是每季度演练一次：从 COS 拉最新的一份，在一台测试机上完整恢复，确认站点能打开、图片在、后台能登录。

第一次演练就发现了一个问题：脚本里 tar 打包路径带的是绝对路径，恢复的时候会把文件解到 /www/wwwroot/ 下面而不是当前目录，差点把测试机弄乱。

改成相对路径之后就没这个问题了：

cd /www/wwwroot
tar -czf $DIR/site-$DATE.tar.gz 站点目录名

三层备份

现在我的结构是：

• 第一层：对象存储，每天一份，保留 30 天。防机器故障
• 第二层：本地磁盘，每周一份，保留 4 周。恢复快，防网络问题
• 第三层：手动导出，每月一次，下载到自己电脑。防账号被盗、防服务商跑路

第三层听起来很土，但真有用。我见过服务商跑路、账号被黑清空存储的事，云端再稳也不是绝对。

那次恢复的过程

说回开头。数据库删了之后：

1. 从 COS 下载最近的一份 db-20250312.sql.gz
2. 解压，导入一个新库
3. 改 wp-config.php 指向新库
4. 确认数据正常后，把旧库改名删掉

整个过程四十分钟。丢的是当天上午更新的两篇文章和几条评论。

如果没有那份备份，这个站基本就废了。

备份的价值不在"备份"这个动作，在"恢复"那一刻。没恢复过的备份，只能算心理安慰。