![\"Road](\"https:\/\/nsrd.info\/blog\/wp-content\/uploads\/2015\/11\/bigStock-Recovery.jpg\")
<\/a><\/p>\nSome of the changes and updates to NetWorker with the 8.2 service pack 2 release include:<\/p>\n
- \n
- Support for JRE 1.8\/Java 8<\/strong> \u2013 You can now run\u00a0the NMC interface using Java 8<\/li>\n
- Reduced name resolution checking<\/strong> \u2013 NetWorker still requires name resolution (of some form), as you’d hope to see in an enterprise product, but there’s been a refinement to\u00a0the times NetWorker will perform name resolution. Thus, if\u00a0your DNS service is particularly slow or experiencing faults, NetWorker should not be as impacted as before*.<\/li>\n
- Automated checks<\/strong>:\n
- \n
- Peer Information<\/li>\n
- Storage nodes<\/li>\n
- Usergroup hosts<\/li>\n<\/ul>\n<\/li>\n
- Maximum device limit can be increased to 1024<\/strong>. If you’ve got a big datazone that’s running at or near 750 devices, you can now increase the maximum device count to 1024.<\/li>\n
- DDBoost Library upgrade<\/strong> \u2013 NetWorker 8.2 SP2 uses libDDBoost 3.0.3.0.<\/li>\n<\/ul>\n
It’s the automated checks I want to spend a\u00a0little time on. As a NetWorker admin or implementation consultant I would have\u00a0killed<\/em> for these sorts of tests; and indeed, I even wrote some scripts which did some similar things. If you’ve not used them before, you should\u00a0have a look at some of the tests previously\u00a0added (here<\/a> and here<\/a>).<\/p>\n
The\u00a0new options though continue to enhance that automated checking and will be a boon for any NetWorker administrator.<\/p>\n
Storage Node Checking<\/strong><\/em><\/p>\n
The first\u00a0new option I’d like to show you is the option to automatically check the status of all\u00a0the storage nodes in your environment. This can be performed by executing\u00a0the command:<\/p>\n
# nsradmin -C \"NSR Storage Node\"<\/strong><\/pre>\n
The output from this will obviously be dependent on your environment. In my lab I get output such as the following:<\/p>\n
![\"nsradmin](\"https:\/\/nsrd.info\/blog\/wp-content\/uploads\/2015\/11\/nsradmin_C_storage_node.png\")
<\/a><\/p>\nSo for each storage node, you get name resolution checking for the storage\u00a0node (forward and reverse), as well as a dump of the devices attached to the storage node. If\u00a0you have an environment that\u00a0has a mesh of Data Domain device mounts, or dynamic drive sharing\/library sharing, this will make getting a very quick overview of devices a piece of cake.<\/p>\n
Usergroup\u00a0Host Checking<\/strong><\/em><\/p>\n
As a means of more tightly checking security options, you can now query the hosts referenced in NetWorker Usergroups and determine whether they can be correctly resolved\u00a0and<\/em> reached.\u00a0This command is run as follows:<\/p>\n
# nsradmin -C \"NSR usergroup\"<\/strong><\/pre>\n
And the output (for my system)\u00a0looks a bit like the following:<\/p>\n
![\"nsradmin](\"https:\/\/nsrd.info\/blog\/wp-content\/uploads\/2015\/11\/nsradmin_C_usergroup.png\")
<\/a><\/p>\n(Note that it will check the referenced hosts for\u00a0each<\/em> user specified for that host.)<\/p>\n
NSR Peer Information<\/strong><\/em><\/p>\n
NetWorker uses peer information \u2013 generated certificates \u2013 to validate that a host which connects to the NetWorker server saying it’s client-X really can prove it’s client-X. (It’s\u00a0like the difference between asking someone their name and asking them for their driver’s license.) This prevents hosts from attaching to your network, impersonating one of your servers, and then\u00a0recovering data for that server.<\/p>\n
Sometimes if things\u00a0radically change on a\u00a0client\u00a0that peer information may get outdated and require\u00a0refreshing.\u00a0(Fixing NSR\u00a0Peer Information Errors<\/em><\/a> remains the most\u00a0accessed post on my blog.) Now you can use the automated checking routine to have a NetWorker host check\u00a0all<\/em> the peer certificates in its local client resource database.<\/p>\n
The command in this case has to reference the\u00a0client<\/em> daemon, and so becomes:<\/p>\n
# nsradmin -p nsrexec<\/em>\u00a0-s clientName<\/em> -C \"NSR peer information\"<\/strong><\/pre>\n
If you run it from the NetWorker server,\u00a0for<\/em> the NetWorker server, the\u00a0clientName<\/em>\u00a0in the above becomes the server name, since you’re checking the client resource for the server. Note\u00a0if you’re feeling particularly old-school (like I do all the time with NetWorker), you can replace\u00a0nsrexec<\/em> with\u00a0390113<\/em>\u00a0in the above as well.\u00a0This is actually also a good way of checking client connectivity, since we verify any local client certificates by comparing the locally cached certificate against the certificated stored on each client. (Given I’m\u00a0running this on a lab server, it’s reasonable to see some timeouts and errors.)<\/p>\n
For my lab, the results look like the following:<\/p>\n
- DDBoost Library upgrade<\/strong> \u2013 NetWorker 8.2 SP2 uses libDDBoost 3.0.3.0.<\/li>\n<\/ul>\n
- Reduced name resolution checking<\/strong> \u2013 NetWorker still requires name resolution (of some form), as you’d hope to see in an enterprise product, but there’s been a refinement to\u00a0the times NetWorker will perform name resolution. Thus, if\u00a0your DNS service is particularly slow or experiencing faults, NetWorker should not be as impacted as before*.<\/li>\n