不可变备份不做恢复演练等于没做：Veeam + Wasabi Object Lock 灾难演习全记录
勒索软件时代，Object Lock 不可变备份是最后一道防线。但「配置完成」和「灾难时真能救命」之间隔着一次完整的演练——我们把最坏场景排了一遍：假设 Veeam 服务器本身被毁，从一个裸的云端 bucket 能不能把数据捞回来？
完整演练时间线——红色节点就是那个不演练就不会知道的坑
演练设计
- Wasabi 建测试 bucket（新加坡区），启用 Object Locking；
- Veeam 里添加为对象存储仓库，immutability 设 4 天；
- 手动备份一台域控到这个仓库；
- 验证不可变：尝试删除备份 → 被拒绝 ✅（锁真的在工作）；
- 模拟灾难：直接把仓库从 Veeam 里移除——模拟 VBR 服务器全毁、配置全丢。
恢复阶段（坑就在这里）
在“新”环境里把同一个 bucket 重新挂回 Veeam：
- 仓库连上，能看到里面有一个加密的备份文件；
- 输入备份加密密码解密——然后诡异的事情来了：解密完成后，备份反而找不到了；
- 一度以为演练失败、数据没了。冷静下来重新走了一遍 import backup，再重启 Veeam console——备份出现了；
- 之后一路顺畅：browse 恢复点 → 挂载备份镜像 → 恢复文件 → 和源机对比内容——一致，演练成功。
那个「解密后消失」的坑，官方文档里没有醒目提示：解密后的备份需要重新 import / 刷新 console 才会出现在界面里。真灾难发生时，如果第一次演练就是实战，这个环节足以让人心态崩掉——你以为最后的备份也没了，实际上它好好的，只是 UI 没刷新。
附赠实验：不可变到底有多「不可变」
演练完想删掉测试 bucket，结果上了一课：
- bucket 里有 immutable 对象时，bucket 删不掉；
- 对象本身删不掉（这正是设计目标）；
- 试图暂停 bucket 的 versioning——也不允许；
- 唯一的出路：等 4 天 immutability 到期，才能清理。
这就是 Object Lock 的真实含义：连你自己（管理员、root、老板）都删不掉。勒索软件拿到你的全套凭据也没用——但反过来，immutability 天数设太长 + 测试数据太大，存储费也会「不可变」地烧下去。测试用小数据、短周期。
教训
- 备份的验收标准是恢复，不是备份成功。没做过恢复演练的备份方案，可靠性是未知数；
- 演练要演到最坏场景：不是「从好好的 Veeam 里点 restore」，而是「Veeam 没了，从零把 bucket 挂回来」；
- 把演练里踩到的 UI 坑（解密后要重新 import）写进 DR runbook——灾难现场没有冷静排查的余裕，runbook 里一行字能救一次心态；
- Object Lock 的删不掉是双向的：防住了攻击者，也防住了你自己的后悔药。上生产前用测试 bucket 把「到期清理」的流程也走一遍。