1. 为什么 Veeam Backup 13 的安装值得单独写一篇
Veeam Backup 13 这个版本在数据保护圈子里讨论度一直不低，尤其是它把安装门槛和底层系统要求做了一轮调整之后，很多原来"下一步下一步就完事"的老手，反而在全新环境里翻了车。我最近在 RockyLinux 上完整走了一遍 Veeam Backup 13 的部署，从 UEFI 引导模式确认、系统依赖补齐、NTP 时间同步，到安装包校验和组件注册，中间踩了几个不大不小但很典型的坑。这篇就把整个过程拆开讲清楚，重点不是复述官方文档，而是把那些文档里一笔带过、实际却会卡住你的细节补上。
先说清楚这篇适合谁看。如果你手上有一台全新的物理机或者虚拟机，准备把 Veeam Backup 13 装上去做备份服务端，而且底层用的是 RockyLinux 这类企业级发行版，那这篇基本可以照着走。如果你只是想了解 Veeam 的备份策略怎么配、作业怎么排，那这篇偏安装侧，可能不是你要的。安装这件事看起来简单，但它决定了后面所有备份作业能不能稳定跑，尤其是时间同步和引导模式这两块，出问题往往是"装的时候没事，跑起来才炸"。
我这次的环境是一台 Dell 的机器，BIOS 里 UEFI 和 Legacy 两种模式都支持，硬盘是 NVMe，系统装的是 RockyLinux 9。整个安装过程我刻意没有用官方的一键脚本，而是手动一步步来，目的就是把每个环节的依赖关系摸清楚。下面按实际操作的顺序展开，中间会穿插我遇到的报错和排查思路。
2. 装之前必须确认的三件事：引导模式、系统版本、时间基准
2.1 UEFI 还是 Legacy，这个选择会一路影响到安装
很多人装系统的时候随手选了默认引导模式，等到装 Veeam 的时候才发现安装程序对分区表或者引导方式有隐含要求。Veeam Backup 13 本身对 UEFI 是明确支持的，但它的安装程序在检测引导环境时，如果发现是混合模式（比如 UEFI 引导但磁盘是 MBR 分区表），行为会不太一致。我的建议是：既然硬件支持 UEFI，就统一走 UEFI + GPT 这条路，别混着来。
怎么确认当前系统是不是 UEFI 引导？最直接的办法是看/sys/firmware/efi这个目录存不存在：
ls /sys/firmware/efi如果这个目录存在并且里面有内容，说明系统是 UEFI 模式启动的。如果提示"No such file or directory"，那就是 Legacy BIOS 模式。这个判断很关键，因为后面如果要做 PXE 网络启动批量部署，UEFI 和 Legacy 的引导文件完全不是一套东西，UEFI PXE 需要的是.efi引导程序，Legacy 用的是pxelinux.0那一套。
还有一个容易被忽略的点：Dell 这类品牌机的 BIOS 里，UEFI 模式有时候会带一个"Secure Boot"开关。Veeam 的安装组件里如果有内核模块需要加载，Secure Boot 开着可能会拦截未签名的模块。我这次是把 Secure Boot 关掉的，因为备份服务端通常不需要这个安全特性，关掉能省掉一堆签名验证的麻烦。当然如果你的合规要求必须开，那就得确认 Veeam 的模块有正规签名，这个要提前查清楚。
2.2 RockyLinux 的版本和仓库配置，决定了依赖能不能装齐
Veeam Backup 13 在 Linux 上的安装，对发行版版本是有要求的。RockyLinux 9 是没问题的，但如果你用的是 RockyLinux 8 或者更早的版本，部分依赖库的版本可能对不上。我这次用的是 RockyLinux 9.3，装之前先把系统更新到最新：
dnf update -y更新完之后，确认一下几个关键依赖在不在。Veeam 的安装程序会依赖一些基础的库，比如libaio、numactl、glibc这些。RockyLinux 默认的仓库里一般都有，但如果你之前精简过系统，可能缺。我习惯在装之前先手动确认一遍：
dnf install -y libaio numactl glibc tar gzip这里有个小坑：RockyLinux 的默认仓库有时候会因为镜像源的问题连不上，尤其是国内环境。如果你执行dnf install的时候报"不能连接"或者超时，先检查一下/etc/yum.repos.d/下面的仓库配置，把镜像源换成可用的。我遇到过yum -y install tree都连不上的情况，最后发现是默认的 mirrorlist 解析有问题，换成 baseurl 直连就好了。
另外，RockyLinux 上如果你之前配过 PHP + MySQL 那套环境，可能会引入一些第三方的仓库（比如 EPEL 或者 Remi），这些仓库里的库版本有时候会和 Veeam 需要的版本冲突。我的做法是装 Veeam 之前，先把不必要的第三方仓库临时禁用掉，装完再按需开回来。可以用dnf repolist看一下当前启用了哪些仓库，心里有个数。
2.3 NTP 时间同步：装的时候不弄好，跑起来全是玄学问题
这一条我要单独拎出来强调，因为它是 Veeam 安装和使用中最容易被低估的环节。Veeam 的很多功能依赖准确的时间戳：备份链的增量识别、作业调度、日志关联、和 vCenter 或者 Hyper-V 主机的通信认证，全都跟时间挂钩。如果服务端时间漂了，轻则作业调度不准，重则认证失败、备份链断裂。
RockyLinux 9 默认用的是chrony做时间同步，不是老的ntpd。先确认服务状态：
systemctl status chronyd如果没跑起来，启动并设置开机自启：
systemctl enable --now chronyd然后看当前的时间源：
chronyc sources -v输出里会列出配置的 NTP 服务器，前面带^*的那个就是当前正在同步的源。如果全是^?，说明一个都没连上。这时候要检查两件事：一是/etc/chrony.conf里配的服务器地址对不对，二是网络能不能通到那个 NTP 服务器。
关于 NTP 客户端要不要设置出入站规则，这是个高频问题。NTP 用的是 UDP 123 端口。客户端向服务器发起请求的时候，是客户端主动往外发，源端口是随机的，目的端口是 123。服务器回包的时候，目的端口是客户端那个随机源端口。所以严格来说，客户端这边出站方向要允许目的 UDP 123，入站方向要允许已建立连接的返回包。大多数防火墙的 stateful 规则会自动处理返回包，你只需要放行出站 UDP 123 就行。但如果你的环境防火墙策略比较严，入站方向也得显式放行，否则回包进不来，同步就会一直失败。
同步频率方面，chrony 默认会根据网络状况动态调整，网络好的时候可能几分钟就对一次，网络差的时候会拉长间隔。如果你想让它对得更勤一点，可以在配置里调minpoll和maxpoll，但一般没必要，默认值够用。我这次是直接指向了内网的一台时间服务器，同步延迟在毫秒级，很稳。
提示：装 Veeam 之前，务必确认
chronyc tracking里的 "System time" 偏移量在可接受范围内（一般小于 1 秒）。偏移太大的话，先手动强制同步一次：chronyc makestep。
3. 安装包获取与校验：别跳过这一步
3.1 从官方渠道拿包，版本号要对得上
Veeam Backup 13 的安装包，官方提供的是 ISO 镜像和单独的 Linux 安装包两种形式。如果你是在 Linux 上直接装服务端，用那个.run或者.tar.gz的安装包更直接。我这次用的是官方下载的 Linux 安装包，文件名里带了版本号和构建号，比如VeeamBackup_13.x.x.xxxx.tar.gz这种格式。
下载的时候有个细节：官方页面会根据你的账号权限显示不同的下载项，有些是试用版，有些是正式授权版。功能上安装过程没区别，但授权文件（license）要提前准备好，装完之后要导入。我建议下载的时候顺便把 license 文件也拿到手，省得装到一半再去找。
如果你是从内网的文件服务器拿包，一定要确认包的完整性。我遇到过从内网拷贝过来包损坏的情况，装到一半报解压错误，排查半天才发现是传输过程中出的问题。所以拿到包之后，先校验一下哈希值：
sha256sum VeeamBackup_13.x.x.xxxx.tar.gz把结果和官方提供的哈希值对一下，一致了再往下走。这一步花不了几秒钟，但能省掉后面一堆莫名其妙的报错。
3.2 解压和目录规划，别随手扔在 /tmp
拿到包之后，解压到一个固定的目录。我习惯放在/opt/veeam-install下面，方便后面找：
mkdir -p /opt/veeam-install tar -xzf VeeamBackup_13.x.x.xxxx.tar.gz -C /opt/veeam-install解压出来一般会有一个安装脚本和一个packages目录。安装脚本通常是.run结尾或者直接是个 shell 脚本。先别急着执行，看一眼脚本开头的注释，确认一下它支持的参数。Veeam 的安装脚本一般支持静默安装和交互式安装两种模式，交互式会一步步问你配置项，静默模式需要你提前准备好应答文件。
我这次用的是交互式安装，因为想看清楚每一步在做什么。如果你要批量部署，那就得研究静默模式的应答文件怎么写，这个后面可以单独展开。
注意：不要把安装包解压到
/tmp下面。有些系统的/tmp是挂载在 tmpfs 上的，重启就没了，而且空间可能不够。安装过程中如果临时文件写不下，会报一些很难懂的错。
4. 执行安装：交互式流程里的关键决策点
4.1 安装脚本启动后的第一轮检查
执行安装脚本：
cd /opt/veeam-install ./install.sh脚本启动后，第一件事是检查系统环境。它会检测发行版、内核版本、内存、磁盘空间这些。如果哪一项不满足，它会直接报错退出。我这次遇到过一个提示，说内存低于推荐值，但因为我这台机器是测试环境，内存给得不多，它只是警告没有退出。生产环境的话，建议按官方推荐配置来，内存和磁盘 IO 对备份性能影响很大。
第一轮检查通过之后，会进入组件选择界面。Veeam Backup 13 的 Linux 服务端安装，通常会让你选装哪些组件：核心备份服务、Mount 服务、Transport 服务这些。如果你只是单机做备份服务端，全选上就行。如果是要做分布式部署，比如把 Proxy 单独拆出去，那就要按角色来选。
我这次是全选，因为是一台机器搞定。选完之后，脚本会开始解压和安装各个组件，这个过程会持续几分钟，取决于磁盘速度。期间它会往系统里注册一些服务，比如veeamservice、veeamtransport这些。安装过程中如果看到某个服务启动失败，先别慌，记下服务名，装完之后单独排查。
4.2 安装过程中的依赖自动处理和手动补刀
Veeam 的安装脚本会尝试自动安装缺失的依赖。在 RockyLinux 上，它底层调用的还是dnf。如果自动安装失败，它会提示你手动装哪些包。我这次遇到一个情况：脚本自动装某个库的时候，因为仓库里版本不匹配，装了个旧版本，结果 Veeam 启动的时候报符号找不到。解决办法是手动指定版本重装：
dnf install -y <package-name>-<version>具体是哪个包，看安装日志里的报错。安装日志一般在/var/log/veeam/下面，或者脚本执行的时候直接输出到终端了。养成看日志的习惯，比瞎猜快得多。
还有一个点：Veeam 的某些组件依赖特定版本的内核头文件或者开发库。如果你之前为了编译别的软件装过kernel-devel，版本可能和当前运行的内核对不上。用uname -r看一下当前内核版本，然后确认kernel-devel的版本一致：
uname -r rpm -qa | grep kernel-devel不一致的话，装对应版本的kernel-devel。这个坑在需要编译内核模块的场景下特别常见，虽然 Veeam 不一定需要编译模块，但依赖链里如果有，就会卡住。
4.3 安装完成后的服务状态确认
安装脚本跑完之后，别急着关终端。先确认几个核心服务的状态：
systemctl status veeamservice systemctl status veeamtransport如果都是active (running)，那基本没问题。如果有failed的，用journalctl -u <服务名> -n 50看最近的日志，定位原因。我这次装完之后veeamtransport起不来，日志里报的是端口被占用。查了一下发现是之前装过别的备份软件，占用了同一个端口。把那个服务停掉，重新启动veeamtransport就好了。
端口占用这个问题在装 Veeam 之前最好先排查一遍。Veeam 用到的主要端口有 9392、9419 这些，用ss -tlnp看一下有没有被占：
ss -tlnp | grep -E '9392|9419'有输出的话，看是哪个进程占的，评估一下能不能停。如果是系统关键服务，那就得改 Veeam 的端口配置，这个在配置文件里能改，但稍微麻烦一点。
5. 装完之后必须做的几项验证
5.1 时间同步的最终确认
前面装之前确认过一次 NTP，装完之后要再确认一次。因为安装过程可能会改动系统配置，有时候会把 chrony 的配置覆盖掉。再跑一次：
chronyc tracking看 "Leap status" 是不是 "Normal"，"System time" 的偏移是不是在毫秒级。如果偏移又变大了，检查一下/etc/chrony.conf有没有被改。我这次装完之后发现 chrony 的配置被追加了一行指向本地时钟的配置，导致它不再同步外部源了。把那一行删掉，重启 chronyd 就恢复了。
5.2 引导模式和分区表的复核
装完之后再确认一次引导模式，确保没有被安装过程改动：
ls /sys/firmware/efi efibootmgrefibootmgr会列出当前的 UEFI 启动项。确认 Veeam 相关的启动项（如果有的话）或者系统启动项还在，顺序没乱。如果发现启动项丢了，用efibootmgr -c重新创建。这个在 UEFI 环境下装完东西之后偶尔会发生，尤其是安装程序动了 EFI 分区的时候。
5.3 用 Veeam 自带工具做一次连通性测试
Veeam 装完之后，一般会带一些命令行工具，可以用来测试和 vCenter、ESXi 主机或者 Hyper-V 的连通性。具体工具名看版本，一般在/opt/veeam/下面。跑一下测试，确认能连上你要备份的源端。连不上的话，排查方向主要是网络连通性、认证凭据、以及时间同步（又是它）。
我这次测试的时候，连 vCenter 一直报认证失败，但凭据确认没输错。最后发现是 vCenter 那边的时间和服务端差了将近 5 分钟，导致认证 token 直接失效。把两边时间对齐之后，一次就通了。所以时间同步这件事，真的是贯穿始终。
6. 几个我实际踩过的坑和对应的解法
6.1 安装脚本在 UEFI 环境下报分区相关错误
这个坑我在一台 UEFI 引导但 EFI 分区给得特别小的机器上遇到过。Veeam 安装的时候需要往 EFI 分区写点东西（具体是什么因版本而异），分区太小写不下就报错。解决办法是重建 EFI 分区，给足空间，一般 512MB 起步，我习惯给 1GB。重建分区意味着要重装系统或者至少调整分区表，所以最好在装系统的时候就规划好。
6.2 RockyLinux 上 SELinux 拦截了 Veeam 的某个操作
RockyLinux 默认开 SELinux， enforcing 模式。Veeam 的某些操作会被 SELinux 拦，日志里能看到avc: denied的记录。临时排查可以把 SELinux 设成 permissive：
setenforce 0确认是 SELinux 的问题之后，正确的做法是写一条 SELinux 策略放行，而不是一直关着。用ausearch和audit2allow可以生成策略模块：
ausearch -m avc -ts recent | audit2allow -M veeam_policy semodule -i veeam_policy.pp这样既解决了问题，又没有降低系统整体安全性。
6.3 安装过程中网络中断导致组件注册失败
Veeam 安装的时候有些步骤需要联网校验或者下载额外的组件。如果网络中途断了，组件注册会失败，但安装脚本可能不会明确报错，而是继续往下走，最后装完发现功能不全。我的建议是安装过程中保持网络稳定，如果环境网络不稳，提前把需要的包都下载到本地，用离线模式装。装完之后用veeamconfig之类的工具检查一下组件注册状态，缺啥补啥。
6.4 关于 NTP 客户端出入站规则的再补充
前面提过 NTP 的端口问题，这里再展开一点。如果你的 RockyLinux 开了firewalld，默认的 public zone 是不放行 NTP 的。你需要显式放行：
firewall-cmd --permanent --add-service=ntp firewall-cmd --reload这样出站和相关的返回包就都通了。如果你用的是 iptables 自己写的规则，那就得手动加：
iptables -A OUTPUT -p udp --dport 123 -j ACCEPT iptables -A INPUT -p udp --sport 123 -m state --state ESTABLISHED -j ACCEPT第二条就是处理返回包的。很多人只加了第一条，发现同步不了，就是因为返回包被挡了。这个细节在文档里经常被忽略，但实际排查的时候特别关键。
7. 装好只是开始：后续维护里时间同步依然是重点
Veeam Backup 13 装完之后，日常维护里最需要盯的还是时间同步。我自己的做法是在监控系统里加一条对 chrony 偏移量的告警，超过阈值就通知。因为时间这个问题，平时不显山不露水，一旦出问题就是连锁反应。备份作业失败、复制任务中断、和源端认证失败，追到根上经常就是时间漂了。
另外，RockyLinux 的系统更新有时候会顺带更新 chrony 或者改动配置，每次更新完之后最好确认一下时间同步还正常。我一般会在更新脚本里加一句chronyc tracking的输出检查，花不了几秒钟，但能提前发现隐患。
至于 Veeam 本身的版本更新，13 这个版本后续应该会有小版本迭代。更新之前建议先看 release notes，确认有没有对底层系统要求的变动。尤其是 UEFI 和内核版本相关的改动，有时候小版本更新会悄悄提高要求，不提前看的话，更新完服务起不来就尴尬了。
最后说一个我个人的习惯：每次装完这类基础服务，我都会把整个安装过程的关键命令和配置记在一个 markdown 文件里，放在/root/notes/下面。下次再装，或者同事要装，直接照着走，省得重新踩一遍坑。这个习惯看起来笨，但实际省下来的时间远超记录的成本。
