一次彻底的 Linux 工作站升级（上）——从 HDD 到 NVMe 的系统迁移与数据分离实战

原创于 2025-07-16 20:37:58 发布 · 829 阅读

CC 4.0 BY-SA版权

文章标签：

不得不说 gemini写的博客还挺燃，以下迁移流程几乎全程由gemini2.5pro指导我完成，所以我把交流的过程生成博客分享出来，供大家参考。

大家好，作为一个深度依赖 Linux 进行机器人和AI相关科研工作的开发者，我的工作站随着项目的增多，逐渐暴露出了一些性能瓶颈和管理上的痛点。系统之前错误的安装在慢速的机械硬盘（HDD）上，而高速固态硬盘（SSD）空间却被 Windows 占用；最重要的是，系统、软件、个人数据、科研项目全都混杂在一起，不仅拖慢了速度，也给备份和管理带来了巨大的挑战。

最近，我新购入了一块 2TB 的 NVMe SSD，决心对我的工作站进行一次彻底的“换心手术”。这篇博客将详细记录我将现有 Ubuntu 22.04 系统，从旧的 HDD 迁移到全新的 NVMe SSD，并实现操作系统与用户数据完全分离的全过程。

这不仅仅是一份操作指南，更是一次充满了“陷阱”与“顿悟”的真实旅程。希望能为有同样需求的朋友们提供一份详尽的参考。

第一章：战前准备 —— 诊断现状与规划蓝图

在进行任何操作前，最重要的事情永远是“知己知彼”。

1.1 诊断我的“旧世界”

我最初以为我的系统是安装在一块由两张500G磁盘组成的1T空间里。但经过 df -h 和磁盘工具的仔细检查，真实情况远比想象的复杂和不合理：

磁盘1 (/dev/nvme1n1): 一块 512GB NVMe SSD。上面安装了 Windows 系统，并且包含着至关重要的 EFI 系统分区 (/dev/nvme1n1p1)，这是所有操作系统启动的“大脑”。
磁盘2 (/dev/sda): 一块 500GB 机械硬盘 (HDD)。我的主力科研系统 Ubuntu 22.04 就憋屈地住在这个盘的 /dev/sda5 分区上。
磁盘3 (/dev/nvme0n1): 这就是我新加入的“救世主”——一块全新的 2TB NVMe SSD。

这个布局最大的问题是：我的主力系统运行在最慢的硬盘上，而高速硬盘却没能发挥最大价值。

1.2 绘制我的“新世界”蓝图

有了新的 2TB SSD，我可以设计一个近乎完美的布局，核心思想是 “系统与数据分离”：

系统盘: 将所有操作系统（现有的 Ubuntu 22.04 和计划安装的 Ubuntu 20.04）都放在高速的硬盘上，但给它们分配固定且不必过大的独立空间。系统盘只负责运行系统和软件。
数据盘: 将一个巨大的分区作为所有个人数据、科研项目、代码、数据集的“数据仓库”。这个仓库独立于任何操作系统，方便管理和备份。

最终规划如下：

物理硬盘	分区设备名 (LABEL)	大小	文件系统	用途
新 2TB SSD (`/dev/nvme0n1`)	`/dev/nvme0n1p1` (Ubuntu-20-SYSTEM)	300G	ext4	【预留】给未来 Ubuntu 20.04 的系统盘
	`/dev/nvme0n1p2` (Ubuntu-22-SYSTEM)	200G	ext4	【本次迁移目标】给现有 Ubuntu 22.04 的新家
	`/dev/nvme0n1p3` (SHARED-DATA)	~1.5T	ext4	【数据仓库】存放所有个人和科研数据
旧 512GB SSD (`/dev/nvme1n1`)	`/dev/nvme1n1p1` (EFI)	300M	vfat	【启动中枢】所有系统的引导分区，绝对不能动！
	其他分区	-	NTFS	Windows 操作系统
旧 500GB HDD (`/dev/sda`)	`/dev/sda5`	325G	ext4	【待淘汰】我们当前的 Ubuntu 22.04 系统

【关键点 1：识别物理硬盘】 我们在旅程的一开始就遇到了一个巨大的认知偏差！我最初以为新硬盘会被识别为 /dev/nvme1n1，但系统实际识别的结果恰恰相反。新 2TB 盘是 /dev/nvme0n1，旧 512G 盘是 /dev/nvme1n1。这个偏差差点导致我们将系统迁移到错误的硬盘上。

教训：永远不要凭主观臆断！在进行任何磁盘操作前，务必使用 lsblk -f 或 sudo fdisk -l 命令，仔细核对每个硬盘的设备名、大小、分区和标签，制作一张准确的“地图”。

第二章：手术开始 —— 迁移系统

我们的核心任务是：把 /dev/sda5 上的 Ubuntu 22.04 系统，完整地“克隆”到 /dev/nvme0n1p2 上。

警告：在开始前，请务必备份所有重要数据到外部硬盘！这是你的最后一道保险。

2.1 准备手术工具 (Live USB)

我们不能在一个正在运行的系统上对它自己动刀。因此，必须制作一个 Ubuntu 的启动U盘（Live USB），从 U盘进入一个临时的“手术室”环境。

下载 Ubuntu 22.04 的 ISO 镜像文件。
制作启动盘：我使用了 Balena Etcher 这款工具，它简洁可靠。安装 .deb 包后即可使用。

2.2 克隆系统文件 (`rsync`)

从 Live USB 启动后，选择 "Try Ubuntu"，我们就进入了“手术室”。

挂载分区：

# 获取 root 权限
sudo -i
# 创建临时挂载点
mkdir /mnt/old_system
mkdir /mnt/new_system
# 挂载旧系统（源头）和新分区（目的地）
mount /dev/sda5 /mnt/old_system
mount /dev/nvme0n1p2 /mnt/new_system

执行克隆：我们使用 rsync 命令进行克隆。

【问题 1：空间不足与数据分离】 我第一次尝试直接完整克隆 rsync -axHAX /mnt/old_system/ /mnt/new_system/，但很快就失败了，提示“No space left on device”。

原因：我为新系统盘只规划了 200GB，但我旧系统盘里包含了大量的 Docker 镜像和科研数据，总大小超过了 200GB。

解决方案：这恰好是我们实施“系统与数据分离”的最佳时机！我们使用 rsync 的 --exclude 参数，在迁移时故意排除掉庞大的个人数据文件夹 (/home) 和 Docker 数据文件夹 (/var/lib/docker)。我们只迁移纯粹的操作系统。

bash
rsync -axHAX --info=progress2 --exclude='/home' --exclude='/var/lib/docker' /mnt/old_system/ /mnt/new_system/

【问题 2：rsync 瞬间完成？】 在一次尝试中，rsync 命令瞬间就完成了，没有任何文件复制的迹象。通过 ls /mnt/new_system 检查后发现，目标目录是空的。

原因：很可能是在执行 rsync 前，源目录 /mnt/old_system 没有被正确挂载，导致 rsync 认为源头是空的。

解决方案：在执行 rsync 前，务必用 ls /mnt/old_system 和 ls /mnt/new_system 进行双重验证，确保源头有文件，目标是空的（或只有lost+found）。

2.3 修复引导 (`chroot`)

系统文件已经搬到了新家，但电脑的“地址簿”还是旧的。我们需要进入新系统，告诉它两件事：1. 你的新地址；2. 更新开机菜单。这个过程叫 chroot。

挂载必要的虚拟文件系统：

【问题 3：chroot 前的关键一步被遗漏】 grub-install 命令的目的是更新 EFI 分区里的引导信息。但 chroot 进去的新系统，默认并不知道 EFI 分区在哪里。

原因：我们进入 chroot 前，只挂载了根分区 /，忘记了把真正的 EFI 分区也挂载到新系统内部的 /boot/efi 目录上。

解决方案：在 chroot 之前，必须执行这关键的一步：

bash
# 将真正的 EFI 分区 (nvme1n1p1) 挂载到新系统的 /boot/efi 目录上
mount /dev/nvme1n1p1 /mnt/new_system/boot/efi

进入 chroot 环境：

# 绑定其他虚拟文件系统
mount --bind /dev /mnt/new_system/dev
mount --bind /sys /mnt/new_system/sys
mount --bind /proc /mnt/new_system/proc
# Chroot!
chroot /mnt/new_system

更新地址簿 (fstab)：在新环境里，用 blkid 找到新家 /dev/nvme0n1p2 的 UUID，然后编辑 /etc/fstab 文件，将根目录 / 的 UUID 更新为这个新的值。
更新开机菜单 (GRUB)：

【关键点 2：grub-install 的目标盘到底是谁？】 这是另一个巨大的迷惑点。我的新系统在 /dev/nvme0n1p2 上，但正确的 grub-install 命令的目标却是 /dev/nvme1n1！

原因：grub-install 的目标不是你的系统分区，而是那个包含了 EFI 分区的物理硬盘。它要把 GRUB 的控制权交到这个主启动盘上，才能统一管理所有系统的启动。

解决方案：根据我们第一步的“地图”，EFI 分区在 /dev/nvme1n1p1，所以它所属的物理硬盘就是 /dev/nvme1n1。

bash
    # (在 chroot 环境里)
    update-grub
    grub-install /dev/nvme1n1
这条命令执行后提示 `Installation finished. No error reported.`，我们就成功了。

退出并重启：

exit
umount -R /mnt/new_system
umount /mnt/old_hdd
reboot

重启时务必拔掉U盘！

第三章：术后康复 —— 配置新系统

重启后，我遇到了两个经典的“术后综合症”。

3.1 修复登录循环

【问题 4：输入正确密码后，黑屏一下又回到登录界面】

原因：这是典型的“登录循环”。因为我们迁移时排除了 /home 目录，导致新系统里根本不存在 /home/dora 这个主目录。系统无法为我加载桌面环境，只好把我踢回登录界面。

解决方案：
在登录界面按 Ctrl+Alt+F3 进入纯文本的 TTY 终端。
用用户名 dora 和密码登录。
手动创建主目录并授权：
bash
sudo mkdir /home/dora
sudo chown -R dora:dora /home/dora
sudo reboot 重启。

3.2 恢复个人环境

成功进入一个“出厂设置”的桌面后，我发现所有个人配置，比如 conda 命令、终端别名、VS Code 插件等，全都消失了。

【问题 5：conda: command not found 等命令丢失】

原因：和登录循环一样，因为我们现在用的是一个全新的、干净的 /home/dora 目录，里面那个记录了所有个人配置的隐藏文件 .bashrc 也是全新的。所有关于 conda 路径、ROS 环境、自定义别名的设置都消失了。

解决方案：这是一个一劳永逸的机会。我没有一个一个地重新配置，而是将旧硬盘里重要的配置文件和配置目录，用 rsync 或 cp -r 的方式，完整地复制到我新的 /home/dora 目录下。

主要恢复了以下内容：

~/.bashrc: 恢复所有终端环境和命令。
~/.gitconfig: 恢复 Git 配置。
~/.ssh: 恢复 SSH 密钥，免去重新配置服务器登录的麻烦。
~/.config/Code: 恢复 VS Code 的所有设置、主题和插件。
其他 ~/.config 里的软件配置目录。

第四章：数据安家 —— 实现最终蓝图

最后，也是最激动人心的一步，就是把我所有的科研数据安顿到那个 1.5T 的“数据仓库”里，并建立方便的访问方式。

挂载数据盘：修改 /etc/fstab 文件，将 /dev/nvme0n1p3 (我们的 SHARED-DATA 分区) 永久挂载到 /data 目录。
搬运数据：用 rsync -a /mnt/old_hdd/home/dora/ /data/dora/ 将旧硬盘里的所有个人文件，都搬到新数据盘里。
创建符号链接 (ln -s): 这是实现“体验无缝”的关键。
- 最佳实践：我没有为每一个项目都创建一个链接，而是创建了一个总的“工作区”链接：ln -s /data/dora/ ~/Workspace。今后，我所有的新项目都会在 ~/Workspace 里创建，从而自动存放在数据盘，完美解决了“怕遗忘导致备份不全”的问题。
- 为了方便: 我也为一些最常用的文件夹（如 Documents, Downloads）和核心项目（如 dora_ws）单独创建了链接，方便快速访问。

至此，上篇的所有迁移和配置工作宣告完成！我的 Ubuntu 22.04 系统已经在一个全新的、高性能的、结构科学的环境中稳定运行。它不仅快如闪电，而且再也不用担心系统盘被数据撑爆，备份也变得前所未有的简单。

在下篇中，我将记录如何在这个完美的基础上，安装第二个独立的 Ubuntu 20.04 科研系统，并实现两个 Ubuntu 系统共享同一个数据仓库的最终形态。敬请期待！