很多小团队做备份的顺序是反的：先买存储，打开定时任务，然后才问能不能恢复。更可靠的顺序是：先决定哪些东西必须回来、多久回来、最多丢多少数据、谁能在压力下完成恢复。
先回答三个问题
- RPO：服务器现在消失，最多能接受丢失多久的数据？
- RTO：服务最多能停多久？
- 恢复顺序：哪些系统先回来，客户或团队才能继续工作？
答案决定工具。博客可能只需要每日数据库备份和每周媒体归档。小型交易站则可能需要更频繁的数据库备份、支付回调验证和 DNS 切换预案。
3-2-1 是底线，不是终点
3-2-1 规则指三份副本、两种介质、一份离站。它仍然适合作为记忆框架，但勒索软件让隔离变得更重要。被入侵服务器可以删除的备份，只能算便利副本。
- 至少一份副本放在主机账号之外。
- 生产服务器不能拥有删除历史备份的权限。
- 备份离开机器或存储边界前先加密。
- 恢复文档不能只存在已经故障的服务器上。
恢复测试才是真检查
备份任务成功，不代表恢复成功。常见失败包括环境变量没备份、数据库凭证过期、上传目录漏掉、软件版本不兼容、DNS 和证书步骤没人写下来。
| 资产 | 最低恢复测试 | 建议频率 |
|---|---|---|
| 数据库 | 恢复到临时实例，并跑一次应用迁移 | 每月 |
| 上传文件 | 抽查新旧文件并核对校验值 | 每月 |
| 服务器配置 | 按文档或自动化重建一台新机器 | 每季度 |
| 密钥 | 确认不依赖旧服务器也能访问密钥库 | 每季度 |
怎样理解硬盘故障数据
Backblaze 长期公开硬盘统计数据。Q1 2026 页面显示 341,263 块硬盘、1,030 次故障和 1.24% 年化故障率。小团队不需要照着买同款硬盘，真正的启发是：硬件故障普通到值得默认纳入设计。
小服务器备份模式
- 每日数据库 dump 到加密对象存储。
- 按 RPO 对应用数据做小时级或每日同步。
- 每周完整归档到第二个服务商或第二个账号。
- 每月恢复到一次性服务器。
- 每季度按文档或基础设施代码完整重建。