一、碰到Blob Store迁移的典型场景

很多用Nexus做私有仓库的团队，跑久了都会碰到同一个糟心事：存文件的磁盘分区满了，上传新的Jar包、Docker镜像失败，甚至连服务都没法正常启动。这时候就得把Nexus的Blob Store（说白了就是存所有二进制资产的“仓库柜”）整体迁到更大的新分区，不过这里坑特别多，尤其是资产完整性校验和路径映射，稍不注意就会出问题，今天就把这些避坑路径理清楚。

1.1 磁盘空间告急的真实处境

中小团队一般会把Nexus的文件和系统放同一个分区，或者单独分一个小分区给Nexus，用个半年一年后，各种编译输出、测试镜像、第三方依赖占满空间，要么没法继续存新东西，要么Nexus的日志目录也在这个满分区里，导致服务自动挂掉。这时候迁移Blob Store是唯一能快速解决问题的办法，总不能为了空间给整个服务器扩容吧？

1.2 为什么不能随便迁？

Blob Store是Nexus最核心的资产存储点，小到几十KB的工具类Jar，大到几个G的Docker镜像，都是存在这里的。而且Nexus的配置和这个目录的路径是绑定死的——如果你直接把目录复制到新分区，不改配置，Nexus还是会去原来的路径找文件，结果就是等于白迁，空间还是没解决，甚至还会因为找不到文件导致所有仓库失效，这个坑我自己踩过，花了半天才找回来。

二、迁移前必须做的准备与避坑提醒

很多人一碰到磁盘满了，就想着赶紧复制文件，跳过准备工作，最后出问题就是因为这个。迁移前这两步必须做，能帮你避开80%的后续坑。

2.1 别跳过的完整性校验

迁移前一定要检查原来的Blob Store里的文件有没有损坏，比如某个Jar包下载到一半没完成，或者上传时出错的临时文件，这些残次品如果被迁到新分区，后续用户下载就会报404或者文件损坏。我一般用两种方式校验：一种是Nexus自带的UI检查，进去Blob Store页面看每个仓库的资产数；另一种是用rsync的干跑模式，模拟复制看看有没有文件差异。

2.2 目标分区的准备工作

新分区必须是独立的、有足够空间的（建议留10%以上的冗余），而且最重要的是权限！Nexus是用特定用户（一般叫nexus）运行的，所以新目录的所有者必须是这个用户，不然Nexus启动后读不了新文件，会报Permission Denied的错，连登录都成问题，这个是所有Nexus运维的“命根子”，绝对不能忘。

三、迁移操作中的三个致命陷阱

这部分是核心，我把踩过的坑都整理出来，每一步都有示例，照着做就不会错。示例用的是Nexus Repository OSS 3.37.1这个稳定版本，技术栈单一，新手也能看懂。

3.1 标准迁移操作示例（避坑版）

# 1. 停止Nexus服务（必须！否则文件会被占用，复制出残缺）
systemctl stop nexus

# 2. 备份原有Blob Store目录（最坏情况能回滚，路径改成你自己的）
cp -a /opt/nexus/storage /opt/nexus/storage_backup_20240520

# 3. 创建新分区的目标目录（确保路径对，比如新分区挂在/data下）
mkdir -p /data/nexus/storage
# 关键！赋予Nexus运行用户读写权限，把nexus换成你自己的用户名（一般都是nexus）
chown -R nexus:nexus /data/nexus/storage

# 4. 迁移文件（用rsync比cp快，还能避免小文件遗漏，别加--delete参数！）
rsync -av /opt/nexus/storage/ /data/nexus/storage/

# 5. 修改Nexus配置，把Blob Store的路径改成新的（两种方式选一种，改完必须重启）
# 方式一：修改nexus配置文件（找<blobStore>标签，改path属性）
sed -i 's/path="\/opt\/nexus\/storage"/path="\/data\/nexus\/storage"/g' /opt/nexus/etc/nexus.xml

# 6. 启动Nexus服务（等30秒，让服务完全启动）
systemctl start nexus

这里要提一句，rsync的-a参数是归档模式，能保留权限、时间戳这些，比cp好用太多，千万别直接用cp，很容易丢东西。

3.2 三个最容易踩的陷阱详解

3.2.1 路径映射写错的坑

很多人把新路径写成/data/storage，少了一级目录（应该是/data/nexus/storage），导致Nexus找不到任何文件，所有仓库都失效。怎么避？迁移前先去Nexus的UI里看当前Blob Store的路径，比如默认是/opt/nexus/storage，迁的时候就把这部分改成新分区的路径，一字不差抄下来，别自己瞎改。

3.2.2 临时文件误迁移的坑

有人复制的时候直接拷整个/opt/nexus目录，把Nexus的临时文件、日志都带过去了，新分区一下子被占了很多没用的空间，复制时间也变长。怎么避？只拷Blob Store的目录，就是你在UI里看到的那个storage目录，别拷整个Nexus根目录。

3.2.3 非停机迁移的隐形坑

有些人不想停服务，想在线迁移，结果Nexus运行时有人同时上传新包，复制到一半的文件，新的包还在生成，迁移后新包没被复制，用户下载就会失败。怎么避？除非你用Nexus的高级Blob Store链接功能，否则一定要选维护窗口，停机迁移，确保所有文件都是静止的，不会有新的写入。

四、迁移后的验证与收尾

迁完不是完事了，还要检查有没有问题，不然等用户反馈就晚了。

4.1 完整的验证方法

第一步，看Nexus的UI：进入Blob Store页面，新的路径显示在线，已用空间和原来差不多（如果复制成功的话）；第二步，拿几个旧包和新上传的包下载试试，比如下载一个JAR，用md5sum校验和原来的文件一样，说明没损坏；第三步，看Nexus的日志，有没有permission denied或者file not found的报错。

4.2 技术优缺点与注意事项

优点是步骤简单，适合中小团队，不用复杂工具，照着示例就能做；缺点是需要维护窗口，大仓库（几百G）的话复制时间长，可能影响业务。注意事项有三个：第一，绝对别用rsync的--delete参数，会把旧目录删掉；第二，权限改完一定要重启服务；第三，迁完后把原来的旧目录备份，别着急删，等三天没问题再删，避免出问题。

五、总结

Nexus Blob Store迁移不是什么高科技，但是细节决定成败，最容易出问题的就是路径映射、权限和完整性校验这三个点。只要照着步骤来，每一步都检查，避开这些坑，就能顺利解决磁盘空间的问题，以后再也不用愁Nexus存不下新东西了。