不少人买完云服务器，把网站或业务系统跑起来就觉得万事大吉。等某天误删了数据库，或者账号被人乱操作，才突然想起来：云服务器备份数据到底做没做，做得对不对？这篇文章从一个常见的事故过程讲起，说清楚备份该怎么想、哪里容易踩坑，以及小团队可以直接照着做的步骤。
事故是怎么发生的
有个做独立站销售的小团队，服务器上跑着商城和订单系统，数据库里大概有三年的订单记录。一次例行维护时，运维同事在清理测试数据，执行了一条范围过大的删除命令，生产库里的部分订单表被清空。团队打开云平台控制台一看，最近的快照是十一天前自动生成的。也就是说，这十一天的订单只能靠支付平台对账和人工回填，前后折腾了两周。
复盘下来，问题不在于没有备份，而在于备份只是“有”，却没人问过三个问题：多久备一次，能恢复到哪个时间点，恢复一次要花多长时间。这三个问题对应的就是恢复点目标（RPO）和恢复时间目标（RTO）。如果业务能接受的最大丢失是一小时，快照间隔就不可能是十一天。
先把三个数字定下来
- RPO：最多能接受丢多少时间的数据。订单类业务一般要按小时甚至更短来算，内容博客按天备份通常也够用。
- RTO：出问题后多久必须恢复运行。影响交易的系统以小时计，内部报表系统可以放宽很多。
- 保留周期：备份留多久。有些审计或合规要求需要保留几个月，只留最近几天，遇到需要追溯的问题时就帮不上忙。
这三个数字一旦定下来，备份频率、存放位置和成本都有了依据。否则配置大多是凭感觉来的，出了事才发现不够用。
备份类型怎么选
云服务器上的备份大致分三类，各自擅长的事情不太一样。
- 磁盘快照：对整块云硬盘做时间点副本，整机回滚很快，适合系统盘和整体环境。缺点是快照按块保存，很难只还原某一张表或某一个文件。
- 数据库备份：用 mysqldump、pg_dump，或者云数据库自带的备份功能，导出逻辑数据或物理备份集。能精确恢复某个库、某张表，跨版本迁移也方便。
- 文件级备份：把网站代码、上传文件和配置目录同步到对象存储或另一台机器，一般用 rsync 或备份工具定时执行。
回到前面那个小团队，比较合适的组合是：快照每天一次，保留七天；数据库每小时增量备份加每日全量；业务文件每天同步到对象存储。快照兜底整体，数据库备份负责精细恢复，两者分工明确，缺了哪一块，都会在某些场景下很被动。
可以直接照做的流程
- 列出需要备份的内容：数据库、上传目录、配置文件、系统盘，并给每一项写上对应的 RPO 和 RTO。
- 开启云平台的自动快照策略，执行时间避开业务高峰，快照上打好用途和日期标签，之后找起来不费劲。
- 编写数据库备份脚本，导出后立即压缩和加密，文件名带时间戳。数据库密码放进环境变量或密钥服务，别明文写在脚本里。脚本一旦被带出仓库，密码就跟着泄露了。
- 把备份文件同步到另一个可用区或另一个地域的对象存储。同城备份能应对硬件故障，遇到机房级事故，还是要靠异地副本。
- 给备份桶开启版本控制和访问日志，再设置生命周期规则，超过保留期的旧文件自动清理。
- 每月至少做一次恢复演练：把备份还原到测试实例上，看数据是否完整，服务能否正常启动。没演练过的备份，其实没人知道能不能用。
几个容易忽略的细节
第一，备份权限要和生产权限分开。如果运维账号既能删生产数据，又能删备份，出问题时两头都会丢。备份存储最好用单独的账号，并且只给写入或只读的权限。勒索类事件里，攻击者往往会先找可以删除的备份，这一点需要提前堵上。
第二，备份本身也要加密。备份文件一旦外泄，风险不比丢数据小，尤其是里面有用户手机号、地址、支付信息的时候。密钥要妥善保管，同时至少要有两个人知道怎么使用，否则备份就成了打不开的密文。
第三，备份任务的执行结果要有人看。脚本静默失败很常见，建议备份完成后发通知，失败时告警。不少团队是在真正需要恢复的时候，才发现备份已经断了好几个月。
小结
云服务器备份数据不是开一个快照功能就能一劳永逸的事。先弄清业务能承受多少丢失和停机，再选合适的备份类型，配合异地存储、权限隔离和定期演练，备份才算靠得住。文中那个小团队事后做的第一件事，是把数据库改成每小时备份，并且每月做一次恢复测试。这些改动成本不高，却让下一次意外只是一次普通的回滚。
