很多人把数据放上云服务器，默认机房在大厂手里，总比自己家里那块硬盘稳。这个判断大体没错，但稳不等于不出事。云服务器厂商把数据搞丢的情况确实发生过，而且出事的不只是小厂。
这里不讲吓人的故事，只说两个真实发生过的案例，然后讲普通用户和小团队可以提前做哪些事。
案例一：机房失火，备份跟着一起没了
2021年3月，法国云服务商 OVHcloud 位于斯特拉斯堡的一座数据中心发生火灾。机房里有大量客户的服务器和存储，火灾之后部分服务中断，一些客户的数据无法恢复。
事后讨论最多的其实是备份。有的客户把备份放在同一机房、同一区域，主数据和备份一起受损。也有客户以为厂商每天都会自动备份，结果发现备份策略并不覆盖自己的全部数据。问题往往出在没有人去核对这件事。
这个案例的教训很直接：备份如果和原数据落在同一个故障域里，遇到大事故时，它们会一起倒下。
案例二：一次配置问题，差点把整套资源带走
2024年5月，澳大利亚养老金基金 UniSuper 遭遇了一次云端事故。据公开报道，起因是云服务商的一次配置问题，该基金在谷歌云上的一个私有云订阅被误删，服务随之中断。
恢复过程值得细看。UniSuper 能在约一周内恢复大部分服务，靠的是在另一家云服务商那里保留的备份。如果所有数据都只放在一家厂商的体系里，事情会麻烦得多。
这件事提醒的是：权限体系和自动化工具确实方便，但配置错误、账户层面的问题、误操作，都可能让一整套资源同时消失。只依赖单一厂商的话，很难靠自己把东西找回来。
“厂商负责”通常只负责一部分
不少人对云服务的理解停在“买了就有人管”。实际情况是，云厂商通常承担的是基础设施的可用性，比如机房供电、网络、硬件维护。数据本身的完整性、保留时长、恢复策略，很多要看你自己的配置，也要看合同条款怎么写。
常见的几个误区：
- 开通了云盘，就以为有了备份。云盘本身也可能落在同一个故障域里，它更像是另一块硬盘，而不是另一份副本。
- 快照当备份用。快照如果和源数据在同一账户、同一区域，账户出问题时，它照样可能被一起删掉。
- 看到“可用性 99.9%”，就觉得数据有保障。可用性说的是服务能不能访问，数据持久性是另一回事，两个指标别混着看。
- 以为删除有回收站兜底。不同产品的保留时间和恢复条件各不相同，用之前去看具体产品的文档，别凭印象。
小团队和个人可以先做的五件事
方案不必复杂。下面这几条基本能覆盖大多数风险，做完会踏实很多。
- 备份放到异地。至少留一份副本在另一个地域。条件允许的话，放到另一家厂商那里，哪怕只是每周同步一次的冷备份。
- 备份权限单独管。备份存储使用独立的账户或访问凭证，不和日常运维共用。这样主账户被误操作或被盗时，备份还有一道门挡着。
- 定期做恢复演练。备份存在，不代表能用。拿一份备份还原到测试环境，检查应用能否启动、数据是否完整、耗时多久。第一次演练常会暴露一些问题，越早发现越好。
- 给重要资源开删除保护。数据库、对象存储桶、磁盘这类资源，尽量打开删除保护或版本控制。它防不住所有事故，但能给误删操作留出缓冲时间。
- 读一遍服务条款中关于数据的部分。重点看数据保留期、故障时的赔偿范围、备份是否默认包含。价格表和性能参数固然重要，但真出事的时候，最先要查的是这些条款。
写在最后
云服务器本身不是问题，问题在于很容易把“方便”当成了“安全”。大多数时候厂商都能把事情做好，但数据的最后一道防线，还是要握在使用者自己手里。备份做到异地、隔离、可恢复，比事故之后再去谈赔偿要踏实得多。
