产品公告：邮箱迁移后 zmpurgeoldmbox 可能删除外部存储 Blob

适用于：Zimbra Collaboration Suite 10.1.15, 10.1.16 具有外部对象存储（Scality、S3、 OpenIO) 

摘要 

• ZCS 10.1.15 中的回归会导致 zmpurgeoldmbox 在邮箱迁移后删除外部 Blob（Scality、S3、OpenIO），即使 zimbraMailboxMoveSkipBlobs=TRUE 也是如此。 
• 这会导致目标服务器上的电子邮件数据永久丢失且无法恢复。 
• 修复针对 10.1.17 补丁版本。 
• 在此之前，如果您使用外部或统一对象存储，请不要在邮箱迁移后运行 zmpurgeoldmbox。 

发生了什么 

在 ZCS 9.0 中，在 zmmboxmove 后运行 zmpurgeoldmbox 正确地仅清理了源服务器上的本地元数据（MySQL + Lucene 索引），而使外部 blob 保持不变。在 ZCS 10.1.15 中，代码更改无意中改变了识别外部/集中存储的逻辑。结果是： 

• zmpurgeoldmbox 现在即使没有 –forceDeleteBlobs 标志也会删除外部 Blob 
• 目标服务器的邮箱仍然引用这些已删除的 Blob 
• 受影响的用户会看到“丢失 Blob”错误并永久失去对其电子邮件的访问权限 

我是吗受到影响吗？ 

如果以下所有均属实，您就会受到影响： 

1. 您正在运行 ZCS 10.1.15 或 10.1.16 
2. 您使用外部对象存储（Scality、S3、OpenIO 或类似存储）作为主卷或辅助 (HSM) 卷 — 尤其是在启用统一存储的情况下 
3. 您使用 zmmboxmove 和 blob-skipping 属性 (zimbraMailboxMoveSkipBlobs=TRUE) 执行邮箱迁移或 zimbraMailboxMoveSkipHsmBlobs=TRUE) 
4. 迁移后在源服务器上运行 zmpurgeoldmbox 

如果您仅使用本地（内部）存储且不使用外部对象存储，则此问题不会影响您。 

行为比较：ZCS 9.0 与 10.1.15 

* 在 ZCS 9.0 中，未针对外部存储实现 –forceDeleteBlobs（错误 96149）。作为修复的一部分，它正在得到正确实施。 

立即解决方法 

• 如果您的环境使用外部对象存储，请勿在邮箱迁移后运行 zmpurgeoldmbox（或通过 SOAP 的 PurgeMovedMailboxRequest）。 
• 作为迁移后清理的一部分，禁用触发 zmpurgeoldmbox 的任何自动化或脚本。 
• 跳过清除会在源服务器上留下残留的本地元数据（MySQL + Lucene）。这是无害的，可以在贴上补丁后清理掉。 
• zmmboxmove 本身不受影响 - 邮箱迁移继续正常工作。只有迁移后清除步骤是有问题的。 

修复 

10.1.17 中更正的行为将是： 

• 外部只有使用显式的 –forceDeleteBlobs 标志才能删除 Blob。 
• 目标版本：ZCS 10.1.17 补丁。
• 如果您需要抢先体验版本，请联系 Zimbra 支持。 

下一步做什么 

1. 在任何具有外部存储的环境中进行邮箱迁移后，立即停止运行 zmpurgeoldmbox。禁用相关的自动化。
2. 审核最近的迁移：如果 zmpurgeoldmbox 已运行，请使用以下命令验证目标服务器上的 blob 完整性： 

zmprov gmi user@example.com 

zmblobchk -m <mailboxId> -v –output-used-blobs start 

如果输出显示外部的“blob not found”错误定位器（包含@@），这些 blob 已被删除。 

1. 如果发生数据丢失，请检查您的对象存储提供商是否支持版本控制或软删除，可能有恢复路径。 
2. 10.1.17 补丁计划：升级后，您可以安全地恢复 zmpurgeoldmbox 并清理解决方法期间残留的元数据。 

问题？ 

如果您有疑问，请联系 Zimbra 支持。 

受影响的版本：ZCS 10.1.15 至 10.1.16（所有版本） 

修复版本： ZCS 10.1.17（目标） 

跟踪参考：ZBUG-5265 

严重性：严重 - 潜在数据丢失