外观
迁移到新硬件
NAS 用了几年，主板、CPU 或整机要换了，不想把所有设置重做一遍。读完这一篇，你能选对迁移的方式，知道换了硬件之后哪些东西会变、会在哪里出问题，并且按清单逐项检查。
开始之前
- 先决定走哪条路，下面有对比。
- 迁移前一定要有备份：数据有独立备份，系统盘也做过备份，见 备份系统盘：backup 插件。
- 命令在 OMV 的 shell（root 身份）里执行。
- 新旧机器的 CPU 架构要一致：amd64 对 amd64，arm64 对 arm64。amd64 和 arm64 之间不能搬系统盘，只能重装。
迁移期间 NAS 要停机，而且有几个会出大事故的操作要避开
影响范围：迁移期间所有共享和应用都不可用。
前置条件：选一个没人使用的时间；备份已经验证过能恢复；记录好旧系统的状态（磁盘、网络、用户、共享，见下文清单）。
要避开的操作：不要让同一组数据盘同时连在两台机器上，也不要让新旧两台机器同时开着并使用相同的 IP 或主机名，否则会出现地址冲突，甚至两台机器同时写同一个文件系统导致损坏。不要对数据盘做格式化、创建文件系统这类操作来「试一下新机器」。
怎么回退：旧机器、旧系统盘和数据盘原样保留，直到新机器稳定运行一段时间。出问题就把硬件接回旧机器。
两条路怎么选
| 路线 A：整盘搬迁 | 路线 B：重装并接回数据盘 | |
|---|---|---|
| 做法 | 把系统盘和数据盘都装到新机器上，直接启动 | 在新机器上全新安装 OMV，只接回数据盘 |
| 好处 | 保留全部设置、用户、插件、计划任务 | 干净，没有旧机器的硬件残留，也适合大版本升级后重新开始 |
| 代价 | 硬件相关的设置会残留，网卡、引导方式可能需要修复 | 所有设置都要重建 |
| 适合 | 同架构、新旧硬件差别不大 | 引导方式变了（BIOS 换成纯 UEFI）、架构变了、旧系统有历史包袱 |
路线 B 的完整步骤，见 系统盘坏了：重装并接回数据盘，两者的区别只在于旧系统盘还在，所以能直接对照着重建。如果不确定，选路线 B，更稳妥。
路线 A：整盘搬迁
迁移前
- 把旧系统更新到最新，确认
omv-salt deploy list-dirty没有待应用的更改。 - 记录旧机器的状态，保存到别处：
sh
lsblk -o NAME,SIZE,MODEL,SERIAL,UUID,FSTYPE,MOUNTPOINTS > old-disks.txt
ip -br link > old-nics.txt
[ -d /sys/firmware/efi ] && echo UEFI || echo BIOS # 旧系统是 UEFI 还是传统 BIOS 引导
omv-sysinfo > old-sysinfo.txt- 记下哪些插件和设置是和硬件绑定的：CPU 频率设置、风扇控制、温度传感器、网络唤醒、定时开关机、UPS、核显加速（容器里的
/dev/dri）。 - 关机，拔掉电源。
在新机器上
- BIOS 设置对齐。 引导方式（传统 BIOS 或 UEFI）和旧机器一致，SATA 模式选 AHCI，把系统盘设为第一启动项。
- 接上系统盘和数据盘。 硬盘接在哪个 SATA 口无所谓，OMV 的挂载用的是文件系统 UUID。
- 开机。 观察能不能正常进入系统。
可能遇到的问题
启动卡在「等待根设备」，或者进入 initramfs 命令行。 新硬件的存储控制器驱动没有包含在旧系统的启动镜像里。用救援系统启动，挂载系统盘并 chroot（步骤见 用救援系统抢救数据 和 忘记管理员密码 里的 chroot 部分），然后在里面重建启动镜像：
sh
update-initramfs -u -k all
update-grub旧系统是传统 BIOS 引导，新机器只支持 UEFI。 需要新建 EFI 系统分区并安装 UEFI 版 GRUB，步骤较多、容易出错。这种情况下建议改走路线 B。
开机了，但网络不通。 OMV 按网卡名配置网络，名字由网卡所在的 PCI 位置等决定，换了主板或者换了插槽，名字就变了，配置里记录的旧网卡不存在，所以没有 IP。在本机控制台用 ip -br link 看新网卡的名字，然后运行 omv-firstaid，选 Configure network interface，重新配置。注意它会删除所有已有的网络接口配置，有 Bond、VLAN、网桥的要之后在界面里重建，见 改坏网络后怎么救。网卡的 MAC 地址变了，路由器上基于 MAC 的 DHCP 预留也要更新。
迁移后检查清单
| 检查项 | 怎么检查 | 说明 |
|---|---|---|
| 数据盘都在 | 存储器 → 磁盘（Storage → Disks） | 用型号和序列号核对，数量要对 |
| 文件系统都已挂载 | 存储器 → 文件系统（Storage → File Systems） | 软 RAID、Btrfs 多盘、LVM 靠磁盘上的元数据识别，和接口无关 |
| S.M.A.R.T. 监控 | 存储器 → S.M.A.R.T. → 设备（Storage → S.M.A.R.T. → Devices） | 重点检查。 监控设置记录的是磁盘的设备文件路径（通常是按型号和序列号命名的路径）。多数 SATA 盘换机之后还能对上，但个别磁盘（例如 USB 盘、换了 HBA 之后的盘）的路径可能变化。OMV 生成 smartd 配置时只保留实际存在的设备，对应不上的磁盘会被跳过，不会有任何提示，所以要逐块确认，必要时重新勾选 |
| 磁盘休眠设置 | 存储器 → 磁盘 里逐块查看编辑 | 同样按设备文件路径记录，逐块确认是否仍然生效 |
| 网络 | 网络 → 接口（Network → Interfaces） | 网卡名、静态 IP、Bond、VLAN、网桥 |
| 时间 | 系统 → 日期和时间（System → Date & Time），BIOS 时钟 | 新主板的 RTC 可能不对 |
| CPU 频率、风扇、温度传感器 | 对应的界面和插件 | 传感器路径因主板而异，通常要重新配置，见 温度监控与风扇控制 |
| 定时开关机、网络唤醒 | 系统 → 电源管理（System → Power Management）、对应插件 | RTC 唤醒和网卡唤醒因硬件而异，见 自动关机与定时唤醒 |
| 容器的硬件加速 | compose 文件里的设备映射 | 新机器没有核显或设备路径变了，要改 compose 文件 |
| ZFS 池 | ZFS 插件里的池状态 | 提示上次由另一个系统使用时，先确认旧机器已经关机，再按插件说明强制导入，见 ZFS 插件 |
| 重启一次 | reboot | 确认挂载、服务、容器都能自动恢复 |
数据盘上的东西
- 软 RAID（md）：阵列信息写在成员盘上，新机器上会被自动识别。OMV 的 md 插件会根据
/proc/mdstat生成配置，不需要你手动处理。 - Btrfs：多设备文件系统在所有成员盘都在的情况下会被识别。
- LUKS：加密分区需要你再次解锁。
- mergerfs、SnapRAID：配置存在系统盘的数据库里，随系统盘一起搬过来，成员盘的路径是按 UUID 记录的，通常不受影响，迁移后仍要核对池和阵列的状态。
路线 B：重装并接回数据盘
整个流程见 系统盘坏了：重装并接回数据盘。关键点是：安装前拔掉所有数据盘；用导入功能按原来的 UID 重建用户；创建共享文件夹时选原来的目录，已存在的目录权限不会被改动。
其他迁移场景
- 克隆系统盘到更大的 SSD。 同一台机器换盘，可以用 backup 插件的整盘备份和恢复，或者用 kernel 插件安装的 Clonezilla 救援镜像整盘克隆，见 内核插件：切换内核与 Proxmox 内核。克隆后新旧两块盘不要同时接在机器上，否则它们有相同的文件系统 UUID，容易启动到错误的那块。
- ARM 开发板之间。 引导程序和设备树是和具体开发板绑定的，系统盘不能直接换到另一块不同型号的板子上，只能走重装路线。
- 迁移到虚拟机。 在 Proxmox VE 上运行 OMV 的做法和取舍，见姊妹站的 OpenMediaVault：在 PVE 上跑一台轻量 NAS。
检查结果
- 新机器上所有数据文件系统都已挂载，容量和文件数符合预期。
- 用客户端通过 SMB、NFS 访问共享，读写正常，权限和以前一致。
- 告警邮件能收到测试邮件，S.M.A.R.T. 监控覆盖了每一块盘。
- 重启一次，一切自动恢复。
- 旧机器和旧系统盘没有丢弃，保留一段时间后再处理。
常见问题
路线 A 迁移之后，旧机器的主机名和 IP 冲突了。 迁移完成后，旧机器要保持关机，或者先改掉它的主机名和 IP 再开机。
换了主板之后，每次开机都提示时间不对。 检查 BIOS 里的 RTC 电池和时区，OMV 里确认 NTP 是启用的。
界面上有些设置指向不存在的设备。 这是硬件相关设置残留的典型表现，传感器、风扇最常见，S.M.A.R.T. 和磁盘休眠也可能遇到，逐项重新配置即可。
新机器比旧机器更耗电或更吵。 先对照 低功耗与静音 检查休眠、CPU 频率和 BIOS 的省电选项。