作为一个运营多个网站的站长，我最怕的事情不是流量下跌，而是数据丢失。曾经有一次因为磁盘故障，差点丢掉一整年的文章和用户数据，从那以后我就把备份当成了头等大事。今天这篇文章，我就把在 VPS 上搭建备份与恢复方案的完整经验分享出来，希望对同样在自建网站的你有帮助。
一、备份前先想清楚：你到底要备份什么
在动手之前，先理清网站的数据构成。一般来说，一个网站的数据主要分两部分：
- 数据库：文章内容、用户信息、评论、配置等都存在数据库里，是网站的核心资产；
- 网站文件：程序源码、主题模板、上传的图片附件、日志文件等。
把这两部分想清楚，备份才能有的放矢，既不遗漏重要数据，也不浪费磁盘空间。
二、数据库备份：最简单也最关键
以最常用的 MySQL/MariaDB 为例，一条命令就能把整个数据库导出成 SQL 文件：
mysqldump -uroot -p 你的数据库名 > /backup/db_20240101.sql
如果数据量比较大，建议配合 gzip 压缩，备份文件能小很多：
mysqldump -uroot -p 你的数据库名 | gzip > /backup/db_20240101.sql.gz
这里有两个小建议：一是线上站点备份时加上 --single-transaction 参数，避免锁表影响用户访问；二是给数据库单独建一个备份专用账号，只授予 SELECT、LOCK TABLES 等最小权限，不要直接用 root 密码。
三、网站文件备份：打包压缩一条命令搞定
网站文件用 tar 打包非常方便，一条命令就能把整个网站目录压缩成单个文件：
tar -czf /backup/site_20240101.tar.gz /www/wwwroot/你的网站目录
如果想排除缓存和日志这类不需要备份的目录，可以加上 --exclude 参数：
tar -czf /backup/site_20240101.tar.gz --exclude='cache' --exclude='logs' /www/wwwroot/你的网站目录
四、定时自动备份：让 cron 替你干活
手动备份偶尔做一次可以，但要长期坚持还是得靠自动化。Linux 上最常用的就是 cron 定时任务。先写一个备份脚本 backup.sh：
#!/bin/bash DATE=$(date +%Y%m%d) mysqldump -uroot -p你的密码 你的数据库名 | gzip > /backup/db_$DATE.sql.gz tar -czf /backup/site_$DATE.tar.gz /www/wwwroot/你的网站目录 find /backup -name "*.gz" -mtime +7 -delete
然后把脚本加入 crontab，让它在每天凌晨执行：
0 3 * * * bash /root/backup.sh
最后一行 find 命令会自动删除 7 天前的旧备份，防止备份文件越积越多把磁盘塞满，非常实用。
五、异地备份：鸡蛋不要放在一个篮子里
备份如果只存在同一台 VPS 上，服务器故障时备份也会一起消失，所以异地备份非常必要。最简单的做法是把备份传到自己家里电脑或者另一台服务器上，用 rsync 增量同步，高效又省流量：
rsync -avz --progress /backup/ 用户名@远程服务器:/backup/
也可以用 rclone 直接把备份同步到云对象存储，比如阿里云 OSS、腾讯云 COS，成本低、可靠性高，是很多国内站长的首选方案。
六、数据恢复实战：别等出事才第一次演练
备份的价值体现在恢复上。很多站长备份做了，但从来没恢复过，真正出事的时候才发现备份文件是坏的，那才叫绝望。建议每季度做一次恢复演练：新开一台临时 VPS，把备份下载下来，恢复数据库和网站文件，确认网站能正常打开后再销毁临时机器。
数据库恢复同样是一条命令：
mysql -uroot -p 你的数据库名 < db_20240101.sql
网站文件恢复更简单，解压覆盖即可：
tar -xzf site_20240101.tar.gz -C /www/wwwroot/
七、几点实战建议
- 备份脚本运行后检查一下生成的文件大小，如果突然变小很多，多半是备份出错了；
- 升级程序、修改数据库结构等关键操作前，先手动备份一次；
- 把备份脚本的运行日志写入文件，出了问题方便排查；
- 备份文件尽量加密存储，避免数据库内容泄露。
八、写在最后
备份这件事，平时看起来没什么用，但关键时刻真的能救命。花半小时把这套方案配置好，以后就不用再为数据安全提心吊胆了。如果你在配置过程中遇到任何问题，欢迎在评论区留言交流，我看到都会尽量回复。