1. 异机恢复不是“文件拷回去”先搞清楚VBR12在做什么1.1 VBR12里的异机恢复到底怎么工作先用大白话讲清楚“异机恢复”的本质它不是把备份里的文件一个个复制到新机器上而是把整个操作系统“连同分区、引导、驱动环境”一起还原到另一台硬件上目标是开机就能进系统。VBR12在做这件事时会先读取备份映像里的完整磁盘数据把每个分区展开到目标磁盘然后在恢复过程的末尾尝试重建启动加载器、修正系统配置让新硬件能识别到这套系统。问题在于Windows有相对统一的驱动抽象层恢复时VBR可以比较从容地做“硬件重新配置”。Linux的情况就复杂一些了内核本身不带完整的硬件驱动驱动要么编进内核要么以内核模块的形式放在initramfs里。你从备份里把根文件系统展开到新机器的磁盘上但initramfs里装的是原机的模块集合新机器的网卡、磁盘控制器一变化系统启动时就会卡住或者直接内核panic。VBR12专门为Linux场景准备了一个恢复环境也就是启动ISO后进入的那个轻量级Linux救援系统它里面有一个核心命令行工具veeam-recovery。整个异机恢复过程就是围绕这个工具展开的。这个设计逻辑很合理先在独立的救援环境里把新硬件设备识别好、网络配好、备份仓库挂载好再把备份映像写到目标磁盘最后引导修复交给救援环境里的工具链去处理。作为使用方你不需要理解底层block级读取的细节但以下几个关键点必须先想明白不然后面会很难排查。第一恢复的目标不是得到“一样的硬盘”而是得到“能在这台新机器上正常启动的系统”。第二VBR12在执行Linux异机恢复时不会像Windows那样替你装一堆厂商驱动新硬件的驱动支持主要靠目标机器的恢复环境去发现以及恢复后重新生成initramfs。第三备份点是时间胶囊恢复出来的系统和原系统一模一样包括原机的hostname、网卡配置、订阅注册状态、分区UUID引用这些内容在新机器上未必适用恢复后大概率需要手动修正。1.2 为什么SLES15需要额外关注SUSE Linux Enterprise Server 15这套系统和CentOS、Ubuntu有一个明显的区别它把btrfs作为默认根文件系统并且默认使用一套复杂的子卷布局配合GRUB2引导。btrfs本身不复杂但子卷UUID硬件的组合会让异机恢复后的修复工作增加不少变数。举个例子原机的/etc/fstab里通常用UUID来引用根分区和/home分区之类的挂载项。备份恢复出来的分区是全新的磁盘的PARTUUID和文件系统UUID都不再是原来的值。如果VBR12的恢复过程没有自动修正fstab系统就会在启动时尝试挂载一个不存在的UUID然后进入emergency mode或者卡在启动阶段。这类问题在SLES15上尤其常见因为默认btrfs根分区是带子卷的子卷的挂载逻辑检查起来比ext4更绕。所以做SLES15异机恢复之前我强烈建议先把下面这几类信息记录下来后面每一项都用得上原机的分区布局和文件系统类型、子卷清单、网络配置文件、GRUB引导方式BIOS还是UEFI、内核模块情况。这些信息看起来简单但实际排障时绝大多数“恢复后起不来”的问题都出在这些细节上。1.3 原机恢复、异机恢复、迁移到虚拟机别选错场景VBR12里“恢复到新位置”其实有好几个入口很多人第一步就选错了。我见过不少同事在向导里点了“恢复到虚拟机”结果只是把物理机的备份导入成了一个VMware虚拟机模板并没有处理物理硬件差异。要避免这些坑先分清几个概念的边界。场景恢复方式适用情况主要风险原机恢复Bare Metal Restore到原机硬盘损坏、系统崩溃硬件没变几乎没有硬件适配问题异机恢复恢复到不同的物理机/硬件原机报废、硬件升级、灾备切换驱动、UUID、网络配置差异恢复为虚拟机Restore to VM物理机迁移到虚拟化平台需要迁移后装载虚拟化驱动适配对SLES15来说如果目标硬件和原机差异很大比如原机是HP Gen10服务器新机器是Dell PowerEdge磁盘控制器从Smart Array换成了PERC网卡型号也变了那么“恢复成虚拟机”这种路线就不合适。正确做法是走VBR12的Linux裸机恢复流程也就是上面提到的veeam-recovery环境。后面的章节我会按步骤把整个流程拆开讲。2. 动手之前先摸清SLES15的几个关键细节2.1 btrfs子卷布局与fstab的精妙之处SLES15安装系统时如果不手动干预默认是btrfs文件系统并且根分区会创建一组子卷。典型的布局类似下面这样# btrfs subvolume list / ID 256 gen 2238 top level 5 path ID 257 gen 2238 top level 5 path /boot/grub2/x86_64 ID 258 gen 2238 top level 5 path /home ID 259 gen 2238 top level 5 path /opt ID 260 gen 2238 top level 5 path /srv ID 261 gen 2238 top level 5 path /tmp ID 262 gen 2238 top level 5 path /usr/local ID 263 gen 2238 top level 5 path /var这种布局的目的是把根文件系统的各个目录拆成独立子卷方便快照和回滚。你看到根子卷挂载到//home挂载到/home/var挂载到/var都是通过/etc/fstab完成的。而fstab里引用的是UUID不是设备名。也就是说btrfs卷的UUID一旦变化fstab里的挂载就会失效。异机恢复之后恢复环境或VBR12如果按原样把分区展开到新磁盘文件系统的UUID从原理上讲是保持原值的因为它是文件系统内部元数据的一部分不是硬件决定。但这里有个实际情况需要注意你恢复到的磁盘大小、分区工具的重新计算、以及恢复过程中创建的新分区表都可能导致/boot/grub2/x86_64、EFI分区或者交换分区的UUID发生变化。此外如果恢复时的分区顺序和原机不一样设备名会变这类问题也非常常见。我建议恢复完成后第一件事就是用blkid把所有分区的UUID列出来和原机记录对比把fstab里明显对不上的条目修成当前值。千万不要先重启再排查在救援环境里改好fstab比启动失败后摸索快得多。2.2 网卡命名与wicked/NetworkManagerSLES15的网络配置和RHEL系不太一样。它默认使用wicked配置文件放在/etc/sysconfig/network/每个网卡对应一个ifcfg-xxx文件例如ifcfg-eth0、ifcfg-enp3s0。文件名和网卡名绑定而网卡名又是内核根据总线位置、PCI槽号生成的。换机器之后网卡名称基本一定会变比如原来叫eth0新机器上可能变成enp3s0。如果ifcfg-eth0这个文件存在但新机器上根本没有叫eth0的网卡wicked启动时就会跳过这个配置文件结果就是网络完全没起来而你明明已经配好了IP。解决思路有两条第一在恢复后把原来的ifcfg文件重命名成和当前网卡名一致然后修改配置内容第二用udev规则把新网卡的MAC地址固定成某个名称再让ifcfg文件使用这个名称。我建议简单场景直接走第一条路修改ifcfg-enp3s0里的NAME、BOOTPROTO、IPADDR这些字段即可。值得注意的是SLES15.3之后系统支持NetworkManager作为可选网络管理方式。如果原来跑的是NetworkManager恢复后的处理逻辑会不同NetworkManager本身对硬件变化的适应能力比wicked强一些但还是建议检查一下连接的配置和设备的MAC绑定避免出现“网络管理服务正常但连接不上”的尴尬情况。2.3 GRUB2引导体系与UEFI的坑SLES15的引导加载器是GRUB2配置文件在/boot/grub2/grub.cfg生成方式是运行grub2-mkconfig。如果你不熟悉SUSE的引导体系最容易出问题的地方在于这台机器到底是BIOS引导还是UEFI引导以及/boot/grub2/x86_64是不是单独的btrfs子卷。绝大多数现代服务器默认是UEFI模式。如果原机是UEFI引导恢复环境在异机恢复后应确保ESP分区EFI System Partition通常是vfat文件系统存在且已安装grub2的EFI版本。如果目标机器仍然开启UEFI但EFI分区没有被恢复环境正确挂载GRUB2就不会被装进去。启动时会直接卡在固件界面连引导菜单都进不去。如果出现引导问题我的习惯是在veeam-recovery环境里手动修复。首先确认当前启动方式是UEFI还是BIOS然后用chroot进入恢复后的根文件系统运行grub2-install和grub2-mkconfig重新生成配置。只要分区和fstab没有问题GRUB修复本身并不复杂。真正的难点在于判断该往哪里装装到哪个磁盘的哪一段这些需要结合lsblk和efibootmgr去确认。2.4 SLESConnect订阅注册状态容易被忽略这个点很多文档不会提但实际影响挺大。SLES15系统在安装后会通过SUSEConnect与SUSE Customer Center建立注册关系注册状态和系统的patch来源、仓库地址绑定。异机恢复以后系统还是原来的系统注册关系却会变成无效状态因为硬件的指纹变了。如果不处理系统启动和基本功能没有问题但yast、zypper检查更新时会报错或者提示注册码失效。正确的处理方式是在恢复后的系统里执行SUSEConnect -r清理旧的注册信息然后重新注册。如果你们公司用的是SUSE Manager统一管理也需要在Manager里把新机器的条目重新理清楚。这个细节虽然不影响开机但很影响后续使用建议恢复后顺手处理掉。3. 实操记录用veeam-recovery完成SLES15异机恢复3.1 恢复前的信息收集与规划这一步做得越充分恢复过程越顺。我用一个表格列一下我每次恢复前都会记录的信息。需记录信息获取命令用途磁盘布局和分区大小lsblk -f / df -h规划目标磁盘大小和恢复方式文件系统类型与UUIDblkid恢复后修正fstab的参照btrfs子卷列表btrfs subvolume list /确认恢复后的子卷路径网卡配置内容cat /etc/sysconfig/network/ifcfg-*恢复后重建网络配置引导模式efibootmgr / ls /sys/firmware/efi判断UEFI还是BIOS恢复内核模块列表lsmod预判新硬件驱动是否足够另外恢复前先把备份点确认好确认VBR12里这个SLES15服务器的备份作业已经成功完成最新的恢复点时间是你想要的数据状态。如果备份是带应用感知处理的一致性会更好异机恢复后出问题的概率更低。目标服务器的硬件情况也要提前确认尤其是磁盘控制器和网卡型号。如果在restore过程中发现内核没有识别到目标磁盘后面的流程根本没法继续这时候需要看看恢复环境里能否加载额外的驱动模块。3.2 启动恢复环境并进入veeam-recoveryVBR12的Linux恢复媒体从哪来常见做法是使用VBR安装目录里的恢复ISO或者在VBR控制台启动恢复流程时向导会自动提供恢复环境。你可以把它做成启动U盘也可以直接在虚拟光驱里挂载。物理机恢复的话我一般用U盘启动。启动后你会看到Veeam的Linux恢复环境界面稍等片刻会进入一个shell提示符这就是veeam-recovery环境。需要注意这个环境带了基本的硬件识别和网络工具但它不是你最终的系统只是一个救援平台。进入之后先确认硬件情况比如用lspci查看磁盘控制器、用lsblk查看磁盘设备是否已经识别到。如果目标磁盘都看不到就要考虑加载厂商的驱动模块这一步必不可少也经常有人忽略。# 查看PCI设备确认磁盘控制器和网卡是否被识别 lspci | grep -E RAID|SATA|Ethernet # 查看块设备 lsblk如果磁盘控制器未识别尝试用modprobe加载对应模块。模块来自恢复环境的initramfs也可以通过驱动U盘加载。不同厂商的加载方式略有差异但思路是先确认硬件ID被识别再谈后续恢复。3.3 在恢复环境里配置临时网络并连接备份仓库异机恢复过程中最关键的一步是让恢复环境能够访问到备份数据。备份数据如果存放在VBR服务器管理下的备份仓库中就需要恢复环境能和VBR服务器通信如果备份数据在共享目录里则需要把共享目录挂载到恢复环境。以VBR服务器的场景为例恢复环境需要先配一个和VBR服务器同一网段的IP。veeam-recovery里的网络配置命令大致是这样的形式# 查看当前网络状态 veeam-recovery net # 配置临时IP具体参数以--help里为准 veeam-recovery net set -n eth0 -ip 192.168.100.15 -mask 255.255.255.0 -gw 192.168.100.1配置完成后用ping测试VBR服务器的连通性。确保能通信后再通过veeam-recovery把备份仓库挂载进来类似下面的流程# 添加VBR服务器让它能发现备份 veeam-recovery vbr add -s 192.168.100.10 -u administrator -p password # 查看发现的备份 veeam-recovery backup list如果你是直接把备份文件放到NFS/SMB共享里用的也可以走共享挂载的路径。总之只要veeam-recovery backup list里能看到那个SLES15的备份点就可以进入下一步。这一步遇到最多的问题是网络不通所以临时网络配置务必先确认。另外备份仓库如果是VBR的服务器端恢复环境还需要能解析主机名或者直接用IP。我实际踩过一次坑VBR服务器是Windows主机防火墙把SMB和VBR端口都拦了导致恢复环境连不上仓库。后来先在VBR服务器的防火墙里放行对应端口恢复才顺利跑起来。3.4 执行异机恢复关键参数和磁盘规划备份点可见后执行恢复的核心命令是veeam-recovery restore。这个命令会进入一个交互式流程让你选择备份点、恢复点和目标磁盘。大概的长相可以参考veeam-recovery restore -b SLES15-Backup.Job -o /dev/sdb执行之后恢复环境会读取备份元数据展示原机的分区结构并让你决定目标磁盘。这里有几个选择非常影响后续结果第一恢复时可以指定把原系统恢复到哪个磁盘上目标磁盘可以是全新的空盘也可以是带有旧系统的盘。如果你没有做好规划选错了目标盘会把现有数据覆盖掉。我的习惯是先在生产环境外挑一个空盘确保lsblk里只看到目标盘和恢复环境用的临时盘。第二恢复时可以选择是否自动调整分区大小。如果目标磁盘比原机大可以让恢复过程自动扩展分区如果目标磁盘比原机小恢复会直接报错这时只能换更大的盘或者手动调整原机的分区布局。在确认目标磁盘和恢复方式之后VBR12会开始全量写入。恢复速度取决于备份所在仓库的读取性能、网络带宽和目标磁盘的写入速度。以我这次SLES15的恢复为例原机磁盘大概是300GB实际使用60GB恢复到同一数据中心内网环境大约花了二十多分钟。恢复过程结束后veeam-recovery会提示你完成此时先不要急着重启我还建议在恢复环境中先对写入的磁盘做一次基本检查确认分区表和文件系统挂载正常这比启动失败后回到救援环境更高效。3.5 重启、首轮引导与系统初始化恢复完成后重启机器并移除恢复媒体。如果一切顺利系统会直接进入GRUB菜单并启动。但以我做异机恢复的经验来看SLES15在首次启动时大概率会出一点小问题最常见的表现是卡在等待设备挂载或者直接落到emergency mode。首次引导之前我强烈建议在恢复环境里先把以下三件事处理好能避免掉大部分启动问题第一更新/etc/fstab里的UUID。用blkid查询恢复后的分区UUID和fstab逐行比对把不对的改成当前值。第二检查网卡配置文件当前的接口名和ifcfg文件是否对得上对不上就先改配置或者用udev规则固定。第三确认initramfs里的模块覆盖情况如果你预判新硬件的磁盘控制器和原机不一样就在恢复环境里挂载根分区后重新生成initramfs。这三件事虽然可以在启动失败之后再补救但提前处理的话首轮引导会平滑很多。尤其是fstab绝大多数SLES15异机恢复后起不来的案例根源都是fstab里的UUID引用失效。4. 常见问题与排查技巧实录4.1 启动卡在“waiting for device”或直接进入emergency mode这是最常见的启动失败现象原因九成是/etc/fstab里引用的UUID与恢复后的分区UUID不一致。系统在启动早期阶段要挂载根分区但按fstab里的UUID找不到设备于是进入紧急模式。排查方法是重新用恢复媒体启动进入veeam-recovery环境把根分区挂载到一个临时目录然后执行blkid查看当前分区UUID再修改fstab。注意btrfs根分区需要挂载对应的子卷挂载命令类似mount -o subvol /dev/sdb2 /mnt修改完fstab之后顺手把其他引用旧UUID的配置也检查一遍包括/etc/default/grub或引导相关参数。确认无误后重启。如果fstab看不出问题那就要考虑initramfs里缺少新硬件驱动或者引导参数指定了错误的root设备。4.2 网卡接口名变化导致网络服务起不来恢复后的系统里原来的eth0可能变成了enp3s0。网络服务起来时会寻找名为eth0的接口但找不到于是网络配置完全失效。检查方法很简单进系统后执行ip addr看当前接口名再看/etc/sysconfig/network/里的ifcfg文件。修复方式不复杂把ifcfg-eth0改名为ifcfg-enp3s0并把里面的设备名改成新接口名。如果你希望接口名固定不漂移可以结合udev规则把新网卡的MAC地址和名称绑定。还有一种情况是原机用NetworkManager而目标机的网卡固件不同NetworkManager配置里面存的是原机的连接恢复后要检查nmcli connection show。这部分属于配置经验多花十分钟能省下后面几小时的排障时间。4.3 GRUB引导失败找不到内核或停留在GRUB shell如果开机直接进入GRUB命令行说明引导配置没有正确写入。多数原因是恢复过程没有按目标机的引导模式生成引导加载器或者EFI分区没有被识别到。排查时先确认目标机是UEFI还是BIOS引导再进入恢复环境做引导修复。UEFI引导的修复流程大致是挂载根分区和EFI分区chroot进去然后运行grub2-install --targetx86_64-efi和grub2-mkconfig -o /boot/grub2/grub.cfg。BIOS引导则对应grub2-install /dev/sdX。这个环节最容易忽略的是chroot之前要把/proc、/sys、/dev挂载好否则grub2-mkconfig会读取不到系统状态。实际操作时这几个虚拟文件系统没挂载是导致命令报错的常见原因。4.4 内核恐慌或提示找不到root设备恢复后的系统如果启动时提示类似“VFS: Unable to mount root fs”或“no root device found”一般有两个原因一是内核参数里的root指向了不存在的设备或UUID二是initramfs里缺少对应文件系统的驱动模块。比如新机器是NVMe磁盘原来的initramfs里没有nvme驱动系统就挂载不了根分区。解决办法是在恢复环境里挂载根分区chroot进去后运行mkinitrd重新生成initramfs。SLES15的生成命令是mkinitrd它会自动探测当前可见的硬件设备并加入对应模块。生成完毕后确认grub.cfg里的root设备参数无误再重启。4.5 快速排查清单症状优先检查修复动作进emergency mode/etc/fstab的UUIDblkid对比并修正UUID网络起不来ifcfg文件名和接口名重命名/修改ifcfg、检查NetworkManagerGRUB shell引导模式、EFI分区chroot修复GRUB2root device not foundinitramfs模块、内核参数mkinitrd重建initramfs网络Ping不通仓库防火墙、IP配置放行VBR端口、重新配置IP另一个很容易被忽略的环节是恢复后的SUSEConnect注册状态建议恢复完成后顺手执行SUSEConnect --status查看。如果显示未注册先SUSEConnect -r清理再根据机构订阅信息重新注册。否则后续打补丁、加扩展包时zypper会一直报错排查半天才发现是注册问题非常耽误时间。我个人在每次做Linux整机异机恢复前都会坚持先把原机的/etc/fstab、/etc/sysconfig/network、分区表和内核模块列表打印出来留底。这步操作虽然不起眼却能省下大量排障时间尤其是当你需要对比新旧机器的配置差异时留底文件就是最好的参照物。做完恢复后也先别急着从恢复环境里退出来把根分区挂载好、检查一次关键文件确认fstab里的UUID都已更新再重启。这个习惯帮我避免过好几次白跑一趟。异机恢复这件事本质上就是把“原机的样子”搬到“新机器的壳”里多花十分钟做检查和留底比靠运气引导成功可靠得多。
