云端备份：AWS 无法恢复的那部分数据

想象一下，周一早上你打开系统后台，看到服务商的这样一条通知：你的部分数据无法恢复。不是"需要一些时间"。不是"我们正在处理"。就是回不来了。据《华尔街日报》报道，在中东的设施遭到伊朗方面袭击后，AWS 向客户发出的大致就是这样的通知。这类消息会让所有依赖云的人停顿一秒，然后想：如果是我呢？答案完全取决于你现在的云端备份是怎么搭的。

我说得直接一点：我服务过的大多数公司其实没有备份。他们只有一种"有备份"的感觉。这是两回事。

"可是它在云上，不是很安全吗？"

这是今天技术领域里代价最高的一个误解。

云很好地解决了一个具体问题：它让你不用再买服务器、换烧坏的硬盘、付机房空调的电费。但它没有替你承担数据的责任。所有大型服务商都把这一点写进了合同，叫做责任共担模型。他们负责基础设施。你负责放进去的东西。

翻译成老板听得懂的话：如果数据中心化为灰烬，服务商会把服务还给你。你的文件呢？只有你事先让人把它复制到别处，才还得回来。

这里还有一个技术细节骗了很多人。你购买云服务时，会选一个"区域"，比如圣保罗或北弗吉尼亚。一个区域内有多个可用区，也就是不同的机房建筑。大多数系统配置成能扛住一栋楼倒下。几乎没有系统配置成能扛住整个区域消失。而战争、自然灾害、大火或司法封锁，出现的恰恰就是区域级的场景。

这不是假设，已经发生过好几次

战争听起来很遥远。那我们换几个更贴近日常的例子。

2021 年 3 月，欧洲最大的云服务商 OVH 位于斯特拉斯堡的一个数据中心被大火烧毁。整栋楼。数千客户的数据永久丢失。很多人在那一天才发现，自己花钱买的"备份"就在着火的同一个园区里。有些公司直接倒闭了。

2014 年，为其他公司托管代码的 Code Spaces 遭到攻击。入侵者进入 AWS 管理后台，把数据连同备份一起删除了，因为备份和生产在同一个账号下，用的是同一套凭证。这家公司在不到 24 小时内宣布停止运营。

2023 年，一家韩国服务商在勒索软件加密了生产环境和相连的备份后，丢失了客户数据。模式一再重复：备份是存在的，但它就在同一个问题的打击范围内。

和原始数据一起消失的备份，从来就不是备份。那只是风险的第二份副本。

你真正需要放在服务商之外的东西

IT 行业有一条老规矩，叫 3-2-1，它老得很好。数据三份副本，存在两种不同的介质或平台上，其中一份放在主场地之外。

对于跑在 SaaS 上的中小企业，我会这样调整：

• 一份放在主要服务商之外。 如果你的系统跑在 AWS 上，安全副本就不能只存在 AWS。可以放到 Google Cloud，放到 Backblaze 这类便宜的存储，甚至放到办公室的 NAS 里。
• 一份是生产系统删不掉的。 独立凭证、独立账号，最好带有一段时间内禁止删除的机制（不可变存储）。这一条能救你于勒索软件，也能救你于一个生气的员工。
• 一份是脱离服务商也读得懂的格式。 CSV、JSON、PDF、SQL。如果你 CRM 的备份只能在这个 CRM 里打开，而 CRM 已经没了，那你手上就是一个漂亮但没用的文件。

第三点在 SaaS 场景里最容易被忘掉，也最重要。你不只是在基础设施的云上。你还在各种业务系统里：进销存、财务、营销自动化、Notion、ClickUp、企业微信。每一个都装着你生意的一部分。每一个都可能因为怀疑信用卡欺诈把你封停、终止某个套餐，或者干脆出故障。

几乎没人做的那个测试

下面这个问题我在每次初次会面时都会问，而且几乎每次都会让对话卡住：你上一次恢复备份是什么时候？

不是"生成"。不是"确认文件存在"。是真正恢复出来，打开，看了数据，确认东西都在。

没测试过的备份就是一种宗教信仰。我遇到过一个跑了八个月的导出任务，每天生成 0 KB 的文件，因为 API 密码早就过期了，而没人看报错邮件。我也遇到过完美、完整、无损的数据库转储，但缺了附件目录：所有签好的 PDF 合同、所有产品照片，一样都不在备份里。数据库里有文件的路径。文件本身没有。

每个季度做一次。取最新的备份，在一个独立环境里恢复，然后试着回答三个简单的问题：

1. 最近七天的数据在吗？
2. 附件和图片能打开吗？
3. 从零到能用，花了多长时间？

第三个答案就是你真实的恢复时间。如果它是八小时，而你的生意撑不过两小时，那你的问题不在备份，而在架构。这种事在测试里发现，总比在危机里发现好。

你能承受停多久，能承受丢多少数据

两个问题就能解决 90% 的规划工作，而且两个都不是技术问题。

生意能承受停多久？ 一小时？一天？一周？一家网店停一天会少卖点东西，之后能恢复。一家诊所一天调不出病历，整天的预约全得取消，口碑也被伤到了。

生意能承受丢多少数据？ 如果备份在凌晨跑，问题发生在下午五点，你就丢掉了一整天的工作。每一笔订单、每一通记录的电话、每一次客户接待。对有些生意来说这可以接受。对另一些则完全不行，那备份就必须是持续的。

用一个具体数字回答这两个问题，剩下的就只是执行了。没有这两个答案，别人卖给你的任何方案都是开着发票的瞎猜。

成本当然有，但比大家想的少得多。把 500 GB 放进另一朵云的冷存储，一个月大概十几到几十块钱。每天复制、测试、失败时通知你的那套自动化，是一次性的配置工作，不是永久订阅。拿它和停工一周的损失比一比，这笔账自己就算清楚了。

这周可以做的事

你不需要一个六个月的项目。你需要一个下午。

把你生意里存放重要东西的所有系统列出来。业务系统、财务、CRM、邮件、文件、网站。对每一个写下三件事：数据在哪里、有没有自动导出、谁能访问这份导出。光是把这张表列出来，通常就会暴露出两三个从没人知道的漏洞。

然后，挑出最关键的那个系统，配置每天导出一份到原服务商之外的地方。就一个。从丢了最心疼的那个开始。

AWS 这条新闻因为牵扯到导弹而显得戏剧化，但教训很平常，对永远不会靠近冲突区的人同样适用。任何你无法替换的依赖，都是在赌不会出事。而事情总会出，早晚而已，通常是在周五下午。

如果你想听听第二种意见，看看你的架构漏洞在哪里，跟我说说它现在是怎么跑的。大多数情况下，用简单的自动化就能解决，而且不用换掉你已经在用的任何东西。

AWS 通知客户，有一部分数据根本回不来了。不是"要等一段时间"。是回不来。

我服务过的大多数公司其实没有备份。他们只有一种"有备份"的感觉。

云负责基础设施。你的数据依然是你自己的责任，合同里就是这么写的。

还有一个几乎每次都让会议卡住的问题：你上一次真正恢复备份是什么时候？不是生成。是恢复、打开、逐项核对。

我见过一个跑了八个月的任务，每天生成 0 KB 的文件。因为 API 密码过期了，而没人看报错邮件。

和原始数据一起消失的备份，从来就不是备份。那只是风险的第二份副本。

如果你愿意，可以跟我聊聊你现在的架构。大多数情况下，用简单的自动化就能解决，不用换掉你已经在用的任何东西。

#备份 #云计算 #风险管理 #科技 #中小企业