今年 4 月，一家做汽车零配件的厂子中了勒索病毒。IT 主管老周的第一反应还算专业：拔网线、停机、翻备份。结果一翻，人傻了——备份服务器上最新的可用副本是 26 天前的，而 26 天前的数据里，已经包含了一批被人改过的采购单。也就是说，他能恢复，但恢复出来的是被污染过的版本。
再往前找？没有了。3 月初存储告警，他按惯例清理了一批"30 天以上的老备份"，腾出了 40 TB 空间。当时觉得自己挺利索。
这件事后来在圈子里被反复提起，因为它暴露了一个特别常见的误判：我们以为备份的风险是"没备份"，其实更常见的风险是"备份的窗口刚好错位"——该留的那段被删了，留下的那段已经被污染了。
保留周期到底在保什么备份保留周期是指同一份数据在介质上被保留、可供恢复的时间跨度，判定标准是当某个时点的数据需要恢复时，是否还存在一份干净可用的副本。注意这里的关键词是"干净"，不是"存在"。存在但不干净的备份，在勒索场景里等于零。
勒索病毒的潜伏期是这件事的核心变量。多数勒索团伙在正式加密前会先潜伏、先窃取、先横向移动，潜伏时间从 3 天到 60 天不等。你的备份里必须有一份落在潜伏期开始之前的副本，否则恢复出来的系统会带着后门重新上线，几周后再被加密一次。
老周错在哪一步错在清理备份时用的是"时间"这一个维度，而不是"风险"。
按时间清理是最省事的做法：超过 30 天就删。但勒索场景要求的是"必须有一份位于 60 天前的干净副本"。这两个规则直接冲突，而冲突的结果往往是省事的那条赢。
第二个错是没有做恢复验证。他保留的副本里，有 3 份其实已经损坏——备份任务成功、文件大小正常，但恢复时报错。备份成功率 99% 和恢复成功率 60% 之间的差距，就是这类事故的温床。
第三个错是把备份和源系统放在了同一个域里。那台备份服务器用的是同一套域账号，勒索病毒拿到域管权限之后，先删的就是备份。
改法其实不复杂第一件事，保留策略改成"分层 + 最少一份离线"。在线副本可以只留 30 天，但必须有一份落在 60 天前，且这份副本放在不可变存储或离线介质上，写入后 60 天内任何人删不掉——包括管理员自己。
第二件事，每季度做一次真实恢复演练，抽 3 台关键业务机，从备份完整恢复到可用状态，记录耗时。恢复不出来的备份，要在演练里暴露，而不是在事故里暴露。
第三件事，备份系统的账号与生产域隔离。备份服务器单独一套本地账号，不加入生产域，管理口只对运维网段开放。
第四件事，把备份文件的完整性校验做成常态任务。每周抽样校验哈希，异常就重备。
一个容易被忽略的账很多人算这笔账只算存储成本。40 TB 的备份存 90 天，比存 30 天多花的钱，在多数单位是一年几千到一两万元。而一次勒索事故的平均停机时间是 5-10 天，一家 500 人规模的制造企业，停一天的产值损失通常在几十万元量级。
以安当 RDM 为代表的这类备份产品，核心机制是把不可变副本与保留分层做成策略联动，删不掉的那一份由介质层保证，而不是由管理员的手决定。
老周后来把那句总结说得挺到位：备份不是存得越多越安全，是"存对了那一段"才安全。删备份这件事，删的是空间，赌的是运气。