手动导SQL存桌面三月一备vs服务器每天三次增量备份到三地，网站挂了后恢复速度差8小时数据丢失风险差不止一个量级

去年一个朋友的电商站被挂了webshell，等他发现的时候，攻击者已经把订单表清了、商品SKU乱改了一通。他赶紧找备份——发现最近一次备份是三个月前手动从phpMyAdmin导出的一个SQL文件，放在自己电脑桌面上。恢复之后丢了一个季度的订单数据，商品信息也得一条条重新录入。同一个月，另一个做内容站的同行也遇到服务器硬盘故障，但他用的是服务器自动备份方案：数据库每天凌晨3点自动dump，文件用rsync增量同步到一台低配备份机，同时再上传一份到OSS。从发现故障到站点完全恢复，前后不到40分钟，丢的数据不到15分钟内的增量。

网站数据备份这件事，拆开来看其实就两个问题：备份能不能自动跑、恢复的时候快不快。但大多数站长的做法是"想起来才备份一次"，甚至只备份了数据库忘了网站文件。这篇把备份这件事从策略到工具到脚本到恢复，一个一个说清楚。

一、网站备份到底要备份哪些东西？大多数人都漏了两样

提到"网站备份"，很多人脑子里只有数据库。去phpMyAdmin导出一个.sql.gz，就觉得万事大吉了。但一个网站要能完整恢复运行，至少需要三部分数据：

一个完整的备份清单应该是：数据库dump文件 + 网站目录打包 + /etc/nginx/sites-available/配置文件 + /etc/ssl/证书目录 + crontab -l的输出。少一样，恢复的时候就多一个坑。

二、四种备份方式从"能用"到"好用"，差距不在能不能备份，在恢复的时候

网站备份大体上分四种路子：手动导出、面板自带备份、WP插件备份、服务器脚本自动备份。它们都能"备份"，但恢复速度、可靠性、自动化程度差了不止一个级别。

这四种方式不是互斥的，最好的做法是组合使用。比如宝塔面板做日常备份+脚本异地同步到备份机+WP插件再存一份到云存储，三份备份三个地方，坏掉一份还有两份兜底。

三、全量、增量、差异备份怎么选？一个每天更新200篇文章的站和一个一周改一次的企业站，备份策略完全不一样

选备份策略之前，先搞清楚三种备份方式到底是什么意思，以及各自的代价。

实操建议：对于绝大多数网站，推荐"全量+增量混合"策略。比如：每周日凌晨做一次全量备份（保留4周），每天凌晨做一次增量备份（保留7天）。恢复的时候先还原最近的全量，再依次叠加增量。这样既省存储空间，恢复速度也不会太慢。

四、一套能直接用的自动备份脚本，数据库+文件+异地同步全搞定

如果你用的是Linux服务器（CentOS/Ubuntu/Debian），下面这套方案可以做到：数据库每天自动dump并压缩，网站文件增量同步到备份机，旧备份自动清理——全程不需要人工介入。

先看数据库自动备份脚本：

#!/bin/bash# backup-mysql.sh - 每天凌晨3点通过cron执行BACKUP_DIR="/data/backups/mysql"DATE=$(date +%Y%m%d)RETENTION_DAYS=30# 创建备份目录mkdir -p $BACKUP_DIR/$DATE# 导出所有数据库（排除系统库）DATABASES=$(mysql -u root -p'your_password' -e "SHOW DATABASES;" | grep -Ev "Database|information_schema|performance_schema|mysql|sys")for db in $DATABASES; domysqldump -u root -p'your_password' \--single-transaction \--routines \--triggers \--events \$db | gzip > $BACKUP_DIR/$DATE/${db}_${DATE}.sql.gzdone# 删除30天前的备份find $BACKUP_DIR -type d -mtime +$RETENTION_DAYS -exec rm -rf {} \;echo "Backup completed: $(date)"

再说网站文件的增量同步脚本，用rsync配合--link-dest参数实现类似快照的效果：

#!/bin/bash# backup-files.sh - 增量同步网站文件到备份机SOURCE_DIR="/var/www"BACKUP_HOST="backup@192.168.1.100"BACKUP_BASE="/data/backups/files"DATE=$(date +%Y%m%d)LATEST_LINK=$(ls -d $BACKUP_BASE/*/ 2>/dev/null | tail -1)# 用rsync增量同步，--link-dest实现硬链接去重rsync -avz \--delete \--exclude="cache/" \--exclude="*.log" \--link-dest="$LATEST_LINK" \$SOURCE_DIR/ \$BACKUP_HOST:$BACKUP_BASE/$DATE/

最后把定时任务加到crontab里：

# 每天凌晨2点备份数据库0 2 * * * /data/scripts/backup-mysql.sh >> /var/log/backup.log 2>&1# 每天凌晨4点增量同步文件0 4 * * * /data/scripts/backup-files.sh >> /var/log/backup.log 2>&1# 每周日凌晨1点做一次全量文件打包0 1 * * 0 tar -czf /data/backups/full_$(date +\%Y\%m\%d).tar.gz /var/www/

五、WordPress用户不想碰命令行，三款备份插件各有什么取舍

如果你用的是WordPress且不想碰服务器命令行，插件是最省事的方案。但插件也有插件的坑——有的备份文件太大恢复超时、有的免费版不支持异地存储、有的备份过程中把服务器CPU跑满。

综合推荐：日常备份首选UpdraftPlus或WPvivid，免费版已经够用。UpdraftPlus用户量最大、社区最活跃，遇到问题容易搜到解决方案。WPvivid的增量备份免费版就支持，对大站点更友好。Duplicator更适合做网站迁移打包，当日常备份工具用有点浪费。

六、备份存哪里才不算"假备份"？服务器本地、同机房另一台、跨机房、云端，安全性差了好几级

备份存储位置的选择，直接决定了发生极端情况时数据能不能救回来。不同的存储位置，对应的灾难类型完全不同。

比较理想的组合是：服务器本地保留最近3天的备份（快速恢复）+ 同账号OSS存储最近30天（异地容灾）+ 另一个云厂商的对象存储保留最近7天（极端情况兜底）。成本不高——一个中等网站的备份数据通常不超过10GB，OSS一个月也就几块钱。

七、备份做好了但恢复跑不通，三个最让人崩溃的场景和怎么避免

备份最大的陷阱不是没备份，是备份了但恢复的时候才发现用不了。下面这三种情况，在站长圈里反复上演：

八、多站点怎么统一管理备份？几十个站一个一个配脚本不现实

如果你手里有几十个甚至上百个网站，每个站单独写脚本配cron显然不现实。多站点备份需要考虑统一调度、集中存储、异常告警三个层面。

多站点备份最怕的不是技术问题，是管理问题——某台服务器到期了忘记续费、某个站的cron被误删了、某次备份失败了没人发现。所以除了备份本身，一套能监控备份状态、自动告警的管理机制，比多写几个脚本重要得多。

九、不同规模网站的备份成本，从零元到几百块一个月，差的不是钱是安心程度

十、几个容易被忽视但关键的小细节

聊完大框架，再说几个实操中容易踩的小坑：

• 备份文件命名要带日期：不要用固定的文件名覆盖备份。万一备份脚本出bug生成了空文件，把上一个有效备份给覆盖了，就什么都没了。文件名加上日期（如backup_20260802.sql.gz），至少保留最近7天的备份。
• mysqldump一定要加--single-transaction：不加这个参数，导出过程中如果有写入操作，可能导致备份数据不一致。对于InnoDB引擎的数据库，这个参数是必须的。
• cron的执行日志要保留：crontab里每个备份命令后面都加 >> /var/log/backup.log 2>&1，这样备份失败时至少能看到报错信息。什么日志都没有的话，备份停了一个月你可能都不知道。
• WordPress的wp-config.php要单独备份：这个文件不在数据库里，也不在主题目录里，但它包含了数据库连接信息、安全密钥、调试开关等关键配置。丢了它，恢复会多花不少时间。
• SSL证书过期时间要记着：用Let's Encrypt自动续期的还好，如果是手动申请的商业证书，证书文件备份了但证书过期了，恢复之后网站HTTPS直接挂掉。把证书到期时间也纳入监控。