VeeamBackup&Replication12高级技巧使用veeam-recovery异机恢复SUSE Linux Enterprise Server 15 SLES15

VeeamBackup&Replication12高级技巧使用veeam-recovery异机恢复SUSE Linux Enterprise Server 15 SLES15

王忘杰
2025-11-20 / 0 评论 / 50 阅读 / 正在检测是否收录...

一、问题描述

某物理数据库服务器,使用SUSE Linux Enterprise Server 15 (SLES15)系统,具备系统盘和FC存储,数据库运行于FC存储中;
服务器整机通过Veeam备份,还原到虚拟机中进行测试时,由于磁盘路径变动,系统无法启动,经过多轮测试后成功启动系统
本文记录异机恢复后的系统修改过程

二、工具准备与流程

Veeam备份服务器信息
Veeam恢复镜像 veeam-recovery-amd64-6.0.0.iso
下载地址 https://repository.veeam.com/backup/linux/agent/veeam-recovery-media/x64/
SLES15安装镜像,具备救援模式 SLE-15-SP3-Full-x86_64-GM-Media1.iso

整体流程

配置虚拟机-使用Veeam恢复镜像还原系统,正确映射分区-启动SLES15救援模式,识别lvm,修改fstab,修改网络配置-启动系统-测试业务

三、恢复系统

1、创建虚拟机
mi6zqdfw.png
2、挂载并进入veeam-recovery恢复模式
mi6zvjrq.png
3、配置网络
配置网络调用的nmtui,配置为能够和veeam通信的IP即可
mi6zx3fj.png
4、进行恢复
mi6zywzy.png
从Veeam服务器恢复
mi6zz511.png
登陆服务器,选择要恢复的备份
mi6zzu63.png

5、映射磁盘
务必注意,先将5T磁盘映射为原447.1G系统盘,free剩余空间映射1.99T的LVM卷
此时lvm卷会显示为sda4(lvm),并下方显示VG和LV卷为/hana分区
mi702anb.png
6、进行恢复
按S 启动恢复即可 Start restore
数据量越大恢复越慢

四、启动救援模式

恢复完成启动系统后,会卡在启动项无法进入系统
mi70iiq8.png
挂载SLE-15-SP3-Full-x86_64-GM-Media1.iso,进入恢复模式
mi70jvk5.png
mi70k0ex.png

挂载系统进行修复
mi70ovom.png

查看当前磁盘情况

fdisk -l

mi70pwrz.png

挂载磁盘
mount /dev/sda3 /mnt/
mount /dev/sda1 /mnt/boot/efi
mount -o bind /dev /mnt/dev
mount -o bind /proc /mnt/proc
mount -o bind /sys /mnt/sys

进入chroot模式
chroot /mnt

挂载lvm卷
扫描pv
pvscan
扫描vg
vgscan
激活vg卷
vgchange -ay VG
扫描逻辑卷
lvscan

修复fstab为当前实际盘符
vi /etc/fstab 

禁用多路径服务
systemctl disable multipathd


重建initramfs
mkinitrd -f

配置网络
yast2
选择System-Network Settings
删除旧网卡,按Overview-DNS-Routing分别配置

注意:yast2很不好用是正常的,他不如nmtui操作简单

重启

mi70yito.png
mi70z976.png
mi7126p0.png
mi712v33.png
mi7163ru.png

五、连接测试

启动系统
mi716klj.png
桌面黑屏,但ssh连接正常
mi717ydd.png
mi71b0nx.png
数据库工具连接数据库测试正常
mi71cv86.png
恢复试验成功

六、一点小问题

虽然SSH和业务系统都已经正常了,但是进不去桌面,还需要进一步排查原因
桌面服务不影响系统和业务运行
mi6vc4b1.png

七、桌面显示问题解决了

AI分析解决的,是因为原机器是第三代志强可扩展,测试虚拟机是第一代志强可扩展,导致的软件不能启动,可以临时修改为softpipe启动。

根据提供的日志,我们可以看到gnome-shell不断崩溃并重启。日志中关键的错误信息包括:

"traps: llvmpipe-0[3913] trap invalid opcode ip:7f296830a80c sp:7f29deaff560 error:0"

"gnome-shell-x11.service: Main process exited, code=killed, status=4/ILL"

"JS WARNING: [resource:///org/gnome/shell/ui/layout.js 24]: reference to undefined property "MetaWindowX11""

其中,invalid opcode(非法指令)和ILL(非法指令信号)表明gnome-shell在尝试执行一个当前CPU不支持的指令。这通常是由于CPU微架构不兼容导致的,比如在迁移后新服务器的CPU与旧服务器不同,可能新CPU较老,不支持某些指令集(如SSE4.2、AVX等),而gnome-shell或其中的组件(如llvmpipe)是使用这些指令集编译的。

另外,llvmpipe是Mesa软件渲染器,它使用LLVM进行即时编译,可能会生成针对特定CPU的优化代码。如果迁移后的服务器CPU不支持这些指令,就会导致非法指令错误。

我们按照以下步骤操作:

通过SSH连接到服务器。

切换到root用户。

编辑/etc/environment,添加一行:
GALLIUM_DRIVER=softpipe

重启系统。

如果重启后图形界面能够正常启动,那么问题就解决了。

mi8gpibo.png

0

评论

博主关闭了所有页面的评论