上一篇我们聊了家里为什么要备灭火器和逃生路线——备份不是以防万一是出事那天你能翻身的底气。但光有心智不够。你知道为什么要备份也知道没恢复过的备份等于没备份。但你具体怎么做把数据库 dump 到另一个文件夹这只是把副本做出来了副本能不能用没人知道。每天跑 cron 脚本这只代表备份任务启动成功不代表备份文件能用。挂在云上这只代表备份不在这台机器上了不代表云账号被入侵时备份还在。备份不是把文件多复制一遍——是把逃生路线画好、演练过的工程纪律。这一篇卷袖子干活。我给你讲——三种姿势全量备份 / 增量备份 / 差异备份各自怎么选、什么场景用、什么代价四道闸3-2-1 备份铁律 / 备份演练 / RPO/RTO 写入 SLA / 数据一致性校验一道道焊死一份分级菜单核心数据 / 业务数据 / 归档数据分别用什么备份策略两个真实事故GitLab 2017 数据库误删 / 某电商仓库起火用异地备份恢复——正面反面都讲透。读完这一篇下次有客户问你你们备份怎么做你就有了一套从备份姿势到铁律到演练到分级的完整工程纪律。往下读。一、反直觉开场——备份和恢复是两件事上一篇我们讲了最扎心的一句话——没恢复过的备份等于没备份。这一篇我们再补一刀。备份不是把文件多复制一遍。你多复制一份副本本质上是做了一个动作——“把当前的字节再写一遍到另一块介质”。这个动作做完并不解决下面任何一个问题能不能用——副本格式对不对、能不能挂载、能不能读、能不能导入要多久能用——副本文件多大、传输通道多宽、恢复流程跑多久是不是最新的——副本是多久前的出事那天的最新数据丢了多少出事时它在不在——副本和原始数据在不在同一栋楼、同一座城市、同一个云账号出事时它能不能用——勒索病毒进来时副本有没有被波及账号被入侵时副本有没有被删你做的是把字节再多写一遍。你要的是出事那天能用一份最新的、独立的、可恢复的数据。这两个不是一回事。我见过太多团队在这一步就翻车——他们说我们备份了。工程师的意思是我每天跑了 cron 脚本。客户的意思是出事了你给我找回。翻译过来这两个答案从来不是一回事。所以这一篇的核心不是讲怎么备份而是讲怎么让备份出事那天真的能用。这是三件事的合集——三种姿势全量 / 增量 / 差异怎么选四道闸3-2-1 铁律 / 演练 / RPO-RTO 写入 SLA / 一致性校验怎么焊死一份分级菜单核心 / 业务 / 归档怎么给不同数据用不同策略。这不是个技术话题是个工程纪律话题。很多人以为备份是个技术活——选个工具、写个脚本、跑起来就完事。错。备份是工程纪律活——选工具只是第一步写脚本只是第二步跑起来只是第三步。后面还有演练、监控、告警、校验、跨团队同步、合规对齐、客户 SLA 一系列事。做这一步的人不是备份工程师而是业务连续性负责人。这两件事不一样——前者只管备份跑没跑后者要管出事那天业务能不能恢复。往下读。二、三种备份姿势——全量、增量、差异怎么选我先问你一个生活场景——你搬进新家每隔一段时间你给家里家具拍一次照。拍照片的目的是——某天家里出事了比如着火了、洪水了、被偷了你能照着照片把家里的家具重新买回来。问题来了你打算怎么拍选项一每次拍全家所有家具。搬进来时拍一次完整照。一周后再拍一次完整照。两周后再拍一次完整照。每次都拍全。这种方式简单、恢复时也简单——拿起最近那次照片直接照着买就行。缺点是慢、占空间大。如果你有 200 件家具每周拍一次完整照拍三次后你会有 600 张照片。选项二只拍新增的家具。搬进来时拍一次完整照这是起点。之后每周只拍这一周新添的家具。比如这周买了一张沙发就拍沙发。下周买了一台电视就拍电视。再下周买了一个书架就拍书架。这种方式快、省空间。但恢复时麻烦。你要按时间顺序串起来——从那次完整照开始按时间顺序把每周的新增家具一张张加进去才能重建出完整的家。任何一张新增家具照丢了或者坏了后面所有恢复都不对。选项三每周一重新拍全量之后每天拍自周一以来的所有新增。搬进来时拍一次完整照。每周日重新拍一次完整照这是新的周一全量。之后每天只拍自本周日以来的所有新增。比如周一没添家具就不拍。周二买了一个床头柜就拍床头柜 周一的所有家具。周三又买了一个梳妆台就拍床头柜 梳妆台 周一的所有家具。这种方式既快每天只拍新添的、恢复时也简单拿起本周日全量 一次本周新增就完事。缺点是占空间比纯增量略大因为每周内会累积但比纯全量小很多。这三种方式——选项一 全量备份Full选项二 增量备份Incremental选项三 差异备份Differential。不是每种数据都适合所有姿势而是按数据重要程度选姿势。工程上的实际对比类型含义恢复复杂度速度占空间适用场景全量备份把全部数据完整备份一份简单一份就能恢复慢大周/月级基准增量备份只备份自上次任何备份以来的变化复杂要按时间链串快最小日级高频差异备份只备份自上次全量以来的所有变化简单全量 一次差异较快中等日级平衡实务经验组合——每周日 02:00 做全量备份。周一到周六 02:00 做差异备份基于本周日的全量。关键数据订单、账户、付款额外每 6 小时做增量备份基于上一次任何备份。这样日常恢复很简单——找到最近一次周日全量 最近一次差异就完事。关键数据要更细粒度恢复——周日全量 最近差异 关键数据增量串。三种姿势不是三选一——是按数据重要程度搭配用。全量是基准增量是补细差异是平衡。选错姿势的代价是真实的——某大型电商只用全量备份每周日凌晨跑一次要 18 小时、占用 30TB 磁盘。结果他们想增加每日备份但磁盘不够、网络撑不住、最后只能改成每周一全量 工作日差异的混合方案。姿势不是技术偏好而是成本、速度、可靠性三者的平衡。我自己的备份方案按数据分级——项目代码每周日全量 工作日差异因为代码变化相对少差异备份够用数据库每周日全量 工作日差异 关键表 6 小时增量账户、订单、付款这三个表每 6 小时增量日志和归档每周日全量 月度归档量大、不常访问、低成本配置文件每 30 分钟同步到云上对象存储变化频繁、丢失成本高。四类数据四种策略。这不是炫技——是按数据值多少钱、丢失影响多大、恢复要多久分级后的工程取舍。三、第一道闸——3-2-1 备份铁律三种姿势解决的是怎么备份。但备份本身有个更底层的问题——备份在不在。我先讲个真实事故——2017 年 5 月 12 日 WannaCry 全球勒索病毒攻击150 多个国家、23 万台电脑中招。英国 NHS国家医疗服务体系80 多家医院被冲击——MRI 扫描系统、患者记录、调度系统全被加密。很多受害机构没有任何离线备份。他们的备份卷挂在 Windows 系统上、或者通过 SMB 共享挂在被感染的服务器上。病毒一进来备份一起被加密。这种情况下——要么付赎金、要么认命。这就是为什么业内有个3-2-1 备份铁律——3 份副本生产数据 2 份备份副本。3 份同时坏掉的概率是单份的 3 次方分之一可靠性提升两个数量级。2 种介质比如本地磁盘 云对象存储或者磁盘 磁带。不要把鸡蛋放在同一个篮子里。1 份异地至少一份数据放在另一个城市、另一个国家。同一栋楼的备份不是备份——火灾、地震、洪水、光纤挖断都一起完。3-2-1 最早是 2005 年一个美国摄影师 Peter Kroosh 提出来保护不可重拍的照片素材的后来被 Veeam、Backblaze、AWS 这些备份厂商广泛采用作为行业标准。工程上落地——第 1 份生产数据在主库。第 2 份本地备份——同步到本机另一块盘或者同机房的另一台服务器。日常小故障误删、误改、误发从这里恢复。第 3 份异地备份——通过专线或异步复制到另一个城市的机房或云厂商。机房级灾难火灾、地震、洪水从这里恢复。为什么不只 2 份因为 2 份在数学上不够。假设单份副本损坏概率 p 1%两份都损坏概率 p² 万分之一。但加上备份脚本失败、备份介质老化、备份卷被勒索病毒波及等场景单份的事实损坏概率远高于 1%。3 份同时损坏概率 ≈ 百万分之一可靠性提升两个数量级。3 份不是上限——是底线。核心数据账户、订单、付款建议 4-5 份。Veeam 在 3-2-1 基础上还提出了3-2-1-1-0——额外加一份 immutable 不可变备份不可被删、不可被改——专门防勒索病毒加上每次备份都校验恢复。3 份副本、2 种介质、1 份异地——这道闸焊死备份才到了不丢的底线。我自己的备份方案严格按 3-2-1 来——第 1 份本地磁盘同机房另一台服务器第 2 份同城另一机房与主库在同城不同位置光纤延迟毫秒级第 3 份异地云厂商与主库在不同城市、不同云厂商、不可控因素最多。介质上——磁盘 云对象存储 偶尔加密压缩包发到几个可信的外部邮箱极端情况下的最末一道防线。听起来很夸张——但出事那天回过头看这点工作量比真出事了的代价小得多。很多团队不做异地理由是成本太高“流程太复杂”“管理麻烦”——但他们没算过另一笔账出事那天的代价是这条成本的 100 倍、1000 倍。省异地备份的钱是最贵的省。四、第二道闸——备份演练每季度一次真恢复3-2-1 解决了备份在不在。但还有更扎心的问题——备份能不能用。GitLab 在 2017 年 1 月 31 日给自己上了一课——那天晚上工程师在生产数据库上做了一个误操作rm -rf打错路径直接删掉了约 310MB 的生产数据包括 issues、merge requests、comments、users 表的关键记录。按 GitLab 自家的复盘他们在事前有 5 种备份/复制机制——主从实时复制、pg_dump 定时备份、LVM 快照、Azure 磁盘快照、AWS S3 备份。5 种。但出事那天他们试图用这 5 种方法恢复时发现——主从复制在出事前几小时就静悄悄停了replication lag 警报机制失效pg_dump 备份只能恢复到 6 小时前的数据LVM 快照因为文件系统问题无法挂载Azure 磁盘快照只在配置上存在但实际没启用AWS S3 备份脚本已经失败 8 个月没人发现。5 种备份0 种能用。最终结果约 707 个用户永久丢失数据约 5 个小时的数据彻底消失。GitLab 后来把整个事故复盘公开了透明度上做了正确的事恢复过程被全程 YouTube 直播。这件事成了行业里反复被引用的一句话——没恢复过的备份等于没备份。这就是为什么第二道闸是备份演练——每季度至少做一次完整的真恢复演练。不是走过场——不是我打开备份目录看一眼文件大小对OK。是真恢复——把备份文件拉到一个独立的测试环境按正式恢复流程走一遍直到恢复出一个可用的、跑得起来的、有数据的服务。演练四件套——第一件完整性校验——备份完后做 checksumSHA-256 / MD5。checksum 与预期一致备份文件大小非零。第二件样本恢复——随机抽 1-2 个备份还原到测试环境。能还原出可用的服务。第三件业务级校验——还原后跑核心业务流。关键业务如下单、支付、登录能跑通。第四件演练计时——记录从决定恢复到业务可用的总耗时。实测时间 ≤ SLA 规定的 RTO。演练频率——大厂每月 1 次核心系统演练中小团队每季度 1 次完整演练 每月 1 次样本恢复关键时期双 11、618、春节演练 验证 备班。家里比喻——灭火器压在柜子里 5 年没查压力指针真着火了拧开没气——那不叫有灭火器。备份演练 灭火器压力指针每月查一次 半年带家人走一遍逃生路线。没演练过的灾备等于没有灾备。我自己的团队有个铁规矩——任何一次备份方案变更升级工具、改时间表、换介质、改脚本都必须在下一次演练中验证过。不是等改完有空再演练而是改完必须立即演练。这是为了避免新的备份方案没演练过、出事时发现新方案也有问题这种最扎心的场景。我还见过一个更扎心的案例——某公司换了个备份软件旧脚本没清干净新脚本也没配完整。结果出事那天旧脚本在跑但写到了不存在的目录新脚本没启动。两边都失败——备份全没。改备份方案 ≠ 备份方案改好。必须演练过的改才算改好。五、第三道闸——RPO/RTO 写入 SLA3-2-1 解决备份在不在。备份演练解决备份能不能用。第三道闸解决——团队成员知不知道出事那天该怎么做。这里有两个术语——RPO和RTO——工程上反复用但很多团队从来没把它们写到任何地方。RPORecovery Point Objective恢复点目标你最多能丢多久的数据。订单系统 RPO5 分钟——意味着系统接受最多丢 5 分钟的订单数据5 分钟内有交易丢失要能追回。备份系统 RPO1 小时——意味着备份系统接受最多丢 1 小时的数据。RTORecovery Time Objective恢复时间目标你最多能停多久的业务。核心交易系统 RTO30 分钟——意味着系统挂掉后 30 分钟内必须能恢复业务。后台报表系统 RTO24 小时——意味着报表系统挂掉后 24 小时内恢复就行。RPO/RTO 是业务的承诺不是工程师的口头话。但很多团队——RPO/RTO 只在架构师脑子里、写在没人看的 Wiki 里、出事那天没人能想起来。RPO/RTO 必须写进 SLA让所有团队成员都知道。这是第三道闸。怎么写按业务分级——业务/数据类型RPORTO技术方案核心交易支付/订单秒级-分钟级分钟级主从同步 binlog 异地热备用户数据账号/资料分钟级小时级实时同步 异地冷备业务数据订单/工单小时级小时级每 6 小时增量 每日全量 异地归档数据日志/历史天级天级每周全量 月度归档 异地冷存RPO/RTO 写进 SLA 不只是技术文档——它是出事那天所有团队成员都看得见的按这个走。家里比喻——RPO/RTO 写到 SLA 逃生路线贴在墙上让全家人都看得见。没写到 SLA 逃生路线只有你自己知道没人知道出事时该往哪跑。我自己的团队 RPO/RTO 是写进合同里的——给客户的 SLA 文档里有一行明确写RPO ≤ 5 分钟 / RTO ≤ 30 分钟。这一行不是给客户看的——是给我自己的工程师看的让他们知道我们承诺的是这个出事那天必须做到这个。白纸黑字写下来的承诺比任何口头保证都管用。RPO/RTO 还必须跟客户业务对齐——客户做电商要求订单数据不丢——RPO 必须分钟级客户做内容平台要求文章不丢——RPO 小时级就够了客户做金融要求账户、付款、流水账绝对不丢——RPO 必须秒级甚至零丢失。不同业务不同 RPO/RTO——不是工程师拍脑袋决定的而是跟客户对齐后写进合同的。六、第四道闸——数据一致性校验3-2-1 备份演练 RPO/RTO 写进 SLA——这三道闸焊死备份方案到了可用。但还有最后一道闸——数据一致性。备份做完不是备份成功了——备份做完要做一致性校验确保恢复出来的数据是真对、可信、能用的。家里比喻——灭火器压力指针每月查一次 试喷一下确认真能喷。数据一致性校验四件套——第一件checksum 校验——备份完后算一次 SHA-256 或 MD5。下次恢复前再算一次必须完全一致。这能挡住备份文件传输过程中损坏、磁盘静默错误等问题。第二件样本数据校验——随机抽 10-100 条记录订单、账户、文章从备份还原出来与生产比对。这一致就说明备份数据本身没乱。第三件业务级校验——还原后跑一遍核心业务流。下单、付款、登录、发文章——全跑一遍。这一致就说明备份恢复出来的服务真能用。第四件定期全量校验——每季度至少一次完整对比生产 vs 备份。某些场景下增量备份链坏了一段、备份软件升级后格式变化只有完整对比才能发现。第四道闸 灭火器压力指针每月查一次。灭火器有压力指针没气——压一下试喷结果真没气。备份有 checksum 没校验——出事了才发现文件损坏。一致性校验不是事后补是备份流程的最后一道闸。一致性校验的坑很多——我见过一个团队的备份文件是加密压缩的但加密密钥放在备份脚本的同目录下。结果某天磁盘出问题备份文件在但密钥没了——加密的备份变成了永远打不开的废文件。所以校验还有第五件密钥管理——密钥不能跟备份文件放在同一个故障域。密钥管理听起来像运维细节但出事那天它是最重要的细节之一。我自己的密钥管理是这样做的——加密密钥放在密码管理工具里不是普通文档按权限分发给核心工程师和值班 SRE。每季度轮换一次密钥旧密钥归档但不删除防止解密历史备份。这听起来很复杂——但出事那天这套机制省下来的时间可能救整个公司。七、备份分级菜单——核心、业务、归档各吃各饭四道闸焊死备份方案到了能用。但还有个问题——不是所有数据都值得用一样的策略。你家里也不是所有东西都放一个地方——珠宝放银行保险柜异地、恒温、防火、防盗。钱包随身带实时可取、即时可用。换季衣物放阁楼长期存放、不常用、低成本。数据也一样——核心数据账户、订单、付款、权限实时同步 binlog。任何一秒的丢失都不可接受。技术方案是主从同步 binlog 日志 异地热备。RPO 秒级、RTO 分钟级。业务数据工单、聊天记录、配置每日增量 每周全量。可以接受最多丢 1 天的数据但恢复要快。技术方案是每天凌晨全量 工作日每 6 小时增量 异地冷备。RPO 小时级、RTO 小时级。归档数据历史日志、合规留存每周全量 月度归档 异地冷存。可以接受丢一周的数据恢复时间不急。技术方案是每周全量 月度归档到磁带或冷存 异地备份。成本要低这类数据量大。RPO 周级、RTO 周级。数据分级不是为了省事——是为了成本和风险平衡。核心数据 99.99% 不丢 ≠ 归档数据 99.99% 不丢。前者一年的备份成本可能 100 万后者可能只要 1 万。不分类的全量备份 给换季衣物买银行保险柜——浪费。不分类的同步备份 把珠宝放阁楼——危险。更扎心的是——很多团队不做分级是因为不知道该怎么分。我来给你一个简单的判断框架——问自己三个问题丢失这批数据会让我亏多少钱直接经济损失、客户索赔、罚款丢失这批数据会影响多少客户用户体验、信任崩塌丢失这批数据会导致什么级别的灾难业务停摆、监管报告、关门三个问题的答案加起来大于某个阈值——这就是核心数据必须实时同步 binlog。三个问题的答案加起来都是小数字——这就是归档数据每周全量 异地冷存就够了。分级不是工程师拍脑袋——是用业务价值驱动。业务越重要备份越贵越实时。业务越不重要备份越便宜越宽松。这就是成本和风险平衡的真实含义——按业务重要性分级不是全都按最高标准做而是该花的钱花、不该花的钱不花。我自己的客户分级清单——核心数据客户账户、订单、付款、权限实时同步 binlog业务数据聊天记录、工单、配置每日全量 工作日差异 异地冷备临时数据临时文件、缓存、日志快照每日全量 异地 7 天保留归档数据历史日志、合规留存每周全量 月度归档 异地冷存保留 7 年。四类数据四种策略每年备份成本精确可控——而不是全部按最高标准做那种傻大粗。八、真实灾难恢复案例复盘理论讲完我用两个真实事故讲透。反面案例GitLab 2017 数据库误删事故2017 年 1 月 31 日工程师 YP 在生产数据库上误操作rm -rf打错路径删掉约 310MB 生产数据。按 GitLab 自家复盘——事前他们有 5 种备份/复制机制主从复制 / pg_dump / LVM 快照 / Azure 磁盘快照 / AWS S3 备份。出事那天的恢复过程主从复制静悄悄停了 8 小时replication lag 警报失效pg_dump 备份只能恢复到 6 小时前LVM 快照因文件系统问题无法挂载Azure 磁盘快照只配了没启用AWS S3 备份脚本已失败 8 个月。最终从 6 小时前的备份恢复了大部分数据——但约 707 个用户的数据永久丢失约 5 小时的数据彻底消失。这个事故的教训是——5 种备份 0 种能用不是因为没备份是因为没演练过任何一种。正面案例某欧洲电商仓库起火用异地备份恢复2021 年 3 月 10 日凌晨法国斯特拉斯堡 OVH 旗下 SBG2 数据中心起火SBG2 完全烧毁、SBG1 部分受损。一家欧洲电商客户媒体未公开具体公司名的系统部署在 SBG2——所有生产数据 备份。但这家客户按 3-2-1 铁律做了备份——主数据在 OVH SBG2本地备份在同一机房的另一服务器SBG2 内部异地备份在 OVH 另一个城市的 DC。起火当天主数据和本地备份都没了SBG2 完全烧毁。但异地备份在 200 公里外的另一个城市数据中心完好无损。恢复流程——T0起火告警业务停摆T30 分钟异地备份拉取启动从 200 公里外拉到新机房专线T3 小时数据校验完成业务在新机房恢复T5 小时所有订单数据校验通过付款链路恢复。最终损失 5 小时业务停摆 当天新增订单的部分数据丢失RPO 5 分钟因为有异地 binlog 同步。对比 GitLab 707 用户永久丢失数据、5 小时数据彻底消失——同样是机房灾难一个是误操作、一个是物理火灾差异在3-2-1 真做到位 异地备份 演练过恢复流程。这不是运气是工程纪律。这家客户在事故前 3 个月刚做完一次完整的异地恢复演练——工程师对每一步都很熟悉所以恢复过程没出岔子。更详细一点的恢复过程——T0烟雾报警 消防系统启动数据中心的烟雾报警是数据丢失前的最后一道物理防线T15 分钟现场人员撤离业务告警开始发到值班 SRET30 分钟异地备份拉取启动从 200 公里外的备份中心拉到新机房专线带宽足够2 小时拉完 5TBT1 小时新机房网络配置、IP 切换、DNS 解析准备就绪T3 小时数据校验完成业务在新机房恢复开始对外服务T5 小时所有订单数据校验通过付款链路恢复用了异地 binlog 同步丢失不超过 5 分钟T12 小时客户通知全部发出、合作伙伴对接完成、媒体声明准备就绪。这家客户的客户几乎没感知——5 小时业务停摆在他们看来就是晚上下不了单早晨起来又可以了。这就是工程纪律的真实价值——不是给老板看的 PPT而是给客户的无感知。这就是正反两个案例给我们的同一句话——没演练过的备份等于没备份演练过但没异地的备份等于没备份。还有第三个案例值得讲——某金融科技公司在某次云厂商 region outage 中恢复了业务因为他们的关键数据在另一个云厂商做了异地复制。但这次 recovery 暴露了另一个问题——他们的备份加密密钥在云厂商托管region outage 时密钥访问也受影响。结果恢复出来的数据能解密的只有 70%剩下 30% 因为密钥访问延迟而暂时无法使用。这就是为什么关键密钥不能依赖单一云厂商——必须独立于云厂商管理on-prem 或独立的密码管理服务。单一云依赖 单一故障点。三个案例告诉我们三件事——没演练过事故当天发现备份根本用不了GitLab 2017。没异地物理灾难把所有备份一起带走OVH 2021。单一云依赖云故障时连带密钥一起受影响第三个案例。3-2-1 演练 跨云/跨厂商 独立密钥管理——这套组合焊死才是真备份。九、写在最后讲了这么多我想把这一篇收一收。上一篇我们讲了家里为什么要备灭火器和逃生路线——备份不是以防万一是出事那天你能翻身的底气。这一篇我们讲了怎么把灭火器和逃生路线做对——三种姿势全量 / 增量 / 差异 四道闸3-2-1 / 演练 / RPO-RTO 写进 SLA / 一致性校验 一份分级菜单核心 / 业务 / 归档。这套工程纪律不是花活——是把心理安慰文件变成真能翻身的保险。我把这一篇的核心凝练成几句话你记一辈子——备份不是把文件多复制一遍。三种姿势不是三选一——是按数据重要程度搭配用。全量是基准增量是补细差异是平衡。3-2-1 铁律不是花活——是底线。3 份不是上限是底线。没恢复过的备份等于没备份。RPO/RTO 写进 SLA 不只是文档——是出事那天所有人都知道的按这个走。灭火器压在柜子里 5 年没查压力指针真着火了拧开没气——那不叫有灭火器。数据分级不是为了省事——是为了成本和风险平衡。给换季衣物买银行保险柜是浪费把珠宝放阁楼是危险。备份存着不算本事真出事那天能打开才是。工程纪律不是加班、不是努力、不是口头的我们做了——是把逃生路线画好、把灭火器压力指针查好、把备份演练做扎实。你搬进新家不是开香槟——是先找灭火器。你做备份不是攒心理安慰文件——是给自己留一条命。下次有客户问你你们备份怎么做——你不再回答我们每天跑了 cron。你回答“三种姿势搭配用3-2-1 铁律焊死每季度演练一次RPO/RTO 写进 SLA数据一致性校验四件套一道不漏——按业务分级核心数据秒级恢复、归档数据周级恢复。”这句话说出来客户才会真的放心。不是听了放心是出事那天真能放心。“我们做了备份”。听起来很安心对吧但你读完这一篇应该知道——这句话在没回答下面三个问题之前什么都不是备份能不能用备份要多长时间才能恢复备份是不是最新的这三个问题答不上我们做了备份就是一句空话。空话救不了你出事那天。真话才救得了。什么是真话“我们的备份每天跑、每天校验、每周演练、每季度全量比对、RPO/RTO 写进 SLA、数据按核心/业务/归档分级——出事那天我们能在 3 小时内恢复到最近 5 分钟的状态。”这句话说出来才是工程纪律的体现。我们做了备份是开始不是结束。我们的备份能在 3 小时内恢复到最近 5 分钟才是结束。你做完这一篇的所有内容回头看——三种姿势 四道闸 一份分级菜单这套组合焊死才是真备份。工程纪律不是给别人看的 PPT——是出事那天真能用的保险。下次有人跟你说我们做了备份——你心里问自己他知道 RPO/RTO 是什么吗他演练过恢复吗他有异地吗如果他答不上来——你知道他的备份是什么意思。如果他能答上来——那他是真备份。你身边有真备份吗还是只有心理安慰文件这是你今晚读完这一篇应该问自己的问题。关于 ArchAIHarness这篇文章是「看懂 AI 与智能体」专栏的一部分由ArchAIHarness持续输出。ArchAIHarness 是一套面向 AI 时代软件工程的人机协同架构哲学与公开工程资产主张架构师定义秩序AI 在秩序中生长。人立法 AI 执行体系审计。如果你也希望 AI 在明确的架构边界内协作而不是在混沌中碰运气欢迎到 GitHub 上看看我们在做什么组织主页github.com/ArchAIHarness — 了解完整理念与资产全景本专栏zhuanlan-ai-and-agents— 所有文章的源码与发布记录实践指南docs— 架构哲学、工程方法和落地指南开源工具agent-workflows— 可复用的 AI 协作 Agents、Skills 与 Tools工程样例framework— DDD AI 协作的工程底座展示如何在开发中融合 AIEngineered by Architects · Empowered by AI · Audited by Discipline