Nexus迁移后，管理界面看起来完整，不代表实际Blob与元数据仍一致。2019年一次Snapshot上传报500，最终线索不在Maven重试次数，而在Nexus服务端的 MissingBlobException。

迁移两个月后才暴露写入问题

迁移当时能浏览已有JAR和Snapshot版本，依赖也没有立刻出问题。两个月后再上传某个Snapshot，Maven提示取不到远程Maven元数据，最终显示：

HTTP 500
RetryDeniedException: Reached max retries: 8/8

这只能说明服务端处理失败并耗尽重试，不能解释是网络、存储还是特定资产问题。

沿服务端原因链找到缺失内容

查看当时 sonatype-work/nexus3/log 下的日志，原因链中有：

MissingBlobException:
Blob <blob-id> exists in metadata, but is missing from the blobstore

组织、仓库和Blob标识已省略。错误表示元数据存在引用，而blobstore中取不到相应内容；它不直接证明丢失发生在哪一步，也不证明只坏了一个文件。

我还检查过 nexus.vmoptions 的工作目录指向，当时没有发现路径配错。继续诊断时仍应确认实际数据目录、blob store配置、挂载是否可用及权限，而不是只看程序目录。

当年的局部处理，不是通用修复命令

最先失败的请求指向 maven-metadata.xml。我当时尝试移除该Snapshot相关的三个元数据资产后重新上传：

maven-metadata.xml
maven-metadata.xml.md5
maven-metadata.xml.sha1

旧记录写明重新上传恢复，但没有明确是在仓库界面还是文件系统中删除。因此这里只保留历史处理经过，不给出直接删除存储文件的操作指令。

若缺失的是构件本体，重建索引或Maven元数据并不能创造原始JAR；删除引用还可能让本可恢复的资产失去定位信息。应先保护现状与一致备份，再按准确版本、数据库和存储后端评估恢复或官方修复任务，必要时向支持渠道确认。

备份数据库，也要备份对应Blob

数据库/元数据与Blob内容是两部分，备份时点差异会造成引用与内容不一致。Sonatype的备份说明要求同时考虑它们及相关文件系统数据；具体流程依部署后端不同，不能把今天的H2/PostgreSQL任务名称直接套回旧版本。Sonatype备份准备

迁移验收应包括配置、权限、元数据、Blob，以及选取不同仓库和版本的实际下载与校验；在授权测试范围内验证发布和Snapshot元数据更新，并保留回滚方案。

浏览页面、读到少量旧依赖、完成一次上传，分别覆盖不同路径。把这些检查分开，才能避免仓库迁完很久后才发现写入相关缺口。