VPS 备份怎么做？把快照、数据库和恢复演练组成真正可用的方案
备份任务成功，不代表网站一定能恢复。本文用内容站的实际场景，讲清备份范围、保留周期、异地副本和恢复验证，给出一套可以逐项执行的方案。
备份要同时覆盖数据、文件和恢复所需配置；保留独立副本与历史版本，并定期从零恢复一次。
一、先回答两个时间问题
如果网站现在故障，你最多愿意丢失多久的数据？又希望多久恢复访问？这分别对应恢复点目标 RPO 与恢复时间目标 RTO。AWS 的恢复目标文档用这两个指标指导恢复策略。[1]
假设博客每天更新一次，丢失当天修改已经令人不舒服；一个不断接收订单的网站，可能连数小时数据都不能丢。我们建议先按业务写出目标，再选择备份频率。不要因为面板默认每日一次，就认为这对所有网站都足够。
二、网站目录不是完整网站
对常见 WordPress 站，文章、评论等内容在数据库里，主题、插件和上传图片在文件里。官方备份文档明确说明，完整恢复通常需要数据库和文件两部分；下载网站目录不能自动得到数据库备份。[2]
此外还要保存必要的配置与说明：运行环境版本、站点入口、定时任务、邮件服务配置、证书续期方式。凭证应加密存储并限制访问；不要为了便于恢复，把数据库密码放进公开仓库或未保护的压缩包。
| 内容 | 为什么要备份 | 恢复时要验证 |
|---|---|---|
| 数据库 | 文章、设置、订单等结构化数据 | 能导入且数据逻辑完整 |
| 上传文件 | 图片、附件、用户上传资料 | 数据库里的链接能找到文件 |
| 代码与配置 | 程序运行和部署方式 | 版本及环境相互兼容 |
| 恢复说明 | 避免只靠某个人的记忆 | 别人也能按步骤操作 |
三、快照很方便，但要理解一致性
快照通常适合回滚环境或加速整机恢复，但创建时应用还在写数据，可能需要额外步骤才能得到应用一致的数据。以 Amazon EBS 为例，官方建议创建快照前暂停写入，以获得一致且完整的快照；不同平台和备份工具的处理方法要分别确认。[3]
对数据库，不应只把正在使用的数据目录打包就认定完成备份。使用数据库支持的备份方式，并安排文件与数据库在逻辑上匹配。例如恢复到昨天的数据库，却使用今天被替换的上传文件，可能出现缺图或附件不一致。
四、独立副本防的，是共同故障
同一账号中的服务器和快照，可能一起受账号失去访问、误操作或权限问题影响。独立副本应考虑位置和权限上的分离：把恢复所需数据放在另一处，使用与日常服务器不同的访问方式，并保留受保护的历史版本。
有副本但没有解密密钥，也恢复不了。把密钥、恢复步骤和联系渠道纳入演练。同步也不能替代历史备份：若错误删除立即同步到另一处，你只是得到两个同样缺数据的位置。
五、给内容站一份可调整的计划
以下是一个起点示例：数据库每日备份，上传目录按变动频率备份，重大更新前额外创建恢复点；保留近期每日版本，再保留较稀疏的较早版本。副本存放在独立位置，每月抽取一次完整恢复演练。频率应按你的 RPO、数据变化和存储费用调整。
每次记录备份是否结束、文件大小是否异常、是否有缺失、保留策略是否执行。失败要能被发现，而不是等到故障才看到三个月前的红色日志。AWS Backup 的责任说明同样强调定期验证恢复能力。[4]
六、恢复演练要验证业务，不只验证解压
- 在隔离测试环境准备兼容的系统与程序版本。
- 恢复文件、导入数据库，并更新测试环境配置。
- 检查首页、文章、图片、登录与表单等核心流程。
- 测试环境禁用真实邮件发送、付款与其他外部写入。
- 记录耗时、缺失步骤与需要的权限，修正文档。
如果无法从现有副本恢复，优先修复备份链路，而不是购买更大的备份空间。我们的判断标准很简单：能够完成一次可重复的恢复，才算拥有一套可用的备份方案。
常见问题：有 RAID，还需要备份吗？
需要。硬件冗余可以应对部分磁盘故障，但误删除、应用错误、账号问题与历史数据回退，需要不同的保护方法。采购时分别询问硬件冗余和数据恢复功能，不把它们当作同一件事。