旧服务器要下线，我打算把站点搬到甲骨文云的免费 ARM 实例上。
动手前以为这会很轻松——云控制台点几下，把旧系统盘挂到新机器，系统、网站、数据库不就都继承了。结果在第一步就卡住。这篇记录的就是这个卡点，以及为什么它在 x86 到 ARM 这条路上无解。
两台机器，两种 CPU
迁移涉及两台实例：
| 旧实例（已下线） | 新实例（免费套餐，现用） | |
|---|---|---|
| CPU | AMD，x86_64 | Ampere，ARM（aarch64） |
| 系统 | Ubuntu（x86_64） | Ubuntu 22.04（aarch64） |
| 系统盘 | 150G 引导卷 | 50G 引导卷 |
甲骨文"永久免费"套餐里最值得用的就是 Ampere ARM 实例：最多 4 核、24G 内存，个人站点绰绰有余。CPU 和内存是配比关系（合计 4 OCPU / 24G），可以拆成 1 核 6G、2 核 12G 等，按需选。
想走的捷径
最省事的思路，是把旧机器那块 150G 系统盘直接挂到新机器上启动。云平台上这个操作叫"替换引导卷"：关机、分离当前引导卷、把旧卷作为引导卷挂上、开机。
我已经把旧卷先当数据盘附加到新实例（Linux 里识别为第二块盘），打算确认下里面的内容再动手。
幸好先看了一眼。
一条 file 命令，问题就清楚了
挂载旧盘后，我对旧系统里最核心的 /bin/bash 做了次检查：
# 旧盘挂载在 /mnt/oldroot
file /mnt/oldroot/bin/bash
输出：
/mnt/oldroot/bin/bash: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV),
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2 ...
x86-64。旧盘里的程序全是给 x86 编译的。
再看新机器：
uname -m
# aarch64
到这儿，替换引导卷这条路就不用再想了。
为什么架构不同就没法用
x86 和 ARM 是两套不同的指令集。我们平时安装的软件，本质是源码编译成对应 CPU 能读懂的机器码。x86 编译出来的二进制，ARM 的 CPU 读不懂——不是兼容性问题，是两套语言。
Linux 可执行文件是 ELF 格式，文件头里写明了它面向哪种架构，file 读的就是这里。
于是旧盘的定位很明确：
当数据盘读、拷贝内容：可以。文件不挑架构，x86 盘里的文稿、图片、SQL、配置，ARM 机器一样能读；
当系统盘启动、跑里面的程序：不行。内核和第一个进程都是 x86 指令，机器根本起不来。
那正确的迁移方式是什么
系统和软件在 ARM 上重新装，只搬数据。旧卷继续挂着当数据盘，我逐项搬这些与架构无关的东西：
网站源码、用户上传的文件（PHP、图片、附件，脚本和数据不挑架构）；
数据库用
mysqldump导出成.sql再导入（这步坑不少，单独写了一篇）；SSL 证书、密钥（PEM 文本）；
Nginx 等配置文件（文本，复制后按新环境改路径）；
定时任务、部署的应用，在新系统重新配置。
跟架构绑定的——操作系统、编译好的二进制、系统库——一律用 apt 或面板在 ARM 上重装。
几个云盘操作命令
整个过程反复在"附加 → 挂载 → 拷贝 → 卸载 → 分离"，通用命令如下（设备名先 lsblk 确认）：
# 确认新挂上来的盘（如 /dev/sdb）
lsblk
# 挂载分区（假设数据在第2个分区）
sudo mount /dev/sdb2 /mnt/oldroot
# 拷贝数据 ...
# 用完卸载（先退出目录，确保没有进程占用）
sudo umount /mnt/oldroot
卸载后到控制台"分离（Detach）"。确认数据全部拷完、不再需要后，才"终止（Terminate）"——这步不可逆，务必先有备份。
写在最后
这次迁移给自己提了个醒：以后跨机器搬服务器，先跑一条 uname -m。
架构一致，克隆盘、做镜像都随意；架构不一致，就老老实实只搬数据，系统和软件重装。删旧卷前确认数据拷完、有备份，云盘终止找不回来。
数据库迁移、ARM 编译依赖、家宽端口这几个后续的坑，我也分别整理了，可以翻翻看。
