云服务器备份 CBR 怎么用：备份策略与恢复的实践笔记

前几天帮朋友排查一台云服务器：系统盘配置文件被误改，服务起不来，才发现这台机器从来没有做过备份，最后只能凭记忆重写配置。从那以后我的规矩是：跑了业务的 ECS，先把备份搭好，再谈优化。这篇笔记记下我用 CBR 的做法：备份策略怎么定、恢复演练怎么做、恢复时容易踩的坑。

一、为什么要给 ECS 做备份

很多人觉得云服务器本身很可靠，备份是多余的。这话只对了一半：云平台保障的是基础设施的可用性，保不了我们自己的误操作。误删文件、升级失败、配置改错、文件被篡改，这些都是平台兜不了底的。备份的意义，就是给系统留一个能回得去的时间点。CBR 可以对整台 ECS 做备份，系统盘和数据盘一起打包，恢复时按备份点整体还原。

二、备份策略怎么定

策略不用一开始就定得很复杂，抓住三个要素：备份什么、多久备一次、留多久。第一，备份对象。业务机整机备份最省心，系统盘加数据盘一起备；只备数据盘也可以，但系统盘的配置也要有地方留底。第二，频率。变化不大的测试机一周备两三次够了；每天写数据的业务机，我一般设每天一次，放在凌晨两三点低峰期，CBR 支持按策略自动执行。第三，保留期。留得越久占用的备份空间越多。我的做法是：日常备份保留 7 天，发版、大促或大改配置之前，再手动备一次，单独保留 30 天。既不会把存储撑爆，关键节点也有兜底。

三、恢复演练怎么做

备份做完了不等于能恢复，一定要演练。我每个月挑一台非核心机器做一次恢复演练：先在 CBR 里选一个备份点，用它恢复出一台新 ECS 或把原机磁盘还原到备份点；起来后检查服务能不能正常启动；确认没问题，演练用的机器就释放掉。演练的重点是确认两件事：备份本身是好的，恢复步骤自己真的会。真到故障那天，没人有时间现学。

四、恢复时要注意什么

恢复时有几件事要提前想清楚。第一，恢复是按备份点整体还原的，备份之后产生的新数据会被覆盖，动手前先把新增的重要数据拷出来。第二，恢复到原机还是新机要想好：原机恢复快，但会把现场覆盖掉；新机恢复更安全，可以先在新机上验证，没问题再切流量。第三，恢复后不要只看机器能不能开机，还要检查网络、安全组、挂载的磁盘是不是都对，应用配置有没有因为 IP 或主机名变化而失效。第四，恢复完记得确认下一次自动备份还在正常跑，别恢复一次就把备份链断了。

备份平时看不出价值，出事那天就是全部价值。策略不用追求完美，先让自动备份跑起来，再按业务节奏慢慢调；演练不用很频繁，但一定要真的做过一次。