WSL2+Docker+Redis数据备份与迁移实战

上周帮同事迁移一台 Windows 开发机，他的日常环境是 WSL2 里跑 Ubuntu，Redis 装在 Docker 容器里，VSCode 用 Remote-WSL 连进去写代码。平时这套组合确实舒服，直到要换机器才发现问题：数据到底存在哪？怎么带出去？新机器怎么接住？折腾了一个下午，中间还踩了 docker commit 的坑——镜像打出来了，里面 Redis 却是空的。回来之后我把验证过的方案完整梳理了一遍，这篇内容就是针对“WSL + Docker + Redis”这个场景，讲清楚备份怎么选、文件从哪取、往新机器迁移怎么做、以及最后怎么验证备份确实可用。适合那些在 Windows 上用 WSL 做开发、用 Docker 起中间件，但还没真正演练过备份和恢复的朋友。

1. WSL2、Docker Desktop 与 Redis 容器：数据到底藏在哪

1.1 三层“看不见的墙”导致备份无从下手

很多人在 Windows 上装完 Docker Desktop，又开了 WSL 集成，就以为“Docker 跑在 WSL 里”，Redis 数据也顺理成章在 Ubuntu 里。这个认知在备份场景下会害死人。

从文件系统视角看，这套环境其实是三层结构：

第一层，WSL2 的每个发行版都是一个 ext4.vhdx 虚拟磁盘文件，比如 Ubuntu 对应 C:\Users\<用户名>\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu...\LocalState\ext4.vhdx。你在 Windows 资源管理器里看不到这个磁盘内部的文件。

第二层，Docker Desktop 自己也有一个名为 docker-desktop 的 WSL 发行版。你用 docker 命令创建的所有镜像、容器、数据卷，实际上都落在 docker-desktop 发行版的虚拟磁盘里，而不是你日常使用的 Ubuntu 发行版里。这也是很多人打开 Ubuntu 的目录结构，怎么都找不到 Redis 数据文件的原因。

第三层，Redis 官方镜像把容器内的 /data 目录声明为数据卷。不指定挂载时，Docker 会自动创建一个匿名卷来承接数据写入。

所以你在 Windows 上看到的 docker-desktop-data 或者 docker-desktop 对应的 ext4.vhdx，才是 Docker 数据的物理承载方。只复制 Ubuntu 的文件，根本拿不到容器数据。

1.2 两种常见部署形态，备份策略完全不同

我建议在一开始就分清你到底属于哪种情况：

如果连自己的环境属于哪种形态都不清楚，先敲一句：

bash复制docker context ls

如果显示的是 desktop-linux，那就是形态 A。如果显示的是 default，而且 docker ps 能在 WSL 里直接执行，多半是形态 B。这个判断决定了后续迁移走哪条路。

1.3 先确认 Redis 容器的数据卷挂载方式

无论哪种形态，备份 Redis 的第一步都是确认容器启动时是怎么挂载数据的。用这条命令看：

bash复制docker inspect redis --format '{{json .Mounts}}'

输出里能看到两类信息：

• Type: volume，说明用的是命名卷，比如 redis-data:/data。
• Type: bind，说明用的是宿主机目录直接绑定，比如 /home/user/redis-data:/data。

如果什么都没挂，那就是匿名卷。匿名卷在 docker rm 的时候不一定立刻删，但容器重建后很难再关联回去，所以越是匿名卷越要尽快备份。

2. 备份方案选型：为什么 dock