云上一夜之间停了，数据只能靠你自己的备份

原创

tcode
tcode

字节脉搏实验室

2026年10月12日 12:32
北京

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

凌晨三点四十，一整片区域被剪了下来

二〇二六年十月七日，日本时间凌晨三点四十分左右，IDCFクラウド 的服务开始出现异常，事后查明问题集中在东日本区域一。当天 IDC Frontier 在官网挂出第一份公告，只有几句话：公司旗下云服务的部分系统遭到第三方非法访问，服务出现故障，受影响的客户由厂商单独联系。这家公司隶属软银集团，主营数据中心与云计算业务。

对使用者来说，那一天的异常分两步出现。先是落在东日本区域一里的虚拟服务器停了，而且起不来；接着他们想去控制台把机器重新拉起来，发现登录入口也已经关闭。第一份公告没有写攻击类型，也没有写影响到多少客户，这些内容是在后面三份公告里逐步补上的。

先把两个词分开。区域是云厂商的地理单元，分区是区域内部的隔离单元。厂商把区域拆成分区，本意是让单个机房的故障不蔓延到整片区域。这次事件里，同一个区域的四个分区被一起处理，因为问题出在平台侧，分区隔离并没有自动变成保护。这一段属于编辑推断，公告没有说明攻击者从哪一层进入。

五小时二十分，厂商用它确认自己出了什么事

把四份公告排成时间轴，能看到一次典型的逐步确认。十月七日第一报只说部分系统遭到非法访问；同一天的第二报把性质写明，是第三方发起的勒索软件攻击，并第一次给出客户范围，四百九十五家企业与自治体。十月八日第三报给出具体范围，东日本区域一的 tesla、henry、pascal、joule 四个分区，同时列明症状是虚拟服务器停止与无法重启。十月九日第四报只讲应对体制，宣布十月七日九时设置紧急对策本部，与母公司软银联动。

日期本身就是一条信息。故障发生在十月七日三点四十分，紧急对策本部成立在当天九时，中间隔了五小时二十分，这段时间就是厂商自己定位问题所花的工夫。据此做业务判断时，把厂商的第一份公告当成已知现象，而不是全部事实，是更稳的读法：重大事件里，第一报通常只敢描述现象，性质、范围、影响面和恢复预期都要等后续几报补齐。

最贵的一句话落在数据上

第三报里最该被运维抄进笔记本的一句话是关于数据的：存放在这四个分区内的客户数据，取出与恢复都很困难；按厂商目前的判断，数据恢复只能依据客户自身持有的备份来完成。

这句话的主语要读清楚。它不等于厂商没有备份，也不等于数据一定丢了。它说的是经由平台侧把数据取回来的路走不通，能走的路在客户手上那份备份。对使用者来说，它的实用价值只有一条：把云厂商会兜底这个假设从预案里删掉。

同一份公告还写了一个容易被跳过的状态。客户管理控制台停止期间，启动和停止虚拟服务器这类操作，改由厂商按客户要求代为执行。运维最日常的动作是登录控制台重启一台机器，这段时间只能走人工通道。

备份要过三个字段，才算备份

云上一出事，最常见的误解是我们开了备份。这次事件给出了一个当天就能用的检查方法：把生产环境和备份存储的账号、区域、服务商三个字段并排写出来。三者与生产完全一致，同一区域整体不可用时，这份备份在可预见的窗口里也用不上。

第二项是恢复凭据。控制台停止期间，能用的只有不依赖它的路径：基础设施即代码的配置文件、资产清单、监控代理上报的实例列表、独立的备份管理凭据。缺了这些，事故当天的第一小时里，你甚至说不清自己有多少台机器。

第三个检查项才是恢复演练，而且必须带判定标准：不碰生产云控制台，用独立凭据把一台机器还原出来，并让服务真正跑通。做不到，就说明恢复路径还挂在那条已经被剪断的链路上。

顺带分清备份与灾备这两个常被合并的词。备份是数据的副本，回答数据还能不能找回来；灾备是可运行的替代环境，回答业务还能不能跑起来。公告里前者被写明只能依赖客户自己，后者体现为厂商建议受影响客户另备环境重新搭建。两件事的预算、演练方式和验收标准都不同，用一套流程覆盖，通常两头都不够。

区域一之外，为什么也建议自己备份

第三报把客户分成两类。区域一那四个分区属于第一类，厂商建议客户准备另一套环境重新构建，数据从自己保存的备份恢复。区域一其余分区、东日本区域二与区域三、西日本区域一属于第二类：目前没有确认遭到非法访问，但厂商同样建议客户自己完成数据备份，并说明备份的获取方法会陆续告知。

第二类客户的处理方式值得多看两眼。他们被告知尚未发现入侵，但这不构成不需要备份的理由，厂商给他们的建议与第一类是同一个方向。把未确认读成安全，是事故通报里最常见的一次误读。

还有两条边界要提前说清。公告写明 TypeS 与私有云不在本次事件范围内，以私有化方式使用该厂商云服务的客户不在名单里。另外，网络上流传的数据量、快照数量这类规模数字，若来自攻击方自述，就不属于已确认事实，本文不采用。

今天就能做的四件事

第一，盘清资产与分区。对每一家云厂商，把业务落在哪个区域、哪个分区、多少台实例、对应哪些对外域名写进同一张表。事故第三天再去找这份清单，代价远高于今天花半小时整理。

第二，判断依赖边界。逐条回答三个问题：控制台不可用时哪些操作还能做；谁的凭据离开控制台就失效；哪些日志只存在云平台上，本地没有副本。

第三，校正备份假设。对核心系统做一次换机恢复演练，记录恢复耗时，并让备份存储与生产在账号、区域、服务商三项里至少拉开一项。

第四，把厂商的故障通知接进值班群。IDC Frontier 在官网单独设有故障与维护信息页面，这在日本厂商中是标准做法。区域级通知早一分钟到手，和事后由同事转发一条链接，处理节奏完全不同。

第四报里还有一个细节可以抄进应急预案。厂商把客户支持窗口交给母公司的法人部门，工作内容分成三块，告知备份步骤并提出迁移环境方案、按客户要求代做虚拟机启停、推进详细调查与恢复计划制定。事故当天最容易被忽略的往往不是技术，而是有没有人统一回答同一批客户的重复问题。

一个可以拿去内部会议上问的问题

如果明天早上我们的云控制台登不上去，谁能凭现有材料说出我们有多少台机器、分别跑着什么服务、最近一次可用的备份在哪、用什么凭据恢复。四个问题答不全，缺的就是这次事件里最贵的那部分准备。

公告说到了哪一步，没说到哪一步

四份公告确认了攻击性质、客户范围、受影响分区和数据的恢复口径，但入侵路径、攻击者身份、被加密的数据量都没有披露，公告写明相关调查仍在进行。厂商没有公布逐家客户名单，本文也不评价任何一方的处置对错。文中事实全部来自厂商四份日文公告原文，发布时间分别是十月七日、十月八日与十月九日，未采用二手转述中的推算数字。

来源

1. 【第1報】当社サービスの一部システムに対する不正アクセスについて（IDCフロンティア）；发布时间：2026-10-07；时区：Asia/Tokyo；https://www.idcf.jp/news/topics/20261007001；首次公告：部分系统遭第三方非法访问，服务部分故障，受影响客户由厂商单独联系；事发时间记为当日凌晨三点四十分左右

2. 【第2報】当社サービスの一部システムに対する不正アクセスについて（IDCフロンティア）；发布时间：2026-10-07；时区：Asia/Tokyo；https://www.idcf.jp/news/topics/20261007002；首次写明性质为第三方勒索软件攻击、受影响客户四百九十五家企业与自治体、东日本区域一自网络切断后停机、其他区域管理控制台暂停

3. 【第3報】当社サービスの一部システムへの不正アクセスによる障害について（IDCフロンティア）；发布时间：2026-10-08；时区：Asia/Tokyo；https://www.idcf.jp/news/topics/20261008001；受影响分区为 tesla、henry、pascal、joule；虚拟服务器停止且无法重启；该四分区客户数据取出与恢复困难，恢复只能依赖客户自身备份；代客执行虚拟机启停；TypeS 与私有云不在范围内

4. 【第4報】不正アクセスによる障害への対応体制について（IDCフロンティア）；发布时间：2026-10-09；时区：Asia/Tokyo；https://www.idcf.jp/news/topics/20261009001；十月七日九时设置紧急对策本部，与母公司软银联动；客户支持窗口交由软银法人部门，含备份步骤说明、迁移环境提案、代客虚拟机启停、调查与恢复计划制定执行