运维圈有句话：数据丢失之前，没人觉得备份重要。硬盘坏、误删库、被勒索病毒、服务商跑路，随便哪一样都能让多年积累瞬间没了。这篇把网站备份这件事说透，照着做，你起码不会因为没备份而一夜回到解放前。
一、先记住3-2-1原则
这是备份的黄金准则，简单但少有人真正执行：
| 数字 | 含义 | 目的 |
|---|---|---|
| 3 | 保留3份数据（1份生产+2份备份） | 防单点故障 |
| 2 | 存在2种不同介质上 | 防介质统一坏 |
| 1 | 至少1份放异地 | 防机房级灾难 |
最常见的误区：把备份放在同一台服务器上。服务器一宕机、被黑、磁盘坏，备份和数据一起没。备份的价值在于“隔离”，必须存到独立位置。
二、到底要备份哪些东西
很多人只备了网站文件，忘了数据库，这是最大的盲区。完整清单：
- 网站文件：/var/www 或你的根目录，含用户上传的图片附件。
- 数据库：MySQL/PostgreSQL 全量 dump，有订单的站尤其不能漏。
- Web配置：Nginx/Apache 的配置目录。
- SSL证书：虽然能重申请，但备份着省心。
- 系统关键配置：ssh配置、crontab、hosts，以及 .env、wp-config.php 这类应用配置。
三、备份频率看业务容忍度
| 业务类型 | 建议频率 |
|---|---|
| 个人博客/展示站 | 每周一次 |
| 每日更新的内容站 | 每天一次 |
| 电商独立站（有订单） | 每天全量+数据库每4小时 |
| SaaS/用户平台 | 每小时增量+每天全量 |
四、自动化：脚本+cron
手动备份坚持不了三天，必须自动化。思路是写个脚本，把网站目录和数据库打包，传到异地存储（对象存储或另一台服务器），再用 cron 定时跑。
几个要点：
- 用
nice/ionice降备份进程的优先级，别在压缩扫描时把网站拖慢。 - 数据库大的别只靠 mysqldump，可以开 binlog 做时间点恢复，或者上物理热备工具。
- 用 rsync 做增量同步，省带宽；传到对象存储时走加密通道。
- 宝塔这类面板也有计划任务，小白直接用它设“备份网站/数据库”到云存储最省事。
五、最关键的一步：验证能恢复
备份命令显示成功，只说明文件生成了，不代表能恢复。建议：
- 每周检查一次备份完整性，看快照列表在不在。
- 每月做一次完整恢复演练：把最近备份恢复到测试目录，导入测试库，用测试域名打开看正不正常。
- 只有测试环境能正常开站、登后台、查数据，这份备份才算真的可用。
常见问题
云服务器的快照算备份吗？
算一层，但不算全部。快照恢复快，适合救误删和配置错，但它和服务器在同一个机房，扛不住机房级灾难。还得有异地那一份才稳。
备份占空间太多怎么办？
用冷热分层：近7天留标准存储随时取，30天内转低频，更老的归档。既保证能恢复又控成本。
备份文件要不要加密？
要。备份里可能含数据库和配置文件，含敏感信息。加密存储、限制备份目录访问权限，是基本操作。
数据备份是正当的运维刚需，用来防丢失、做容灾都合规。提醒一句：备份里若涉及用户个人信息，按《个人信息保护法》做好加密和访问控制，别让备份本身变成泄露口。
