WSL2 数据抢救：从 `E_UNEXPECTED` 故障到文件修复

突发故障：WSL2 无法启动

毫无征兆地，WSL2 突然罢工。启动时，终端直接抛出 灾难性故障 wsl/service/E_unexpected 的错误信息，Ubuntu-20.04 发行版彻底无法访问。这让我心头一紧，里面存储着不少重要的代码和数据。

初步尝试：备份与复制均失败

遇到这种情况，第一反应是赶紧备份数据。尝试使用 wsl --export 命令将发行版导出为 tar 格式的备份文件，可系统根本不响应，导出操作完全无法进行。

既然导出不行，想到了 WSL2 的核心存储文件 ext4.vhdx。找到这个文件的位置后，试图通过直接迁移、复制的方式进行数据抢救，但尝试了几次，复制过程都不顺利，显然这种方式也走不通。

更换思路：覆盖文件遇阻

换了个思路，先在 WSL2 中安装相同版本的 Ubuntu-20.04 发行版。安装完成后，执行 wsl --shutdown 命令关闭所有 WSL 进程，然后在 Windows 系统下，将之前有问题的 ext4.vhdx 文件覆盖到新安装发行版的对应目录下。

然而，这次尝试还是失败了。新安装的发行版依旧无法正常启动，推测这是因为 ext4.vhdx 文件内部已经损坏，单纯的覆盖解决不了问题。

关键操作：注销、挂载与修复

注销发行版

既然覆盖不行，决定先注销掉这个有问题的发行版，执行命令：

wsl --unregister Ubuntu-20.04

挂载损坏的虚拟磁盘

接下来，需要挂载那个损坏的 ext4.vhdx 文件来进行修复。在管理员权限的 PowerShell 中执行挂载命令：

wsl.exe --mount <path-to-ext4.vhdx> --vhd --bare

这里的 <path-to-ext4.vhdx> 需要替换为 ext4.vhdx 文件的实际路径，--bare 参数能保证只挂载不自动分配盘符。

确定挂载位置

挂载完成后，执行 wsl.exe lsblk 命令查看具体的装载位置，通过输出信息，确定了损坏的虚拟磁盘被挂载到了 /dev/sdd。

执行修复操作

知道了挂载位置，就可以进行修复了。在 WSL 终端中执行以下命令：

sudo e2fsck -f /dev/sdd

e2fsck 是专门用于修复 ext 系列文件系统的工具，-f 参数表示强制检查，即使系统认为文件系统正常。

最终恢复：覆盖文件成功

修复完成后，再次安装相同版本的 Ubuntu-20.04 发行版，执行 wsl --shutdown 关闭 WSL 进程，然后将修复好的 ext4.vhdx 文件覆盖到新安装发行版的目录下。

这次，当重新启动 WSL2 时，系统成功启动，里面的数据也完好无损，数据抢救工作终于完成。

总结

这次 WSL2 数据抢救经历表明，当遇到 灾难性故障 wsl/service/E_unexpected 时，不要急于重新安装系统。可以通过注销发行版、挂载损坏的虚拟磁盘、使用 e2fsck 工具进行修复等步骤，尝试挽救里面的数据。当然，日常做好数据备份，才是避免数据丢失的最佳方式。