简介：这是一份 DELL NetWorker 18.2.0.1 的安装部署指南，面向负责备份系统落地与日常运维的工程师，也适合刚接触该产品的初学者。文档没有简单罗列命令，而是从服务端、客户端、前置条件三个层面展开：先说明磁盘空间、网络通信和 Java 运行环境要求，再详细讲解备份服务器安装、防火墙端口放通、域名解析及主机映射文件修改，最后覆盖 Windows 与 Linux 客户端的安装配置。整包只有 1 个 docx 文档，压缩包大小 12.25MB；目录按引言、概述、服务端安装、客户端安装等模块组织，正文以完整文字说明逐步展开。文档正文篇幅较长，步骤拆解细致，可按章节快速定位。目前已有 1257 人学习下载，适合作为入门与实施参考资料；对照自动保护策略说明，可完成备份服务器初始化配置，减少部署中的常见踩坑。

1. NetWorker 18.2.0.1 安装指南：先想清楚它装在哪、给谁用

这个标题里的 NetWorker 18.2.0.1 安装指南，看起来只是一份 docx，但真拿到手你会发现，最贵的时间都花在装完之后。NetWorker 是企业级备份软件，负责给数据库、文件系统、虚拟机做统一备份，和普通桌面备份工具完全不是一个思路。本文讲的安装，是指把备份服务器、客户端、存储节点装到 Linux 服务器上，并跑到能出第一个备份任务为止。我习惯先泼盆冷水：如果你在自己电脑上装个客户端就想跑通，大概率卡在主机名解析和防火墙端口上，不是安装包的问题。这篇适合谁？接手备份系统的新运维、准备从老版本升级的人、以及第一次在公司机房里部署 NetWorker 的工程师。你会看到完整的准备清单、安装命令、参数说明和几个让我翻过车的坑。

2. 安装前准备：版本兼容性、网络端口与系统账号

2.1 用前先对照：操作系统版本、内核参数与依赖包

NetWorker 18.2.0.1 这种企业级软件，对操作系统版本、内核和 glibc 有明确要求。装前我一般先不做任何解压，直接在目标服务器上开三个命令：

cat /etc/os-release uname -r getconf GNU_LIBC_VERSION

第一条看发行版名称和主版本，第二条看内核，第三条看 glibc 版本。NetWorker 服务端比客户端更挑剔，如果发行版版本太老或内核太新，安装脚本会在预检阶段直接拒绝，报错信息通常很含糊，只说“不符合安装条件”。这时候别去折腾安装包，先换一台符合要求的系统。

除了版本，还要检查主机名。NetWorker 对主机名解析极其敏感，服务端主机名必须能正向解析成 IP，而且最好是全限定域名（FQDN）而不是短名。我见过最多的问题就是/etc/hosts里把主机名解析成了127.0.1.1，结果服务端启动时绑定地址出错，客户端也找不到服务器。建议在安装前就把 hosts 写好，例如：

192.0.2.10 backupserver.backup.lan backupserver

写完用getent hosts backupserver.backup.lan验证。这一步看起来简单，但能挡掉后续 80% 的“起不来”问题。参数说明：第一列是服务端 IP，第二列是完整域名，第三列是短名，三者必须能互相解析，缺一个后面都会出幺蛾子。

2.2 网络与防火墙：把 7937 端口段在安装前留好

NetWorker 服务端、客户端和存储节点之间的通信有固定端口段。默认情况下，服务端会监听 7937 到 7945 区间，具体端口取决于服务和数据通道类型。客户端主动连服务端时，也会用这一段。很多新手在安装时没先开防火墙，装完才发现nsrd起不来，或者起来后客户端注册不上。

我一般会在安装前先把端口占用情况摸清楚：

ss -tunlp | grep -E '793[7-9]|794[0-5]' firewall-cmd --list-all

firewall-cmd --list-all是给用 firewalld 的系统看的；如果你用的是 ufw 或者其他防火墙，就用对应的查询命令。关键不是看当前有没有端口在监听，而是确定这些端口没有被其他进程占用，并且防火墙规则允许 TCP 和 UDP 同时通过。NetWorker 有些探测和数据包走 UDP，只放行 TCP 会留下隐患。

如果防火墙开着，我会把端口段放行，并在规则里注明用途。例如 firewalld 下：

firewall-cmd --permanent --add-port=7937-7945/tcp firewall-cmd --permanent --add-port=7937-7945/udp firewall-cmd --reload

参数说明：--permanent表示写入持久化配置，重启不丢；--reload让规则立即生效。这里不要只放行服务器本机端口，客户端和存储节点之间的通信同样要走这一段。如果环境里有网络隔离策略，记得把备份网段的进出规则一起提给网络管理员，否则运行期会反复出问题。

3. 从解压到装完：NetWorker 18.2.0.1 服务端、客户端与存储节点

3.1 解压安装包：校验哈希与预检环境

拿到 NetWorker 18.2.0.1 的安装包后，我先不急着解压。企业备份软件安装包体积不小，传输过程容易损坏，损坏后的安装脚本会报各种奇怪错误。所以第一步是校验哈希。常见做法是：

sha256sum NetWorker_18.2.0.1_linux.tar.gz

把输出的哈希值和下载页面提供的值对比。当然，如果没有官方校验值，这一步可以跳过，但我不建议省。解压命令很简单：

tar -xzf NetWorker_18.2.0.1_linux.tar.gz cd NetWorker_18.2.0.1_linux

解压后先别执行安装脚本，用df -h .看看当前目录所在分区剩余空间能否满足安装要求。NetWorker 服务端安装后，除了软件本体，还有资源数据库和日志目录，建议预留 20GB 以上。如果/opt和/nsr在不同分区，还要分别检查。

另外，安装脚本通常会检测服务器上的用户。NetWorker 会创建nsr系统账号，如果之前残留过旧版本的同名账号，可能会导致安装时权限目录归属混乱。我一般会查看一下：

id nsr

如果提示用户不存在，那没问题；如果存在，就要确认它是不是旧版本留下的。旧版本残留的用户和组，最好在卸载旧版本时清理干净，否则新版本安装脚本可能跳过创建用户步骤，最后服务以错误权限运行。

3.2 服务端安装：用交互脚本和选项文件两种方式

NetWorker 服务端安装没有什么花哨的图形界面，最常见做法是执行安装脚本进入交互式菜单。进入解压目录后，直接运行：

./install

脚本会依次询问安装类型、安装目录、是否创建桌面图标等。对于纯服务端，选择安装 Server 对应的选项。交互过程会打印服务端需要的磁盘空间、依赖包检查结果。这里有个细节，安装脚本的输出里如果出现WARNING而不是ERROR，很多人会直接回车，但我建议停下来把 WARNING 逐条看一遍。比如“找不到 gnutls 开发库”这种警告，虽然不影响服务端本体安装，会在后续配置 TLS 加密备份通道时变成硬错误。

如果需要在多台服务器上安装，或者要纳入自动化，我会用选项文件方式。NetWorker 安装脚本支持预先写好应答文件，常见做法是这样的：

./install -options /opt/install_kickstart.txt

选项文件里的内容长什么样并不复杂，就是键值对，比如安装类型、安装目录、用户归属。使用-options的好处是，脚本不会停下来等你按回车，日志可以直接重定向到文件。参数说明：-options参数后面必须跟一个绝对路径，而且文件中写的安装目录必须有写权限。

安装完成后，服务端的主进程是nsrd，管理服务是nsrexecd。我习惯先执行：

systemctl status nsrd nsrexecd

看两个服务是不是active (running)。如果nsrd没起来，先别反复重启，去日志目录找原因。NetWorker 服务端的日志通常写入安装目录下的nsr/logs或/nsr/logs，用tail -n 100看最近的报错，远比在系统日志里瞎找直接。

3.3 客户端与存储节点：最小化安装和连接参数

客户端和存储节点不一定要在服务端同一台机器上。实际部署里，客户端装在需要备份的业务服务器上，存储节点（Storage Node）装在挂载磁带库或大容量磁盘阵列的服务器上。安装方式类似，但重点是连接参数。

在业务服务器上，客户端安装用同一个安装包，执行：

./install -client

脚本会询问服务端主机名，这里要填服务端的完整域名，而不是短名。如果你填错了，之后改会比较麻烦。客户端安装后，会启动nsrexecd服务，它是用来接收服务端调度和认证的。验证客户端是否正常，可以运行：

nsrexecd -version

如果能看到版本号，说明二进制可执行；但能不能和服务端通信，还要看端口。我一般会在客户端上执行：

nsrports -s backupserver.backup.lan -C 7937

这是一个连通性检查命令，-s指定服务端，-C指定端口。能得到 “connected” 之类的反馈，说明网络层面没问题。参数说明：7937是 NetWorker 默认的连接端口，如果环境里改过端口，这里要改成实际端口。

存储节点的安装，通常会多一步“指向服务端并把存储节点加入资源数据库”。安装脚本会要求输入服务端主机名和存储节点首次通信的认证字符串。认证字符串就像临时密码，服务端会用它来登记这个存储节点。安装后，需要去服务端确认节点列表里能看见它。

4. 初始化与备份策略：让安装好的 NetWorker 真正跑起来

4.1 初始库配置：注册授权并设置默认备份客户端

服务端装完只是第一步，真正能干活儿还需要初始化资源数据库。NetWorker 把客户端、磁盘池、策略、备份任务都记录在资源数据库里，这个库由服务端进程统一管理。我一般会先启动服务，然后检查服务端状态：

nsr_server -s backupserver.backup.lan

如果服务已经由 systemd 启动，这条命令通常不会做太多事，但它能让你确认服务端名字是否和 hosts 一致。接着要注册授权码，否则备份任务跑到一半会因为授权不足被取消。NetWorker 的授权命令很直接：

nsrlicense -a A1B2-C3D4-E5F6-G7H8

参数说明：-a表示添加授权码，后面是授权字符串。授权码来自购买的许可文件，注意区分评估版和正式版。企业里经常有多个授权码分属不同模块，比如容量许可和客户端数量许可，都要一次加进去。

接下来是设置默认备份客户端。所谓默认，就是把 NetWorker 服务端当成一台客户端也可以备份自己。这不影响业务，但能帮你验证环境是否正常。常见做法是在服务端上把本机主机名加进客户端资源：

nsrclient -s backupserver.backup.lan -a backupserver.backup.lan

命令中的-a是添加动作。这时候可以做一个手动备份测试，看服务端能否备份它自己的配置目录。能成功，说明服务端、客户端、授权、网络链路全通了。

4.2 第一个备份策略：从客户端组到保留策略

跑通单点备份后，才开始建正式的备份策略。NetWorker 的策略模型是“客户端组 + 备份策略 + 保留时间”。我会把逻辑一样的业务服务器放进同一个客户端组，再给这个组配一套备份策略。

创建客户端组的常见做法：

nsrgroup -s backupserver.backup.lan -g db_servers -a oracle1.backup.lan -a oracle2.backup.lan

说明：-g指定组名，-a一次添加一个客户端。这个命令把两台 Oracle 数据库服务器归到db_servers组。参数-s指向服务端，因为要写入服务端的资源数据库。

接着创建备份策略。NetWorker 的策略可以指定备份类型，比如文件系统备份、数据库备份，也可以指定存储位置和保留周期。一个最小策略命令大致是：

nsrpolicy create -s backupserver.backup.lan -p db_backup -g db_servers -t scheduled -R 14d

这里-p指定策略名，-g指定组，-t scheduled表示按计划执行，-R 14d表示保留 14 天。注意，这不是唯一写法，NetWorker 管理界面里创建策略更直观，命令行适合批量复制。

策略建完后，还要确认它绑定了存储池。如果没有存储节点，默认会写到服务端的本地磁盘池；如果有独立存储节点，最好在策略里指定。否则备份数据写到系统盘，很快会把磁盘塞满，这是比软件报错更隐蔽的坑。

我一般还会看一眼备份周期里的启动窗口。备份窗口不能和业务高峰期重叠，特别是数据库备份，启动时间不能写成本地时间就完了，还要确认客户端和服务端在同一个时区。时区不同会导致备份任务延后 1 小时甚至 8 小时，表现是任务一直显示“等待启动”，看起来没报错，就是不跑。

5. 安装与初始化阶段的最烦人排查点：从起不来服务到备份失败

5.1 现象一：服务端装完 nsrd 起不来，端口监听失败

现象：安装脚本没有明显报错，但systemctl status nsrd显示失败，ss -tunlp看不到任何 7937 端口监听。

原因：最常见是/etc/hosts里主机名解析到了127.0.1.1，服务端启动时绑定地址解析成回环地址，外部连接全部失败。另一个常见原因是 7937 端口被某个遗留进程占用。

解决：先看日志确认绑定地址问题：

tail -n 100 /nsr/logs/daemon.raw

如果日志里出现bind address already in use，说明端口冲突，用lsof -i :7937找到占用进程并停掉。如果是解析问题，把 hosts 改成如下形式：

192.0.2.10 backupserver.backup.lan backupserver

然后重启两个服务：

systemctl restart nsrexecd nsrd

记住要先启动nsrexecd，再启动nsrd，顺序反了也会导致服务端起不来。

5.2 现象二：客户端报“无法解析服务器名”却并非 DNS 问题

现象：客户端装完，执行nsrports -s backupserver.backup.lan -C 7937，报错说找不到服务器名，但用ping backupserver.backup.lan明明能通。

原因：ping 能通可能是因为 DNS 搜索域自动补全了短名，而 NetWorker 客户端要求严格 FQDN 检查。客户端上的/etc/resolv.conf或/etc/hosts里没有完整的backupserver.backup.lan映射，服务端名解析失败。

解决：在客户端 hosts 里也加上服务端映射。这一步经常被忽略，尤其在有内部 DNS 的环境里，工程师以为 DNS 里有了就万事大吉，但部分备份软件非要在 hosts 里看到显式条目。加上后重试：

echo '192.0.2.10 backupserver.backup.lan backupserver' >> /etc/hosts nsrports -s backupserver.backup.lan -C 7937

这类问题让我翻过车，血泪经验就是：备份环境的主机名，永远优先写 hosts，不要只依赖 DNS，宁可多写一条冗余记录，也不要让软件去猜。

5.3 现象三：备份任务卡在“等待启动”或“正在连接客户端”

现象：策略配置没问题，客户端也允许连接，但任务状态一直徘徊在“等待启动”，或者备份启动后立刻失败，报错与权限无关。

原因：两个被忽略的深层因素。第一是服务端和客户端系统时间差太大，NetWorker 的认证票据默认对时间偏移极其敏感，偏移超过几分钟，握手失败。第二是存储节点没有在服务端登记，任务调度时找不到有效的存储目标。

解决：先统一时间，配置 NTP 同步。操作上，服务端和所有客户端执行：

chronyc makestep

然后确认：

chronyc tracking

看到System time偏差在几毫秒内，才算正常。接着检查存储节点：

nsradmin -s backupserver.backup.lan -p nsrstorage -C 'show; print type: nsr storage node'

如果列表为空，说明存储节点没登记。需要回到存储节点上重新执行安装脚本的存储节点配置步骤，或者手动在服务端添加存储节点资源。这两件事都是“不解决就反复挂起”的经典玄学，很多人折腾半天，最后一查是时间和存储节点。

6. 进阶技巧：用选项文件静默重装，用日志定位慢备份

6.1 静默安装：把交互参数写进配置再跑

如果后面要重复部署客户端，交互式安装太慢了。我会先把安装响应参数写成一个文本文件，再执行：

./install -options /opt/nsr_client.opt

选项文件里至少包含安装类型、安装目录、服务端主机名、是否开机自启。例如：

install_type=client install_dir=/opt/nsr server_name=backupserver.backup.lan autostart=1

参数说明：install_type是安装类型，install_dir指定软件目录，server_name是服务端 FQDN，autostart表示安装完成后是否启动服务。这种方式很适合批量推送客户端，日志输出重定向到文件后，可以统一检查安装结果。

6.2 验证安装：用日志采样定位慢备份

备份任务跑得慢，先别怀疑网络。我会先看服务端日志时间线：

grep -i "delay\|wait\|timeout" /nsr/logs/daemon.raw | tail -n 200

或者直接打开备份任务对应的日志文件，比较“客户端读取数据”和“写入存储节点”两个时间戳。差距大，问题在网络或存储节点；差距小，问题在客户端本身。这个习惯帮我很多次，备份系统就是一个黑匣子，但你不用猜，日志会把真相露出来。

最后说个教训：我见过有人为了省事跳过 hosts 配置和端口检查，结果部署完才发现，客户端连不上服务端，最后只能重装。安装 NetWorker 18.2.0.1 这件事，百分之八十的问题都出在安装前准备，而不是安装本身。提前花十分钟做检查，比事后加班排查划算得多。希望帮到你。

本文还有配套的精品资源，点击获取