很多站长把网站跑起来之后，最关心的往往是访问量和排名，却很少有人真正在意服务器上那些数据的安全。直到某天磁盘损坏、机房故障、被人误删数据库，或者手滑把一张重要的表清空了，才猛然意识到：网站可以重新搭，数据丢了就真的什么都没了。备份这件事，平时看不出任何价值，真到需要它的那天，就是救命稻草。本文按真实操作顺序，把 VPS 备份从手动打包、数据库导出，到自动化定时备份、异地容灾，一次讲清。
一、备份到底要备什么
动手备份之前，先想清楚一件事：你的 VPS 上，什么东西是丢了就找不回来的？
- 数据库：博客文章、用户账号、订单记录、配置数据，几乎无法重建，是备份的重中之重。
- 网站程序源码：虽然能从安装包重新装，但你改过的主题、二次开发的插件、自定义代码丢了就很麻烦。
- 上传文件：图片附件、用户上传的文件、下载资源，一旦丢失不可恢复。
- 配置文件：Nginx 站点配置、.env 环境变量、crontab 定时任务，虽然内容不多，但重建起来非常耗时。
很多人以为"我网站不大，手动下载一份就行了"。但对一台 24 小时在线的服务器来说，手动备份最大的问题不是繁琐，而是"懒"——今天拖明天，明天拖下周，等到真出事那天，发现最后一次备份还是三个月前的。所以，备份一定要自动化。
二、手动备份：先学会把数据打包
自动化之前，先手动跑通一次完整流程，确认每一步都正确。以常见的宝塔 + Nginx + MySQL 环境为例，网站数据一般在 /www/wwwroot/ 目录，数据库用 mysqldump 导出。
先把网站目录打包成 tar.gz 归档：
tar -czf /backup/site-$(date +%Y%m%d).tar.gz /www/wwwroot/你的站点目录再把数据库导出来，注意数据库名和用户名密码按你自己的情况替换：
mysqldump -u用户名 -p密码 数据库名 | gzip > /backup/db-$(date +%Y%m%d).sql.gz导出完成后，用 ls -lh /backup/ 看一眼文件大小，确认归档内容完整、压缩正常。这一步建议手动跑一遍，把报错全部解决掉，再进入下一步自动化。
三、自动化备份：crontab + Shell 脚本
手动流程跑通之后，把它写成一个脚本，交给系统定时任务去执行。新建 /root/backup.sh，内容大致如下：
#!/bin/bash
BACKUP_DIR="/backup"
DATE=$(date +%Y%m%d)
# 备份网站目录
tar -czf $BACKUP_DIR/site-$DATE.tar.gz /www/wwwroot/你的站点目录
# 备份数据库
mysqldump -u用户名 -p密码 数据库名 | gzip > $BACKUP_DIR/db-$DATE.sql.gz
# 只保留最近 7 份，自动清理旧备份
ls -t $BACKUP_DIR/site-*.tar.gz | tail -n +8 | xargs -r rm -f
ls -t $BACKUP_DIR/db-*.sql.gz | tail -n +8 | xargs -r rm -f给脚本加执行权限，并手动运行一次验证：
chmod +x /root/backup.sh
bash /root/backup.sh确认没有报错后，加入 crontab，让它每天凌晨自动执行：
crontab -e
# 每天凌晨 3 点执行备份
0 3 * * * /root/backup.sh >> /root/backup.log 2>&1这里把输出重定向到了日志文件，方便事后检查任务是否成功执行。脚本里"只保留最近 7 份"的逻辑很重要——不清理的话，磁盘迟早被备份文件占满，反而把服务器拖垮。
四、异地备份：把备份"送"出去
本地备份解决的是"误删、手滑"的问题，但解决不了"服务器挂了、机房出故障"的问题。如果备份文件跟源站放在同一台机器上，硬盘坏了，备份也跟着没了。所以，真正的容灾要求备份必须"异地"存放，至少不在同一台服务器、最好不在同一个机房。
常用的异地备份方式有三种：
- 对象存储：腾讯云 COS、阿里云 OSS、Cloudflare R2 等都有免费额度，用 rclone 或命令行工具把备份传上去，是最省心的方案。
- 另一台 VPS：用 scp 或 rsync 把备份推到另一台便宜的小机器上，注意目标机器要配置好密钥认证，避免交互输入密码。
- 本地电脑：下载到自己电脑或 NAS 上，适合数据量不大的个人站，但记得本地也要留一份。
以 rsync 推送到另一台服务器为例：
rsync -avz --remove-source-files /backup/ user@备份机IP:/backup/把这条命令追加到 backup.sh 末尾，每天的备份就会自动同步到异地。对个人站长来说，对象存储免费额度通常完全够用，性价比最高，强烈推荐。
五、灾难恢复：关键时刻别掉链子
备份做得再好，恢复练得少，出事时照样抓瞎。建议每季度做一次完整的恢复演练：开一台临时 VPS，把备份下载下来，重新导入数据库、还原网站目录，确认站点能正常访问。流程并不复杂：
# 解压网站目录
tar -xzf site-20261028.tar.gz -C /www/wwwroot/
# 恢复数据库
gunzip -c db-20261028.sql.gz | mysql -u用户名 -p密码 数据库名演练的意义在于：提前发现备份里的坑——比如备份不完整、数据库导出少了几张表、密码过期、脚本路径写错。真到灾难发生时才发现问题，代价就太大了。
六、几个容易踩的坑
- 别备份日志：access.log、error.log 这类日志增长飞快，又没必要恢复，一定要在 tar 打包时排除，否则备份体积会失控。
- 敏感数据要加密：数据库里可能有用户密码、支付信息，备份文件建议用 gpg 加密或放到私有存储桶，设置好访问权限。
- 密码别硬编码在脚本里：mysqldump 的密码直接写在脚本中，一旦服务器被入侵，等于把数据库钥匙也交出去了。可以考虑使用 mysql_config_editor 或配置文件方式管理。
- 备份失败没人知道：自动化定时任务偶尔会因为磁盘满、网络异常等原因失败，建议搭配上一期讲过的监控告警，给备份任务加一道"成功才安心、失败就告警"的保险。
总结
备份这件事，投入的成本很低，回报却可能是一次完整的数据失而复得。记住几个关键点：数据库和源码都要备、备份必须自动化、异地再存一份、定期做恢复演练。把这条链路搭好之后，你就可以安心睡觉了——哪怕明天服务器整个宕掉，数据也还在，网站随时能原地复活。