Veeam 备份到 Wasabi 突然 403：Compliance 和 Object Lock 不是同一个东西
Veeam 往 Wasabi 云存储 offload 备份，任务突然全线失败，报错长这样：
Failed to pre-process the job Error: REST API error: 'S3 error: Access Denied
Code: AccessDenied', error code: 403
Agent failed to process method {Cloud.CreateCheckpoint}.403 Access Denied 的第一反应是 access key 权限问题——但 key 没动过，bucket policy 也没改过。开 case 问 Wasabi 支持，答案出乎意料：
Veeam 不支持 Wasabi 的 Compliance 功能。 如果需要对象不可变性，请改用 Object Lock 的 bucket；如果不需要，把 bucket 的 Compliance 模式关掉即可。
根因：两个「不可变」，只有一个能用
一图分清两个”不可变”——选错左边那个，Veeam 就是一路 403
Wasabi 有两套互相独立的不可变机制，名字都很像「防删除」：
| 功能 | 层级 | Veeam 支持 |
|---|---|---|
| Compliance | Wasabi 自家的 bucket 级设置 | ❌ 不支持 |
| Object Lock | S3 标准的对象锁（AWS 兼容 API） | ✅ 支持 |
我们建 bucket 的时候看到「Compliance」这个词，想着备份就是要合规、要防篡改，顺手就勾上了——从 Veeam 的视角，它调用的 S3 API 被 Compliance 模式拦下，就是一个莫名其妙的 403。
修复
按支持给的两条路二选一：
- 需要不可变备份（我们的场景）：新建一个启用 Object Lock 的 bucket，把 Veeam 的 backup job 改指向新 bucket，在 Veeam 仓库设置里配 immutability 天数；
- 不需要不可变：把现有 bucket 的 Compliance 关掉，任务立即恢复。
我们选了路线 1，顺便做了一次完整的不可变备份灾难演练（另一篇细讲）。
教训
- 403 不一定是权限问题——对象存储的 403 可能来自 bucket 的任何一层策略（Compliance、Object Lock、bucket policy、IAM），逐层排查；
- 第三方软件对接对象存储时，「S3 兼容」四个字要打个问号：厂商自有功能（如 Wasabi Compliance）往往在兼容范围之外；
- 建 bucket 时看到不认识的选项别顺手勾——先查它和你的备份软件的兼容性文档。Wasabi 官方有一篇《Compliance vs Object Lock 的区别》，建 bucket 前读一遍能省一次 support case。