「放云上就安全了」最贵的一课：495 家机构被勒索后，云厂商说恢复只能靠你自己的备份

第三份公告里最重的一句话

2026 年 10 月，日本云服务商 IDCF 发布第三份事故公告：东日本区域 1 的 tesla、henry、pascal、joule 四个可用区遭第三方勒索攻击，故障自 10 月 7 日凌晨开始，虚拟服务器停止且无法重启，共 495 家企业与自治体受影响。公告里最冷峻的一句是：受影响区域保存的客户数据预计难以提取或恢复，恢复只能依靠客户自行持有的备份——公司已隔离网络、关停管理控制台，建议客户在别的环境重建业务。

三个必须分开的概念

服务器能重启、数据能取回、业务能恢复，是三个不同的问题。新虚拟机随时能建，但 ERP、订单、客户系统没有可用数据就是一具空壳。而"数据在云上"的普遍误解在于：云厂商承诺基础设施的可用性与持久性，并不承诺你的数据在逻辑损坏或加密攻击下可恢复。多副本也不是备份——副本会忠实地把勒索软件的密文一起复制。值得注意的是，厂商事后做的网络隔离、关停控制台都属于"止损"动作，而不是"取回数据"的动作：共享责任模型里，"数据可恢复性"这半句写在你的义务栏里，不在他们的 SLA 里。

备份纪律的硬清单

1. 3-2-1 再加一：3 份副本、2 种介质、1 份异地，外加 1 份离线或不可变（对象锁、WORM 存储）；
2. 账号隔离：备份账号与生产账号权限互斥，勒索者拿下生产凭据也删不动备份桶；
3. 跨区不等于跨灾：同一云同一区域的多 AZ 副本，挡不住区域级事件；
4. 季度恢复演练：抽样还原并计时，RTO/RPO 必须是数字不是形容词——没演练过的备份等于没有备份。

给依赖单一云侧的提醒

源站与关键业务数据至少留一条"出逃通道"：可迁移的导出格式、第二云的最小镜像、或源站挂了怎么办里那条自建兜底。把鸡蛋分篮子不是不信任云厂商，而是对共享责任模型的正常尊重——架构上如何把"分离"做成最后一道防线，全球平台连环宕机给站长的一课 已展开。

一句结论

云端存储解决的是"会不会丢盘"，你自备的备份决定的才是"会不会丢生意"。495 家机构已经替全行业交过一次学费了。
更多实操文章见 资讯中心。