企业官网建设流程全解析

简介：面向备份运维初学者及初次接触Dell EMC NetWorker的工程师，这份安装部署指南围绕18.2.0.1版本，系统梳理服务端与客户端落地过程，重点解决环境准备、域名解析和主机名配置等易卡点。文档从产品简介与备份架构入手，依次说明磁盘空间、TCP/IP要求、JRE安装、防火墙端口开放、DNS或Hosts文件修改，再展开Windows备份服务器安装、管理界面登录及Server Protection自动保护策略调整，并覆盖Windows与Linux客户端部署。压缩包仅含1个docx文件，大小约12.25MB，章节编号清晰，便于按步骤查阅和对照实践。已有1262人学习，适合希望快速搭建测试环境、理解安装前置条件与常见排错思路的读者，也可作为部署前检查清单和内部培训参考。

1. 备份窗口越压越短，先搞清楚 NetWorker 18.2.0.1 这套安装逻辑

上个月帮一个朋友看备份平台的故障，他的场景很典型：虚拟化集群 + 两台数据库服务器 + 一堆文件服务器，之前的脚本备份靠 cron 拉 rsync，一到月底就崩，恢复的时候连「上周三那份备份到底完不完整」都说不清。这类场景切换商业备份软件几乎是必然选择，而 Dell EMC NetWorker 18.2.0.1 就是那种在传统企业机房里跑了很多年、文档齐全、但第一次装能让人反复翻车的产品。

这份《DELL--NetWorker 18.2.0.1 安装指南》不是源码包，也不是视频课，而是一份完整的部署实施文档，内容覆盖备份服务器在 Windows 2012 R2 上的安装、Windows/Linux/AIX 三类客户端接入、JRE 环境、防火墙端口矩阵、DNS 与 hosts 解析规范，以及备份服务器自身的保护策略（Server Protection）。它解决的恰恰是初学者最容易卡住的那一段：从拿到安装包到管理界面能登录、能跑出第一份成功备份。适合刚接手备份系统的运维、做系统集成的实施工程师，以及需要给上级交一份可复现部署记录的负责人。备份这东西，只要没真恢复过一次，就永远处在玄学状态。

2. 装之前先把地基打平：JRE、磁盘与解析三件事

NetWorker 的安装包本身不复杂，难的是它在安装前对环境的隐性要求。文档里把这几条放在第 3 章开头的「一般注意事项」里，看着像客套话，实际上每条都对应一类真实故障。我一般习惯把这部分单独拎出来先做完，再动安装程序，因为 NetWorker 装完再改主机名或 JRE 路径，代价远高于装前改。

2.1 磁盘空间与安装路径的取舍

文档给的建议很直接：NetWorker 安装目录预留 200GB 以上，且不要装在系统盘，推荐 D 盘。原因不是软件本体大，而是nsr目录下会持续增长客户端索引（client file index）和介质数据库（media database），这两块是备份服务器的核心元数据，恢复时能不能快速定位到某份备份全靠它们。系统盘一旦被索引撑爆，Windows 直接蓝屏或服务起不来，那时候再迁移目录就是一场灾难。

默认安装在 C 盘时路径是：

C:\Program Files\EMC NetWorker\nsr

装到 D 盘则变成：

D:\Program Files\EMC NetWorker\nsr

这个路径后面配客户端资源、写排错脚本、看日志都会反复用到，建议装完立刻记下来。另外提醒一句，路径里不要出现中文和空格以外的特殊字符，虽然 18.2 对空格的兼容性比早期版本好，但在某些自定义脚本调用save命令时仍会出现引号转义问题。

2.2 JRE 安装与环境变量配置

NetWorker 的 NMC（NetWorker Management Console）是基于 Java 的 Web 管理界面，服务端起不来十有八九是 JRE 没配好。文档示例用的是 jre-8u161-windows-x64，安装过程本身一路 Next，关键在于装完要配环境变量。常见做法是新建系统变量JAVA_HOME，变量值填 JRE 的实际安装目录，例如：

JAVA_HOME = C:\Program Files\Java\jre1.8.0_161

然后在Path里追加%JAVA_HOME%\bin。配完后开一个新的 cmd 窗口验证：

java -version

能打印出java version "1.8.0_161"才算数。这里有个血泪经验：在已经打开的 cmd 窗口里验证是没用的，环境变量只对新进程生效，很多人在旧窗口里敲java -version看到「不是内部或外部命令」，就以为装错了，其实只是没重开窗口。另外 JRE 版本不要随意升级到更高的大版本，NetWorker 18.2 对 JRE 版本有明确适配范围，超出范围后 NMC 登录页可能白屏或报证书握手异常。

2.3 DNS、hosts 与主机名规范

这一块是文档写得最细、也最容易被跳过的地方。NetWorker 数据区里所有服务器、存储节点、客户端之间都要求能互相解析长名称、短名称和 IP 地址。如果有内部 DNS，就在 DNS 上补 A 记录；没有 DNS 就改 hosts 文件，Windows 路径是：

C:\Windows\System32\drivers\etc\hosts

文档里的写法是同时写入 IP、FQDN 和短名，格式类似：

10.10.46.1 bak-srv01.bak.example bak-srv01 10.10.13.1 dd-store01.bak.example dd-store01

每行三个字段用空白分隔，短名放在最后。Linux/AIX 客户端还要确认/etc/hosts里有 IPv4 回环条目：

127.0.0.1 localhost.localdomain localhost

少这一行，某些客户端在启动nsrexecd守护进程时会解析自身失败，表现为服务启动后几秒自动退出，日志里只留一行含糊的报错。还有两条硬性约束必须记住：TCP/IP 主机名必须与计算机名一致；主机名中不允许出现下划线_。下划线这条踩过的人不少，Windows 计算机名默认允许下划线，但 NetWorker 在建立对等连接时会拒绝这类主机名，症状是客户端资源加得进去，备份任务一跑就失败，报「host not found」性质的错误，查 DNS 又完全正常，非常折磨人。

解析验证用三条命令，逐个方向跑一遍：

nslookup bak-srv01.bak.example ping -a 10.10.46.1 tracert 10.10.13.1

nslookup确认正向解析，ping -a反向确认 IP 能解回名字，tracert确认路由可达。三个方向都通，才进下一步安装。

3. Windows 备份服务器安装：从安装向导到管理界面能登录

环境备好之后，服务器端安装本身是图形化向导，逐屏点 Next 的活，但中间有几个输入项一旦填错，后面几乎无法补救，必须当场确认。

3.1 安装包解压与向导走位

把安装介质拷到服务器本地目录，比如D:\DELL-EMC-software，进入后找到NetWorker-18.2.0.1安装程序双击启动。向导前几屏是许可协议和安装类型选择，选择 Server 安装（备份服务器），一路 Next 到提示确认，点确定继续。中途会出现两次密码输入：一次是 Keystore password，一次是 Initial password。

这两个密码的作用不同，别搞混。Keystore 是 NetWorker 认证服务的密钥库口令，用于保护服务器与客户端之间的认证凭据，后续添加客户端、生成认证令牌都依赖它；Initial password 是 NMC 管理员账号的初始密码，用于第一次登录管理界面。文档示例里两者都填了同一个字符串，测试环境图省事可以这样，生产环境务必分开并纳入密码管理，因为 Keystore 密码丢失后恢复认证库极其麻烦，属于那种「没有后悔药」的操作。

安装完成后，Windows 服务列表里会出现一组 NetWorker 相关服务，包括NetWorker Backup and Recover Server、NetWorker Remote Exec Service等，确认它们处于运行状态再往下走。

3.2 端口矩阵：防火墙不开，装完也白装

这是文档里最有价值的一页，也是最容易被忽略的一页。备份流量涉及的端口远不止一个，服务端、客户端、存储设备三方之间要双向放行。把文档中的端口要求整理成表：

端口段 7937-9936 是 NetWorker 的服务端口范围，10000-30000 是动态数据端口区间，这两个范围在跨网段部署时最容易漏开，典型症状是管理界面能看到客户端在线，但备份任务启动后立刻失败，报连接超时。写防火墙策略时建议按「服务器到客户端」「客户端到服务器」两个方向都建规则，不要只做单向，NetWorker 的通信是双向发起的。

3.3 登录 NMC 并激活服务器保护策略

安装完成后通过浏览器访问 NMC 界面，地址形如：

https://bak-srv01.bak.example:9090

首次登录用安装时设置的管理员账号和 Initial password。登录后系统会提示配置备份服务器，把主机名填进去，确认认证方式，认证通过后即可看到企业视图。

紧接着要做的一件事是启用 Server Protection，也就是备份服务器自身的自动保护策略。文档专门有一节讲这个，原因很实际：NetWorker 服务器上的元数据（索引、介质库、资源配置）如果不备份，服务器崩了之后即使数据还在存储设备上，你也不知道哪份备份对应哪个时间点，等于全部作废。Server Protection 会按内置工作流定期备份服务器自身的nsr目录和引导数据库，默认使用本地或指定设备，启用后在任务面板能看到对应的工作流。常见做法是启用后立即手动触发一次，确认执行成功再离开。

3.4 用命令行确认配置生效

图形界面看着绿了不代表底层正常，装完我一般会跑两条命令确认。在服务器上打开 cmd，切到 NetWorker 的 bin 目录：

cd "D:\Program Files\EMC NetWorker\nsr\bin" nsradmin -s bak-srv01.bak.example -p nsrexec

nsradmin是 NetWorker 的管理命令行，-s指定服务器，-p指定资源类型。进入交互界面后输入：

print type: NSR

会打印出服务器资源配置，重点看version、hostname、parallelism三个字段。版本号确认是 18.2.0.1，主机名必须与刚才 hosts 里写的完全一致，注意短名和 FQDN 的差异。parallelism是并行度，默认值通常偏保守，后续按客户端数量和存储带宽调整。

再确认 NMC 服务端口：

netstat -ano | findstr 9090

有 LISTENING 状态才算正常。如果 9090 没起来但服务显示运行中，九成是 JRE 环境变量没生效，回第 2.2 节重新检查。

提示：服务器装完当天就把这两条命令的输出截图存档，后面出现「以前明明是好的」这类争议时，这份记录就是唯一的对照基准。

4. 三类客户端接入：Windows、Linux、AIX 的差异点

客户端安装看起来比服务器简单，但跨平台差异最容易出问题。文档分别给了 Windows、Linux、AIX 三套流程，核心动作一致：装软件包、配解析、启动守护进程、在服务器端建客户端资源。

4.1 Windows 客户端安装与前置检查

Windows 客户端安装前先确认三件事：主机名无下划线、hosts 里能解析到备份服务器、防火墙按 3.2 节放行端口。然后运行客户端安装包，安装类型选 Client，中途填写 NetWorker 服务器的主机名。安装完成后检查服务：

sc query nsrexecd

nsrexecd是 NetWorker 的远程执行守护进程，客户端的所有备份请求都通过它接收，状态必须是 RUNNING。如果启动失败，先看 Windows 事件查看器里的应用日志，再检查 hosts 解析，最后看端口。三者的排查顺序不要颠倒，否则会在错误的方向上耗掉半天。

4.2 Linux 客户端：包管理器安装与守护进程

Linux 侧安装流程用命令行，以常见的 rpm 包为例，先解压安装介质，进入对应平台的目录，然后执行：

rpm -ivh lgtoclnt-18.2.0.1-1.x86_64.rpm

包名中的lgtoclnt是客户端软件包前缀，18.2.0.1与服务器版本保持一致。装完启动守护进程并设为开机自启：

systemctl start nsrexecd systemctl enable nsrexecd systemctl status nsrexecd

第三条命令看active (running)。这里有个容易踩的点：部分发行版的防火墙默认开启，只放行了 ssh，NetWorker 的端口段全部被拒。用firewall-cmd --list-ports先看当前放行列表，再按 3.2 节的端口矩阵批量添加，加完--reload生效。

4.3 AIX 客户端：installp 与文件集识别

AIX 走的是另一套包管理体系，安装用installp，先列出包里的文件集：

installp -l -d ./lgtoclnt-18.2.0.1.bff

确认输出里有LGTOnode、LGTOclnt这类文件集后执行安装：

installp -a -d ./lgtoclnt-18.2.0.1.bff LGTOnode LGTOclnt

装完同样要确认进程：

lssrc -s nsrexecd ps -ef | grep nsrexecd

AIX 上的坑主要在两处：一是/etc/hosts的回环条目格式与 Linux 略有不同，必须写成127.0.0.1 localhost这种标准形式；二是 AIX 系统默认的 TCP 参数在备份大文件时可能触发超时，常见做法是调高no参数里的tcp_sendspace和tcp_recvspace，具体值按链路情况定，改完需要重启网络服务。这两条文档里没展开，但实际部署中如果遇到备份中断且网络层无丢包，基本就是这里的问题。

4.4 在服务器端创建客户端资源

客户端软件装好只是「装上了」，还必须在备份服务器上把客户端纳入数据区，才能被策略调度。在 NMC 界面里进入客户端资源配置，新建客户端，填写客户端的主机名，注意这里填短名还是 FQDN 取决于前面解析的配置，两者必须一致，否则调度时解析到的是另一台机器或直接解析失败。保存后可以手动发起一次探测性备份，比如只备份一个测试目录，确认数据能落到存储设备上，备份索引正常生成，这条链路才算真正打通。

5. 踩坑排查：五条现场记录

下面五条都是这类部署里反复出现的，按「现象 → 原因 → 解决」写清楚，遇到时可以直接对着查。

5.1 NMC 登录页打不开或白屏

现象：浏览器访问 9090 端口，页面加载一半卡住，或登录后完全白屏，服务状态显示运行中。

原因：JRE 环境变量未对新进程生效，或安装的 JRE 大版本与 NetWorker 18.2 不匹配。前者常见于安装完成后直接在旧 cmd 窗口验证并启动服务。

解决：重开终端执行java -version确认版本，检查JAVA_HOME指向的目录里确实有bin\java.exe，然后重启 NMC 相关服务。若版本不匹配，卸载并换回适配版本的 JRE，不要试图通过修改兼容性参数绕过。

5.2 客户端显示在线但备份任务立即失败

现象：客户端资源在 NMC 里显示可达，手动启动备份任务后几秒内变成失败，日志提示连接超时或无法建立会话。

原因：防火墙端口未按双向放行，尤其漏掉 7937-9936 与 10000-30000 两个端口段。管理界面的在线探测走的是少量固定端口，数据通道走的是动态段，所以会出现「看着通、一跑就断」的假象。

解决：按 3.2 节端口表在两端各建一条双向放行策略，服务端到客户端、客户端到服务端都要有，建完用netstat观察任务启动瞬间的端口连接状态确认。

5.3 主机名含下划线导致备份失败

现象：客户端安装顺利，资源也能创建，但只要执行备份就报主机名解析相关的错误，nslookup一切正常。

原因：NetWorker 不接受包含下划线_的计算机名，而 Windows 默认允许这类命名，此前用其他工具备份时从没暴露过。

解决：修改计算机名为不含下划线的名称，同步修改 DNS 记录或 hosts 条目，重启客户端主机，并在服务器端删除旧客户端资源后重新创建。改名前先确认没有其他系统依赖旧名字，这个操作影响面比想象中大。

5.4 服务器自身元数据从未备份

现象：服务器运行数月无异常，某次存储设备故障后需要按时间点恢复，却发现找不到服务器索引的备份，只有业务数据。

原因：安装时没有启用 Server Protection 自动保护策略，或启用后从未验证过执行结果，工作流一直处于失败状态。

解决：安装完成后立即启用该策略并手动触发一次，确认备份完成、索引文件正常生成。恢复演练时必须把「服务器元数据恢复」也纳入，否则演练结果没有实际意义。

5.5 客户端解析自身失败导致服务自动退出

现象：Linux 或 AIX 客户端nsrexecd启动几秒后自动退出，日志里只有一行关于地址解析的模糊报错。

原因：/etc/hosts缺少 IPv4 回环条目，或主机名与 hosts 中的记录不一致，守护进程启动时无法解析自身。

解决：补上127.0.0.1 localhost.localdomain localhost，核对hostname命令输出与 hosts 中的短名完全一致，重启守护进程再观察。

6. 验收与复查：把「装完了」变成「确认可用」

安装最后一步不是点完向导，而是做一次完整验收并把结果留档。我现在的习惯是每次部署完都跑一遍固定清单，因为备份系统最大的风险不是装不上，而是「以为装好了」。

6.1 一份可复用的验收清单

这份表打印出来逐项打勾，比凭记忆强得多。尤其是端口和解析两项，出问题的概率最高，却最容易在验收时被「界面看着正常」掩盖过去。

6.2 恢复验证才是终极验收

备份成功不代表能恢复，这句话在真实故障里被验证过太多次。启用 Server Protection 之后，我一般会做一次小型恢复演练：挑一个测试目录，备份完成后删除其中若干文件，从 NMC 里发起恢复，确认文件内容完整、权限与时间戳正确。如果环境里有克隆链路，还要验证从副本侧恢复的路径是否可用，这一步验证的是整条数据链路，而不只是备份动作。

另外两项容易被漏掉的复查：一是备份策略的调度时间与业务高峰是否冲突，初次上线建议先观察一周的实际执行时长再调并行度；二是介质库与索引的增长速度，按 2.1 节预留的空间如果按周增长得快，就要提前规划扩容，而不是等告警。

6.3 一个具体技巧：用日志确认会话细节

图形界面的任务状态刷新有延迟，想看真实执行过程，直接看日志更可靠。服务器的日志目录在nsr\logs下，用命令按时间过滤：

cd "D:\Program Files\EMC NetWorker\nsr\logs" findstr /I "savegrp save session" *.log

findstr的/I忽略大小写，关键词选savegrp（备份组调度）和save（实际数据传输会话），能看到每次备份的启动时间、客户端、数据量和结束状态。遇到「任务显示成功但数据量明显不对」的情况，从这里能直接看出是哪个客户端提前结束了会话，比在一堆告警里翻要快得多。Linux 客户端侧对应的日志路径按发行版差异，常见做法是看/nsr/logs或系统日志里nsrexecd的记录。

从那以后我每次部署完备份系统，无论多顺利，都强制走一遍「小型恢复演练 + 日志复查」这两步，哪怕只花二十分钟。备份平台的价值不在安装当天，而在半年后那个半夜需要恢复的瞬间，那时候你能依靠的只有当初留下的记录和验证过的流程。希望帮到你。

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