做运维的人，或者自己开店的人，多半都有过一次心里发凉的经历：一条误删命令敲下去，几年攒下的订单数据就没了。那时候想起备份，通常已经晚了。这篇讲讲怎么在阿里云上配好阿里云备份，让出事那天不至于手忙脚乱。
先弄清楚哪些数据要备份
备份不是把整台机器打个包就完事。先看看数据都放在哪，大致分三类，每类的做法不一样。
- 系统盘和应用环境，比如操作系统、运行时、配置文件。这部分一般用快照就能覆盖，出问题时整体回滚，比一个个文件去找要快得多。
- 数据库，比如 RDS 里的业务表。要按时间点做备份，因为很多事故往往是某张表、某批数据被改错了，需要回到出事前的那个时刻。
- 对象存储里的文件，比如用户上传的图片和合同扫描件。开启版本控制，文件被覆盖或误删后，还能找回旧版本。
盘点的时候可以顺手问一句：如果这份数据今天没了，哪个业务会先停？能回答出来的，优先级就排在前面。
一个误删订单表的例子
有个做本地生鲜的小团队，订单系统跑在一台 ECS 上，数据库用的是 RDS。某次运维同学清理测试数据时，把生产库里的一张订单表误删了。他们当时的处理顺序是：先停止写入，然后用 RDS 的备份在新实例上恢复到故障前五分钟的时间点，再把差异数据手动补回来。整个过程大约两个小时，业务影响基本限制在一个下午。
事后复盘，起作用的是两件很朴素的事。一是数据库本来就开了自动备份，并且保留了一段时间。二是恢复前先停写，否则新数据会把旧版本覆盖掉，后面想回退就麻烦了。
恢复之前先别急着点按钮
出事的时候，人最容易直接点恢复。但有几步值得先做，花的时间不多。
先给当前状态拍一个快照。哪怕现在的数据已经是错的，它也可能是后面对比的依据。万一恢复结果也不对，还能回到这一步。
再确认要恢复到哪个时间点。别凭记忆估计，最好翻一下操作日志，找到误操作前的那个时间。估计偏了几分钟，补回来的数据就可能对不上。
最后恢复到新实例上验证，数据没问题再切换业务流量。这样即使恢复过程出了岔子，原来的环境也不会再被伤到。
搭建备份方案时的几个要点
如果打算在阿里云上把备份体系搭起来，下面几条可以当作检查表用。
- 遵循 3-2-1 原则：至少三份数据，两种存储介质，其中一份放在异地。很多人只有一份备份，还放在同一台机器的另一块盘上，这其实不算备份。
- 给快照和备份设置保留策略，比如每日保留七天、每周保留四周。没有策略的话，历史快照会越攒越多，存储费用慢慢失控，到时候临时删，反而容易删错。
- 重要的对象存储数据可以做跨地域复制。遇到某个地域出问题时，另一地域还有一份可用副本。
- 定期做恢复演练。备份做得很勤快的团队不在少数，但从来没验证过能不能恢复，等真出事才发现文件是坏的，那时再补救就晚了。演练可以每季度挑一个库，恢复到测试环境，看看数据和应用能不能跑起来。
备份本身也要设防
备份数据同样是敏感资产，权限不能给得太宽。用 RAM 子账号细分权限，只给需要的人恢复或删除的权限，不要让所有人都用主账号。备份存储桶要关闭公共读，并开启操作日志审计，谁在什么时候动过什么，能查得到。
删除备份的操作建议加二次确认，或者要求多人审批。否则有人一个手滑，历史版本可能被一起带走，那就等于把最后的安全网也拆了。
写在最后
备份没有一劳永逸的办法。比较理想的状态是策略清楚、自动执行、定期验证、权限可控。把它放进日常运维里，而不是等出事后再补。
如果你现在还没有任何备份计划，今天就可以先检查一下数据库的自动备份是否开启。这一步成本最低，见效也最快。
