上个月一个凌晨两点把我叫醒的，不是告警短信，是一个朋友打来的电话：他们公司一台 Windows 文件服务器的共享目录里，所有文件后面都多了一个随机后缀，双击打不开，右键属性里文件大小没变但打不开提示“格式无效”。更让人头皮发麻的是，他紧接着说了第二句“备份也在同一台服务器上，昨天刚跑完的备份任务”。
我第一反应是让他断网、别重启，然后开始问三个问题：备份是增量还是全量？备份目标目录在不在同一块盘上？备份用的账号是不是和被加密的服务账号共享同一组权限？三个问题里他只答上来一个备份任务是全量的，每天凌晨两点跑，跑完自动删掉一周前的旧档。也就是说，被加密的不是数据本身，是那份“保险”，而且这份保险和被保护的东西躺在同一个抽屉里。
如果你现在正在给公司做备份方案，或者正在琢磨勒索软件到底能造成多大损失，这两家的服务器可以先拿来做隔离的备份机或者干净的恢复环境：yxvm（服务器与主机，可单独开一台只跑备份任务的机器）、qde（服务器与主机，适合放在另一台物理机上做异地副本）。备份这件事的核心不是“备了”，而是“备的地方跟被保护的东西没有关联”，下面我把这次处置的完整过程和后来总结的规范写下来。
勒索软件的变现逻辑是“先拿到数据，再让你付钱”，所以它干的第一件事不是加密，而是破坏你的恢复路径。常见的动作就三类：
删卷影副本：Windows 上执行 vssadmin delete shadows /all /quiet，把系统还原点和卷影副本清空。没有卷影副本，很多勒索载荷连“加密前先备份原文件”的那一步都省了。
终止备份与杀软进程：把 backup、veeam、sqlservr、sqlagent、vss、任何安全软件进程直接结束，保证接下来写文件的时候没人拦着。
横向移动找备份：拿到域权限之后扫内网，优先找 NAS、SAN、备份一体机、挂在共享上的目录，甚至会去翻配置文件里写着的备份服务器地址和账号。
所以「备份在不在同一台机器上」这个问题，在勒索软件眼里几乎不重要只要能登录、能执行命令，它就一定能顺着你的权限摸到那份备份。真正决定你能不能活下来的，是这份备份能不能被改。
3-2-1 备份法则大家都听过：3 份数据副本、2 种不同介质、1 份异地存放。但真正救命的往往不是这个法则本身，而是它的隐藏前提那 1 份异地副本，必须是勒索软件改不动的。
我朋友那台机器的情况是：3 份有（全量快照 + 一份手工拷贝 + 一份 NAS 上的旧档），2 种介质有（本地磁盘 + NAS），1 份异地……严格说也算有，挂在一台异地 NAS 上。但那份 NAS 用的是跟文件服务器相同的域账号、同一个密码，而且 NAS 的管理密码是三个月前用手机备忘录记下来、跟路由器后台密码一样的那个。勒索软件一拿到域控权限，横向扫到 NAS，直接把里面的历史备份全部加密了它甚至不需要破解 NAS 的管理密码，因为域账号就有写权限。
所以正确的姿势是这样的：
副本一：生产环境的本机快照或本机备份，用来做分钟级回滚，允许被改，但必须有保留策略（保留 7~30 天），且备份账号只有写权限、没有删除权限，删除动作交给策略而不是交给账号。
副本二：独立存储的备份，可以是另一台机器上的存储、NAS 或者对象存储。这里最关键的一条是：存储端开启不可变保留（Object Lock / WORM / 快照锁），在保留期内无论用什么账号都不能删除或覆盖。对象存储的话就是给桶开 compliance 模式并配 retention；文件系统的快照要看有没有 immutable 或者保留锁。
副本三：异地副本，放在不同机房、不同账号体系、甚至不同云。异地不只是防机房故障，更是防域账号被攻破攻击者拿到主环境的全部凭据，也动不到另一套账号体系里的东西。
“只读”这三个字落到不同环境里有不同的实现方式，我按实际用过的顺序说：
方式一：对象存储的对象锁（Object Lock）。这是最省事的一种。开桶时选 compliance 模式，设一个保留期（比如 30 天），在这个周期里连桶所有者都删不掉对象，必须是 compliance 模式才行，governance 模式管理员还能绕过。适合把数据库备份、配置备份直接丢进去。注意保留期一旦设置就不能缩短，而且删除会产生一笔费用账单，这是它的代价。
方式二：文件系统/阵列的快照保留锁。多数企业阵列和 ZFS、Btrfs 都能做只读快照，区别在于能不能防止管理员删。ZFS 上可以给数据集加 immutable 属性并设置 immutable=on，到期前谁都改不了包括 root。这个方案成本最低，但要注意它保护的是“快照”，不是“备份任务”勒索软件如果能删掉快照任务本身，快照照样没了，所以还得配上权限。
方式三：独立账号 + 独立终端 + 只写不删。这条最土但最有效：备份用的那个账号在文件服务器上只授予写入备份目录的权限，不授予删除权限，也不加入任何管理员组；备份任务跑完之后，由另一条路径（不是被加密机器上的脚本）去做旧档清理。用一台独立的机器、一套独立的凭据去管理备份，比在原机上装个 agent 就叫“备份”强得多。
方式四：物理隔离的离线副本。把磁带或者移动硬盘在备份完成后直接取下来 unplug。这是最早的做法，现在没人愿意天天干，但在勒索攻击频繁的当下，一份不插电的离线介质是永远改不动的，代价是恢复慢一点。
这次我们从接到电话到把服务恢复，前后花了不到六小时，其中真正花在“恢复”上的时间大概只有一个半小时。剩下的时间全花在前期判断上。下面这套顺序是我这次总结下来的：
第一步：断网，不是关机。直接拔网线或者在交换机上把该网段隔离，关机反而可能让加密进程把内存里的密钥丢掉，日志也断了。断网能防止它继续横向移动到 NAS、备份机、域控。这一步做晚了，后面所有努力都会打折。
第二步：判断哪份备份是干净的。关键不是“有没有备份”，而是“哪一份没被碰过”。看三样东西：备份任务最后一次成功的时间戳（要早于攻击开始）、备份文件的完整性校验值、备份账号的登录日志。备份账号在被攻击时间窗内有登录记录的，直接判定为脏，别抱侥幸心理。
第三步：把恢复环境隔离出来。不要在原机上恢复。新起一台干净的机器（这也是我上面推荐先看服务器的原因之一），先把干净备份拉回来做校验，确认能解开、能校验和一致，再往生产导。恢复环境一定要接在一个独立网段里，不然刚恢复好的数据又会被二次加密。
第四步：先救数据，后修系统。勒索病毒经常在系统里留了后门，你把文件恢复回去、系统还是被控制着，等于把病毒请回家里。恢复顺序应该是：干净镜像重装系统 → 打补丁 → 关闭被利用的入口（弱口令、被爆破的远程端口、暴露到公网的管理面板）→ 恢复数据 → 再把业务切回来。
第五步：轮换所有凭据。这一步最容易被忽略，但不做的话你三个月后还会再被勒索一次。域控管理员密码、服务账号密码、备份账号密码、API 密钥、数据库口令、SaaS 平台的 access token，全部换掉，不是只换被用到的那个。
这次之后我给身边朋友的公司做了一次备份体检，发现下面几条几乎是人人都中招的：
一、备份和被保护的数据在同一个共享里。数据库的备份文件放在数据库所在的同一个目录、同一个共享、甚至同一个网盘同步目录里。勒索软件扫到共享就会顺手一起加密。备份目录必须和业务目录分开，而且最好连权限体系都分开。
二、备份账号权限给太大。为了图省事，备份账号直接给了域管理员。这是我见过最普遍的问题它同时解决了勒索软件的“删备份”和“横向移动”两个需求。
三、从来没验证过能不能恢复。“备份任务每天显示成功”不等于“能恢复”。我建议至少每季度做一次随机抽一份备份，在干净环境里跑一次完整恢复并记录耗时。恢复演练不测，等于没有备份。这一条其实我们之前专门写过一篇灾备演练翻车的心得，感兴趣可以翻翻站内那篇。
四、只做增量不留全量。增量备份的链一旦某环被污染，恢复就会失败。全量 + 增量的组合策略要保证每个增量链都有一个独立的、不可被修改的锚点全量。
五、把勒索当成必然会来的事。我现在的判断是：只要你的系统暴露在公网上、有远程登录服务、且没有不可变备份，那被勒索只是时间问题，不是会不会的问题。所以这套东西不应该是“出事了再上”，而是跟 HTTPS、跟监控、跟日志留存一样，属于服务器的日常配置。
最后说一句可能不太中听的：备份不是为了让你从容付款，而是为了让你有底气直接说不。当你手上有一份改不动的干净副本时，勒索软件给你的就不是选择题了。
