上周帮一个做外贸的网站朋友恢复网站，他的数据数据库被误删了。服务商那边只保留7天快照，备份而他最后一次手动备份是网站三个月前。丢掉的数据客户询盘记录，用他的备份话讲，“比丢钱还难受”。网站这事让我觉得，数据有必要把网站数据备份这件事说透。备份

很多人以为网站备份就是网站复制文件。其实不然。数据一个完整的备份网站至少包含三部分：网站程序文件、数据库、网站以及配置文件（比如SSL证书、数据服务器环境变量）。备份只备份了`/var/www/html`，数据库没导，恢复时照样抓瞎。反过来，只导出SQL文件，程序被篡改或删除，一样白搭。我见过有人用`mysqldump`导了数据库，结果忘了备份`wp-config.php`，恢复后连不上数据库，折腾一整天。

那怎么备份才算靠谱？分两种场景说。

如果你用的是虚拟主机或共享服务器，后台通常带“一键备份”功能。别太信任它。我测试过几家主流面板，有的只备份网站根目录，数据库要单独操作；有的备份文件存在同一台服务器上，服务器一挂全完。正确做法是：手动导出数据库（phpMyAdmin里选“自定义”导出，勾选“添加DROP TABLE”），再把网站文件打包下载到本地。频率？内容站一周一次，电商站每天一次。别嫌麻烦，写个脚本定时跑。

自己管服务器的话，`rsync`加`cron`是基础操作。比如每天凌晨3点把`/var/www`同步到另一块硬盘，同时用`mysqldump`导出数据库并压缩。但这里有个坑：`rsync`默认不删目标端多余文件，如果你删了源文件，备份里还留着旧版本。加`--delete`参数才行。另外，别把备份放在同一台机器上。我见过有人把备份存到`/backup`目录，结果硬盘坏道，源数据和备份一起没了。异地备份不是口号，买个对象存储（比如Backblaze B2，便宜），用`rclone`同步过去，每月多花几块钱，换的是安心。

数据库备份有个细节容易被忽略：字符集。特别是从MySQL 5.6迁移到8.0时，`utf8`和`utf8mb4`混用，恢复后中文变问号。导出时加`--default-character-set=utf8mb4`，导入前确认目标库字符集一致。这问题我踩过两次，第二次是因为没检查`sql_mode`，严格模式导致日期`0000-00-00`插入失败。备份文件不是导出就完事，恢复测试才算闭环。每季度挑一个备份文件，在测试环境还原一次，看看能不能正常打开首页、登录后台、搜索数据。不测试的备份等于没有备份。

还有个小众但致命的点：备份文件的权限。有人把备份放在网站根目录下，命名`backup.sql`，结果被搜索引擎抓取，数据库结构甚至用户密码哈希全泄露。备份文件要么放Web目录外，要么用`.htaccess`拒绝访问，或者干脆加密压缩（`zip -e`或`gpg`）。别用`backup.zip`这种名字，用日期加随机串，比如`20250321_a7f3c9.zip`。

最后说个真实教训。一个做博客的朋友，用WordPress插件每天自动备份到Google Drive。听起来很稳。结果某天插件更新，备份任务静默失败，他两个月后才发现。自动备份必须带失败通知——邮件、Telegram机器人、甚至Server酱，都行。别假设“设了任务就会一直跑”。服务器会重启，API令牌会过期，磁盘会满。定期登录备份后台看一眼，比什么都强。

网站数据备份这事，没有一劳永逸的方案。它像给车做保养，定期检查、换机油、试刹车。你偷懒，它就在某个深夜给你颜色看。