码农早餐 · 2026-09-18
今日头菜：AWS 说中东机房部分数据恢复不了：备份这件事，比你想的难。另有 7 条快讯：Nvidia 让 Rust 直接写 GPU 内核，两条路线并行；4B 模型生成的查询计划，比 Postgres 快 81%；等。
AWS 承认中东遭袭设施里部分数据无法恢复——不是延迟，是恢复不了，而报道里连哪几个可用区、多少客户、有没有赔付都没交代。云厂商的默认备份从来不是合同承诺，RPO 和保留策略得你自己先算清楚。
AWS 说中东机房部分数据恢复不了：备份这件事，比你想的难
先看事实：有报道称，AWS 表示在中东地区、遭伊朗袭击的设施里，部分数据无法恢复。原文只有标题和一句概述，没有交代是哪几个可用区、涉及多少客户、有没有赔付方案，也没说后来有没有回滚或补救。「云厂商帮你备份」这件事，从来不是合同里那句默认承诺。
为什么这事值得写代码的人停下来看一眼——因为它戳中的不是地缘政治，是每个系统里最被低估的一环：备份。有一篇讲得很细的文章把这件事拆开了：备份不是「再存一份」，而是一整套取舍。你至少得先回答两个问题——RPO（能容忍丢多少数据）和保留策略。作者给的参照是：关键金融机构的 RPO 可能小于 30 秒，而不少小企业是 24 小时甚至更久，有些压根没有灾难恢复方案。RPO 定 24 小时，一周就是 7 个快照，一个月 30 个，一年 365 个——不轮转，存储先撑不住。
于是就有了轮转：近的留密、远的留疏，日备留 14 天、周备留 7 周、月备留 12 个月，这就是 GFS 轮转 + 快照式备份。再往下还有一层：文件变更服从肥尾分布——绝大多数文件长期不变，极少数天天在改。所以不该存重复副本，而应该去重（deduplicate），用硬链接引用已有文件，一个文件在磁盘上只存一份，各个快照指向它。这招 rsync 系工具（比如 rsnapshot）在用，好处是轮转时只删目录项、不删文件本身，而且省带宽——你要传到云上的第二台机器，省下来的每一兆都是账单。
备份真正的难点不在「复制」，在「恢复」——没验证过的备份，等于没有备份。 文章里那串定语越堆越长：增量的、去重的、GFS 轮转的、快照式的……每加一个形容词，复杂度就涨一截。作者拿自己家 10 个 Docker 容器练手时就翻车了：很多容器会创建 root 属主的文件，cronjob 却以默认用户跑，日志里全是备份失败；数据库又爱把数据先放内存、再批量刷盘，直接拷文件根本拷不出一个一致的库。这些坑，跟你用什么云没关系。
对照一下就更清楚：RAID 1 做的是镜像，不是备份——勒索软件加密、手滑删错文件、脚本把盘写满零，镜像会一字不差地帮你把这些「同步」到第二块盘上。镜像管的是磁盘坏，快照管的是人犯错。这两件事经常被混成一件，直到出事那天才发现自己只有前者。至于云厂商那边，能恢复出多少、多久恢复，取决于它内部怎么切分和复制——这部分你看不见，也不在 SLA 的赔付范围里，它赔的通常是可用性，不是你的数据。
对写代码的人，具体要动的地方就三处：确认关键数据的 RPO 到底是多少（别写「越高越好」，写数字）；把备份脚本的失败告警接进你真正会看的渠道，而不是一个没人打开的日志文件；数据库别用文件级拷贝，用逻辑导出或它自己的快照机制。至于跨区域、跨云厂商的第二份——成本摆在那，值不值，得你自己按数据的重要性算。
💡 主厨说：那篇文章里最扎心的一句是「世界上有两种人：已经经历过灾难性数据丢失的，和即将经历的」——而备份轮转策略里，最容易被省掉的恰恰是「恢复演练」这一步，省它的理由永远是没时间，出事时的代价是全部时间。
来源：
- AWS Says It Can't Restore Some Data From Mideast Facilities Struck by Iran (WSJ)
- Backups Aren't Simple (filipovski.net)
Nvidia 让 Rust 直接写 GPU 内核，两条路线并行
Nvidia 宣布支持用 Rust 原生写 GPU 内核，官方给了两条路线。原文只有标题和这一句，两条路线具体怎么分、覆盖哪些场景，报道没展开。对写 Rust 的人来说，这意味着 GPU 这块长期被 C++ 占着的地盘，多了一个官方入口；但值不值得现在就迁，得等它把两条路线的边界、能用的工具链和限制条件讲清楚。新东西先看懂它到底改了什么，再谈要不要上车。
来源：
4B 模型生成的查询计划，比 Postgres 快 81%
有人训练了一个 4B 的小模型，专门用来产出查询计划，作者给出的数字是比 Postgres 自带的规划器快 81%。这事跟你的关系很直接：查询计划一直是数据库里最吃经验、最难调的那块，如果小模型真能在这一步上稳定赢过跑了二十多年的优化器，那「SQL 调优」这项手艺的入口会变。但我看这类结果第一反应是先问数据——81% 是在哪套 benchmark、哪些查询形态上测出来的，TPC-H 那种规整的查询和线上那种带一堆 ORM 拼出来的 SQL，难度完全不是一回事。原文只有一句结论，没有展开测试条件，所以这个数字先记着，别急着信。
来源：
花 9 美元让 Gemini 训练自己的替代品
有人发了一篇记录：花 9 美元让 Gemini 训练出它自己的替代品。原文只有标题，没展开训练数据从哪来、替代品是什么规模、这 9 美元花在了哪一步。所以现在能确定的只有一件事——有人把「用大模型造一个更便宜的自己」这条路径的成本压到了个位数美元。对写代码的人来说，这值得点开看看它到底怎么做的，但先别急着照搬。模型能力上限由数据决定，不看花了多少钱。
来源：
HarnessTax 实测：外壳对 coding agent 成绩影响多大
同一个模型，换个外壳跑，成绩能差多少？有人做了 HarnessTax 这个项目，专门量化 harness（也就是包在模型外面那层脚手架：工具调用、上下文管理、重试逻辑那一套）对 coding agent 表现的影响。这事跟你直接相关——你调 prompt、换模型换得勤，未必意识到真正拉开差距的可能是外面那层壳。原文只有标题和项目页，具体数字没展开，值不值得细看，得点进去看它到底在什么任务上测的。
来源：
DeepSeek v4.1 Flash 压 KV cache，三值模型另有其人
我们之前聊过 DeepSeek v4.1 Flash 的能力表现，今天这条转向另一面：同一模型线上，KV cache 压缩被推到了新的极限。KV cache 是长上下文推理里最吃显存的那块，压得动它，意味着同样的卡能塞进更长的上下文、更低的单次推理成本——对要自己部署的人来说，这是比跑分更实际的事。
另外有一篇讲三值 LLM 突破 1.58-bit 限制的工作，和上面这条是两回事，别混成一条看。三值量化省的是权重，KV cache 压缩省的是推理中间态，两条路都在往「更便宜地跑起来」走。至于压完之后能力掉不掉、掉多少，得看具体测在什么数据上，光看标题里的「极限」两个字说明不了问题。
来源：
- Breaking the 1.58-bit Barrier for Ternary LLMs
- DeepSeek-v4.1 Flash: Pushing the Limits of KV Cache Compression
480 分热帖：一页能抄的编程小技巧
Hacker News 上一条讲「小技巧」的帖子拿到 480 分，标题朴素到只有三个词，链接指向一篇个人博客，正文没给任何摘要。能在这个榜上冲到 480 分，通常意味着它写的不是新框架，而是那些你天天遇到、却总在重复踩的小坑——命名、边界、早返回这类东西。值得点开看看有没有一条能直接抄进你手头的代码。
来源：
GitLab.com 要改速率限制，只说了这一句
GitLab.com 的速率限制要变了，官方博客只给出一句「Rate limits on GitLab.com are changing」，具体怎么调、什么时候生效、影响哪些接口，原文都没展开。对天天把 GitLab 当代码托管和流水线底座的人来说，这事值得点进去看一眼，但眼下能确定的只有「要变」这两个字。我的态度很简单：先等它把数字和范围写清楚，再决定要不要提前改调用方式。
来源：
你手头系统的 RPO 定的是多久——30 秒以内，还是干脆 24 小时赌一把？明早 8 点见。
本期从过去 24h 的 X / Hacker News / GitHub Trending 共 65 条信息中挑出 8 条（全天逐小时采写、经事实校对后于晨间选编）。内容由 LLM 辅助生成，每条均附原始来源链接，重要决策请交叉验证。
微信扫码关注「码农早餐」
每天早 8 点推送到微信，不用记网址。关注后回复「价格」，拿大模型价格与退役时间速查表。
喜欢这篇？订阅每日推送
每天 8:00 帮你挑好 AI 圈最重要的 5-10 条，说人话、看得懂、不浪费时间。
本页内容由 LLM 自动聚合 + 解读生成，每条均有原始来源链接，建议交叉验证。