上周我的 OpenClaw 突然连微信消息都不回了服务日志里全是超时打开文件管理器一看C 盘可用空间只剩 380MB。查了半天最后定位到问题根源——数据迁移没做对。OpenClaw 本体安装所占的空间其实不大真正把 C 盘撑爆的是它背后的 WSL2 虚拟磁盘、Docker 数据卷和本地模型文件。这篇文章把我从 C 盘迁到 D 盘的全过程、踩过的坑、以及迁完之后的长期维护方案完整写出来给所有本地部署 OpenClaw、又饱受 C 盘空间困扰的朋友作参考。1. 绕不开的第一步先搞清楚 OpenClaw 到底把数据存在了哪里很多人一看到 C 盘爆红就急着开搞迁移结果迁了半天发现 D 盘倒是空出来了OpenClaw 该卡还是卡。原因很简单你没搞明白数据在哪里迁移就无从谈起。OpenClaw 这种本地优先的智能体框架部署方式通常不是单一的绿色软件而是由几个组件拼起来的OpenClaw 主程序、Docker 容器、本地模型服务、状态管理/知识库存储等。每一个组件都有自己的落盘方式而且默认全都往 C 盘塞。1.1 真正的数据大头不是程序本体而是运行时的几个仓库这是我在实际排查中最大的认知纠偏。OpenClaw 主程序本身不管是 GitHub 拉下来的源码目录还是安装包释放出来的文件撑死几百兆到一两个 G。真正吃空间的是下面这几个运行时的仓库Docker Desktop 的 WSL2 后端数据文件路径一般在C:\Users\你的用户名\AppData\Local\Docker\wsl\disk\docker_data.vhdx。这个文件是动态扩展的虚拟磁盘OpenClaw 的镜像、容器、数据卷全在它里面。我见过不少人这个文件直接涨到 60GB 以上。WSL2 发行版的虚拟磁盘如果你装了 Ubuntu 用于 WSL2路径一般在C:\Users\你的用户名\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu...\LocalState\ext4.vhdx。WSL 里的系统文件、依赖、以及在 WSL 里直接跑的数据都会写进这个 vhdx。Ollama 本地模型目录默认在C:\Users\你的用户名\.ollama\models。一个 7B 参数的模型量化后大概是 4~6GB一个 14B 模型 8~10GB如果你下过好几个模型这一项就能轻松吞掉二三十 G。OpenClaw 配置、日志、知识库存储包括用户目录下的.openclaw文件夹、日志文件、以及向量数据库的索引文件。单个文件不大但智能体长时间运行产生的日志和索引增长非常可观。1.2 为什么 OpenClaw 比普通应用更容易拉满 C 盘普通软件的数据是写入一个固定的安装目录但 OpenClaw 这种智能体框架不一样。它运行时的数据写入路径分散在多个地方而且增长模式是持续写入、不自动清理日志高频刷盘智能体每次和微信/飞书交互、每次调用工具、每次推理都会写日志。接入 IM 之后消息频率越高日志增长速度越快。容器可写层膨胀如果你直接用docker run而不做数据卷映射OpenClaw 在容器里产生的所有数据都会写进容器可写层这层数据就在docker_data.vhdx里。容器删了重建数据就没了但虚拟磁盘文件不会缩小。本地模型和向量检索的双重存储本地模型文件是静态占用向量数据库/知识库索引则是动态增长。多轮对话的上下文、工具调用结果、导入的文档都会变成向量落盘。1.3 别用眼睛找空间先量化再动手迁移前第一步不是复制粘贴而是测量。我强烈建议你装一个 WizTree免费或者 TreeSize直接扫描 C 盘按文件大小排序。结果出来之后你会发现排在最前面的几个文件几乎必然是那几个 vhdx 和模型目录。如果你不想装图形工具也可以用 PowerShell 快速定位某个目录的占用Get-ChildItem C:\Users\$env:USERNAME\.ollama\models -Recurse -Force -ErrorAction SilentlyContinue | Measure-Object -Property Length -Sum | Select-Object -ExpandProperty Sum再配合wsl --list --verbose查看 WSL 发行版的运行状态。把这些数据记下来迁移完成后对比验证才知道自己到底迁了什么、省了多少空间。2. 动迁移命令之前先做这四个确认这里说句实在话迁移本身不复杂复杂的是在迁移过程中把数据搞丢。我见过太多人一上来就wsl --unregister结果 WSL 里的数据库、配置、甚至没备份的项目文件全没了后悔都来不及。所以任何迁移动作开始之前先按下面四步走。2.1 备份顺序先配置后数据容器镜像一个都不能漏我的备份优先级是这样的OpenClaw 配置目录通常叫.openclaw里面可能有.env配置、skills、token、会话状态、知识库配置。这一项体积小但价值最高建议用 robocopy 复制一份到 D 盘。docker-compose.yml 和 .env 文件如果你是用 compose 部署的这两个文件是你的部署地图没有它们你连服务都还原不回来。Docker 镜像和命名卷镜像可以docker save导出命名卷可以映射到宿主机目录后直接复制。数据卷里的东西往往是真正的业务数据比如 OpenClaw 的会话记录。模型文件Ollama 模型文件很大如果你网络条件一般重下会很痛苦建议优先备份。备份命令示例docker save -o D:\backup\openclaw-images.tar openclaw-image-name docker ps -q --filter nameopenclaw | ForEach-Object { docker commit $_ openclaw-backup:latest }项目目录用 robocopy 整体复制robocopy C:\path\to\openclaw-project D:\backup\openclaw-project /E /COPY:DAT注意robocopy 的退出码 1 表示成功复制了文件不是报错。很多第一次用 robocopy 的人看到exit code 1以为失败了其实恰恰相反。2.2 硬编码路径与权限绑架迁移前必须收集的清单OpenClaw 这类框架的配置文件里经常写死一堆绝对路径。如果直接复制文件过去不把路径改掉服务起来之后会沿着老路径找文件找不到就报错或者更麻烦——找得到但不完整。我建议在动迁移命令之前先做一次全项目范围的路径搜索。重点排查这些位置.env文件中的OPENAI_BASE_URL、OLLAMA_BASE_URL、DATA_DIR等变量docker-compose.yml 中volumes冒号左边的宿主机路径OpenClaw 配置文件中的知识库/向量库路径Windows 计划任务、启动脚本里指向 C 盘的路径桌面和开始菜单快捷方式的目标路径路径写法还有个坑Windows 上用反斜杠C:\Users\...但在 JSON 或 YAML 配置里反斜杠经常需要转义写成C:\\Users\\...。迁移到 D 盘之后如果用 Docker 容器跑服务宿主机路径还要考虑写成/mnt/d/...的形式。这些细节不提前理清楚后面每一个都会变成启动报错。2.3 恢复分区、压缩卷这类扩容手段和迁移怎么选之前有很多人问我C 盘满了能不能把 D 盘的空间分给 C 盘特别是搜索关键词里排在前面的一堆c盘扩容d盘压缩卷无法给c盘c盘和d盘之间有一个恢复分区。这里说清楚一个重要事实Windows 自带的磁盘管理只能从相邻的未分配空间扩展 C 盘。如果你把 D 盘压缩卷腾出了一块空间这块空间在 D 盘右侧C 盘根本用不到。如果 C 盘和 D 盘之间还夹着一个恢复分区那磁盘管理里的扩展卷选项基本就是灰色不可用的。有人会去用第三方分区工具强行移动恢复分区这操作不是不行但风险和收益完全不成正比恢复分区一旦搞坏系统恢复能力就没了还可能把引导搞挂。我的结论很直接如果你 C 盘和数据盘是同一块物理磁盘上的两个分区与其折腾分区扩容不如做数据迁移。迁移不需要动分区表不碰引导风险小得多而且效果是立竿见影的——把 WSL2 虚拟磁盘、Docker 数据、模型文件挪到 D 盘之后C 盘空间立刻回来几十 G以后系统更新、临时文件都有余量。3. 四条迁移链路逐个击破WSL2、Docker、Ollama 与 OpenClaw 配置搞清楚了数据结构、做完了备份下面进入实操环节。我把迁移拆成四条相对独立的链路每一条负责一个数据来源。你可以只做自己需要的部分也可以四条全做。但顺序不要乱建议按照 WSL2 → Docker → Ollama → OpenClaw 配置的顺序来因为后面的操作多多少少依赖前面的结果。3.1 WSL2 发行版整体搬迁export 和 import 的正确姿势如果你在 WSL2 里装了 Ubuntu而且 OpenClaw 的部分服务、数据或依赖在 WSL 内部那么 WSL 的 ext4.vhdx 是必须要处理的。最稳妥的方案是导出再导入而不是手动复制 vhdx 文件。直接复制正在使用的 vhdx 容易导致文件损坏而且 WSL 进程还占着文件复制也会失败。操作流程如下先退出 Docker Desktop避免它占用 WSL 发行版。然后在管理员 PowerShell 里执行wsl --shutdown导出当前发行版为 tar 归档文件wsl --export Ubuntu D:\wsl-backup\ubuntu.tar这一步的时间取决于 WSL 内部数据量一般几分钟到几十分钟。导出完成后检查一下 tar 文件大小确保大于 0。注销原发行版wsl --unregister Ubuntu这一步会删除原发行版的所有数据。但别慌你已经导出备份了。在新位置导入wsl --import Ubuntu D:\wsl\Ubuntu D:\wsl-backup\ubuntu.tar --version 2这里的D:\wsl\Ubuntu是新的安装目录之后 ext4.vhdx 就会生成在这里。导入之后有一个非常经典的坑原本的默认用户会变成 root。因为wsl --import导入的归档文件丢失了默认用户的注册信息。你会发现用wsl -d Ubuntu进去是 root 用户之前普通用户环境下安装的所有东西都变得权限错乱OpenClaw 容器内写入文件时经常报 permission denied。解决办法是wsl -d Ubuntu -u root然后编辑/etc/wsl.conf[user] default你的WSL用户名保存后执行wsl --shutdown重新进入 WSL用whoami确认当前用户已经恢复。再用df -h /确认根目录所在磁盘已经是 D 盘路径。3.2 Docker Desktop 数据盘单独改道比想象中简单但别手动复制 vhdx对于新版 Docker Desktop4.30 以后所有 Docker 数据——镜像、容器、数据卷——都集中在docker_data.vhdx里。最省心的迁移方式是让 Docker Desktop 自己搬在图形界面里操作打开 Docker Desktop → Settings → Resources → Advanced → Disk image location把位置改成D:\DockerData然后点 Apply Restart。Docker Desktop 会自己把数据 vhdx 搬到新位置并完成重新挂载。但有个现实问题如果你的 C 盘已经满了Docker Desktop 在搬数据的过程中需要临时空间可能搬不过去。这时候先做一次大扫除把临时镜像、停止的容器、悬空数据卷清掉腾出空间docker system prune -af如果还是不够可以临时把 Docker Desktop 的 dataFolder 改到 D 盘的一个临时目录让它把数据先瘦身再搬。还有一种做法是修改配置文件。新版 Docker Desktop 的配置在C:\Users\你的用户名\AppData\Roaming\Docker\settings-store.json里有一个dataFolder字段。关闭 Docker Desktop 后把字段值改成D:\DockerData保存后重启。不过不同版本的字段名和文件路径有差异除非你很确定否则我还是建议用 GUI 操作容错率高得多。这里特别提醒不要手动复制正在运行中的 vhdx 文件。虚拟磁盘在被挂载时复制轻则文件损坏重则整个 Docker 数据全丢。如果你一定要走命令行也要先wsl --shutdown确认磁盘没有被占用再做复制。3.3 Ollama 本地模型仓库移植环境变量改对了模型一个都不用重下Ollama 的默认模型目录在C:\Users\你的用户名\.ollama\models。迁移的核心思路是改环境变量OLLAMA_MODELS指向 D 盘新目录然后把模型文件搬过去。具体步骤完全退出 Ollama。任务栏托盘图标右键退出或者taskkill /IM ollama.exe /F不要在 Ollama 还在运行时移动模型文件不然文件被占用robocopy 会报一堆错而且模型文件可能损坏。新建 D 盘模型目录并复制文件robocopy C:\Users\你的用户名\.ollama\models D:\ollama\models /E /COPY:DAT /R:2 /W:5/R:2表示失败重试 2 次/W:5表示等待 5 秒再重试这两个参数可以有效避免个别文件占用导致整个复制失败。设置用户环境变量setx OLLAMA_MODELS D:\ollama\models重启 Ollama确认模型还在ollama list如果列表为空先检查环境变量是否生效echo %OLLAMA_MODELS%。然后确认模型目录里的文件是否完整尤其是以blobs命名的子目录。迁移之后还有一个特别隐蔽的问题如果你的 OpenClaw 是在 Docker 容器里运行而 Ollama 跑在宿主机上那么 OpenClaw 代码里的localhost:11434指向的是容器自身不是宿主机。你需要把它改成http://host.docker.internal:11434。这个坑在迁移后非常常见——迁移前可能配置就已经有这个隐患但迁移过程动了环境问题就暴露出来了。3.4 OpenClaw 配置目录、skills 与知识库的搬迁最后是 OpenClaw 本身的配置和业务数据。这里我不写死路径因为你可能是用源码方式部署也可能是 Docker 方式部署路径差异很大。但思路是一致的先找到 OpenClaw 的数据目录。搜索你的用户目录下有没有.openclaw、skills、data、vector_store、memory之类命名的文件夹。把这个目录整体复制到 D 盘比如D:\openclaw-data。全局搜索配置文件里的旧路径。把所有指向 C 盘的配置项改成 D 盘新路径。这里要特别注意 .env 文件里的写法——C:\Users\...在部分解析器里会出问题稳妥起见可以将路径分隔符统一改成/。如果你是用 docker compose 部署 OpenClaw强烈建议把关键数据目录做成显式数据卷映射例如volumes: - D:\openclaw-data:/app/data - D:\openclaw-skills:/app/skills这样以后容器重建、升级镜像、再次迁移数据都在 D 盘下一次迁移的成本几乎为零。这也是这次迁移中最值得做的长远投资。迁移完成后发一条测试消息让 OpenClaw 正常调用一次模型、记录一次日志确认数据确实写入了新路径。这一步不能省。4. 迁完最容易踩的五个启动坑附带完整排查顺序数据迁移完成只是第一步真正常见的问题是迁移后服务起不来。以下五个问题我基本都遇到过而且每一个都对应了一个具体的排查链路而不是重启试试。4.1 WSL 默认用户丢失导致 root 权限混乱症状容器能启动但 OpenClaw 在容器里写配置文件时权限被拒或者挂载目录的文件属主变成了 root普通用户删不掉。排查链路先确认 WSL 里当前用户是不是 rootwsl -d Ubuntu whoami如果输出root那问题就在这。原因是wsl --import后默认用户被重置为 root之前的普通用户配置没有自动恢复。修复方法在 3.1 节已经写了改/etc/wsl.conf的[user] default字段然后wsl --shutdown重启。改完之后还要检查宿主机的 D 盘挂载目录权限必要时在 WSL 内执行sudo chown -R 用户名:组名 /mnt/d/openclaw-data4.2 control UI 启动失败与端口占用症状OpenClaw 的 Web 控制台打不开提示control UI did not start或者页面一直转圈加载不出来。排查链路先看容器状态docker ps -a如果容器已经 Exited直接看日志docker logs 容器名 --tail 100如果容器在运行但 UI 打不开检查端口是否被旧进程占用netstat -ano | findstr :端口号迁移后最容易出现的情况是旧实例没有关干净新容器起不来端口被占。把旧的进程记下 PID 结束掉或者停掉旧容器再重启新的。浏览器用无痕模式访问一次排除浏览器缓存导致的假失败。4.3 模型名错误unknown model 报错症状OpenClaw 回复请求时日志里出现类似agent failed before reply: unknown model: deepseek的报错。这个报错的热度很高我猜是因为很多人迁移后 Ollama 环境变量没生效或者模型名字带 tag 没写全。排查链路非常简单在宿主机上执行ollama list看输出的模型列表里有没有你配置的那个名字。如果列表为空说明 OLLAMA_MODELS 环境变量没生效或者模型文件没有完整迁移。检查echo %OLLAMA_MODELS%的输出是否指向 D 盘然后用ollama pull 模型名重新拉取这时候模型文件会下载到 D 盘新目录之前的努力也不算白费。如果模型在列表里但 OpenClaw 依然报 unknown model检查 OpenClaw 配置文件里的模型名是否带了完整 tag。比如deepseek-r1:7b只写deepseek-r1不一定能匹配到。还有一个容易忽略的点OpenClaw 在 Docker 容器里调用 Ollama 时用localhost:11434但容器里的 localhost 是容器自己。把 base_url 改成http://host.docker.internal:11434再试。4.4 docker-compose 数据卷映射路径失效症状容器能启动OpenClaw 看起来一切正常但会话记录是空的知识库内容也丢了。这个是迁移后最隐蔽的坑因为服务没报错。原因通常是docker-compose.yml 里 volumes 的宿主机路径还写的是 C 盘旧目录迁移后这个目录不存在了Docker 就自动新建了一个空目录挂载进去服务正常运行但数据是空的。排查链路看编排文件里 volumes 部分写的路径docker inspect 容器名 --format{{json .Mounts}}如果 Source 路径指向的是不存在的旧 C 盘路径改掉后重新创建容器docker compose up -d --force-recreate另外注意如果服务跑在 WSL 内部docker-compose 里的宿主机路径要写/mnt/d/...而不是D:\...否则路径解析也可能对不上。4.5 接入微信/飞书后的回调与 token 失效症状OpenClaw 正常启动但微信或飞书的消息发过去机器人完全不回复或者提示回调失败。排查链路先看 OpenClaw 日志确认消息有没有到达服务。如果压根没有收到消息问题多半在平台的回调地址没有更新或者 webhook 服务没起来。迁移过程中如果你改了端口映射、换过 IP、重启过容器回调地址里的 IP/域名可能需要重新配置。尤其是用内网穿透工具暴露服务的情况穿透进程本身也要跟着迁移到 D 盘环境否则回调地址指向的机器已经不在服务了。另外部分接入方案要求重启后重新扫码授权token 会变这个也要在管理后台里重新配置。5. 不想半年后再迁一次长期防 C 盘膨胀的维护动作迁移完成后C 盘确实回来了几十 G但如果你不改变使用习惯半年后很可能会再次爆满。WSL2 的虚拟磁盘、Docker 数据卷、日志文件这些都是成长型数据放任不管就会继续膨胀。以下是我迁移后一直在做的维护动作也是我认为值得长期坚持的三件事。5.1 限制 WSL2 虚拟磁盘的无限膨胀WSL2 的 vhdx 是动态扩展的写入数据时变大但删除数据后不会自动缩小。这就是为什么很多人明明删了一堆模型、清理了 Docker 镜像C 盘空间却一点没回来。要压缩虚拟磁盘正确流程是在 WSL 内部执行sudo fstrim --all告诉文件系统哪些块是空闲的。wsl --shutdown。用 diskpart 压缩 vhdxdiskpart select vdisk fileD:\wsl\Ubuntu\ext4.vhdx attach vdisk readonly compact vdisk detach vdisk exitDocker 的docker_data.vhdx也一样先docker system prune -af退出 Docker Desktop再用 diskpart 压缩。另外可以在C:\Users\你的用户名\.wslconfig里配置资源上限[wsl2] memory8GB processors4这会限制 WSL 能占用的内存和 CPU虽然不直接控制磁盘大小但可以防止整个系统被 WSL 拖到卡死变相降低出现新问题的概率。5.2 Docker 与日志的定期瘦身OpenClaw 长时间运行日志文件会持续增长。给 docker-compose.yml 里的服务加上日志轮转配置是我迁移后最后悔没早点做的事logging: driver: json-file options: max-size: 20m max-file: 5这样单个日志文件最大 20MB保留最近 5 份超过自动清理不会再无限膨胀。另外我养成了一个习惯每两周执行一次docker system prune清理悬空镜像和停止的容器。注意docker system prune --volumes会把没有被容器使用的数据卷一起删掉执行前一定确认无用卷里没有还想留的数据。OpenClaw 自身的日志如果支持按天轮转就开起来不支持就写个计划任务定期删除 N 天前的日志。5.3 目录软链接兜底方案里的应急手段有些程序不提供数据目录配置项遇到这种情况我才会用 Windows 的目录联接junction兜底。原理就是让 C 盘的一个目录指向 D 盘的真实目录mklink /J C:\Users\你的用户名\AppData\Local\Docker D:\DockerData\Docker做法要点先把原目录整体 robocopy 到 D 盘再删除 C 盘原目录最后建 junction。顺序绝对不能反。但我也要提醒你junction 不是银弹。有些程序升级时会删掉 junction重新创建真实目录链路就断了下次启动就会重新在 C 盘写数据。所以我的优先级始终是——能改配置的改配置改不了配置的最后才用 junction。5.4 安装新组件时的源头控制如果以后要在 D 盘机器上重新部署一套 OpenClaw我的建议是安装阶段就把所有可配置的数据目录都指到 D 盘。Ollama 安装后立刻设置OLLAMA_MODELSDocker Desktop 安装后第一次启动就走设置里把 Disk image location 改到 D 盘OpenClaw 用 docker compose