云厂商说「部分数据恢复不了」：备份从来不是云的默认项

一条让人不舒服的新闻

近期有报道称，AWS 承认其位于中东的部分设施在遭遇袭击后，有些数据已经无法恢复。这条消息很快就从热搜上消失了，但它在运维圈里留下的震动不小：一家以基础设施可靠性为卖点的厂商，公开说出「恢复不了」这四个字，本身就说明了一件事——云提供的是持久性，不是可恢复性，这两件事不是一回事。

「备份不是一件简单的事」

同一周，一篇题为《Backups aren't simple》的博客在技术社区里被反复转发。作者的经历很朴素：家里把照片全拷到一块移动硬盘上，结果父亲为了接电视盒子把盘格式化了。他后来复盘说，这不该怪父亲，要怪的是「所有重要东西只放一个地方」这个结构性问题。

文章里有几个判断值得抄下来：机械硬盘的磁颗粒会漂移，固态硬盘的 NAND 会漏电，冷数据也会腐烂；勒索软件会把在线备份一起加密；而 RAID 1 那种镜像方案根本不是备份——它只保证盘坏了能换，不保证你能回到误删之前。真正的备份要能回退到某个时间点，所以要谈 RPO，也就是你能接受丢多少小时的数据。

责任共担模型里的灰色地带

云上的责任共担说得很好听：底层基础设施归厂商，你的数据归你。但现实里的坑全在中间——对象存储开了版本控制却没有跨区域复制；数据库做了自动快照，主账号一被盗全被删；备份在同一朵云、同一个账号、同一个区域里，等于把三份鸡蛋放进了同一个篮子的三个格子里。

这几条都不是技术难题，而是承诺边界没想清楚。做架构评审时，与其问「有没有备份」，不如问三个更硬的问题：备份存哪、谁能删、多久真的恢复演练过一次。

给中小团队的可执行清单

不需要复杂的方案，先把四件事做掉：备份必须落在与生产不同的账号或不同的地域；保留至少一份离线或不可变副本；把恢复步骤写成一张真的会被执行的纸，每季度演练一次；把「谁能删除备份」这条权限单独收紧。

比这四件事更难的只有一件：在没人出事的时候，说服自己把它做完。