What’s new in NetWorker 19.7?

NetWorker 19.7 was recently released, and in this article I’ll step through some of the key updates in the product.

You’ll find the official release notes and other documentation for NetWorker on its product documentation page, but I’ll skip through the new features below.

• Client inventory/upgrade operations:
  • In an earlier release of NetWorker, parallelism was introduced for client inventory/upgrade operations (i.e., the nsrpush functionality). As of this release, you can now change the parallelism if you’d like from the default of 4.
• Scanner enhancements:
  • The scanner utility is what you use to rebuild indices that have expired or been removed. There’s now an option to check the expiration of saveset indexing you’re bringing back in against a nominated date. For example, you might intend to scan in some filesystem backups whose indices expired, because there’ll be a number of browsable recoveries run against them over the next two weeks. But what if some of those savesets are almost at the end of their retention time? Tell scanner to warn you if anything it scans for is set to expire in that timeframe and you’ll get a heads up so you can action it after the scanning is done.
• Storage node:
  • When it comes to backup environments, speed is always good. And NetWorker storage nodes get a speed bump in this version when it comes to cleaning up expired savesets and freeing up the disk space afterwards.
• Encryption at rest:
  • There’s an option to globally turn off encryption at rest if you need to — this prevents clients from turning it on using directives. This is the sort of option you want if you’re switching from traditional disk backup devices to deduplication systems such as PowerProtect DD. (For those systems, you want that encryption at rest option turned off so you can leverage native Data Domain encryption at rest.)
• Security updates:
  • Additional auditing is now introduced when an administrator or the system invokes nsrim (used to clean up expired savesets). This allows you to audit operations that trigger backup deletion.
  • Likewise, deletions of savesets from AFTD, CloudBoost or PowerProtect DD (standard, Smart Scale or Cloud Tier) devices are now tracked in the audit log.
  • New options to allow the administrator to reset the system fingerprint and unlock access to lockboxes if required.
  • You can now attach a Root CA Certificate/Root CA Certificate File to a PowerProtect DD or Smart Scale system; doing so allows you to apply additional authentication processes to DD Boost connections.
  • There’s a new command, nsrclientserverlist, that can be used to probe clients (NetWorker 19.7 onwards) for details of their authorised servers (maintained in the servers file). You can also use it to create, update or delete entries in the file too. (Check below for an example of this.)
• Cloning configuration:
  • There’s now a new RAP resource ‘NSR cloneconfig’ that allows you to more easily control global cloning preferences (e.g., enabling AMS and the number of slices and threads, whether you want virtual synthetic replication disabled, the level of verbosity or debugging that you want for all cloning operations, etc.)
• VMware updates:
  • vProxy OVAs can be redeployed from OVAs that have been stored in the vCenter Content Library (7.0 U3 and higher)
  • You can perform FLR for Linux virtual machines that have unformatted disks
  • NetWorker virtual edition has had its size increase to provide more space to work with
  • VBA support has been deprecated
• Mtree replication:
  • NetWorker supports enabling enhanced DR strategies between NetWorker servers by coordinating Mtree replication between systems; essentially, this keeps Mtrees synced between two Data Domains and coordinates the export of metadata for replicated volumes from a source NetWorker server and the import of that metadata to a target NetWorker server.
• Database/Application support:
  • Cassandra DB is now supported for backup and recovery using NetWorker Orchestrated Application Protection (OAP)
  • Performance improvements for Exchange 2019 database recoveries by using MetaCacheDatabase
  • Support for transparent data encrypted granular recovery from SQL Server and SharePoint
  • Meditech module now supports integration with PowerStore for enhanced backup and recovery operations.

It’s a fairly comprehensive list of features and updates, and I’m sure to have forgotten a thing here or there, but as always it’s great to see NetWorker continuing to stride forward with new features and functions.

The NetWorker Web UI continues to move forward, too. Here are a couple of views — first, the dashboard, and second, monitoring action activities:

I want to drill in a little bit on that nsrclientserverlist utility. I think this is a really handy addition for environments where you still have a lot of client software installs (as opposed to virtual machines that you’ll capture as an image-based backup). Since in enterprise environments its common for the backup administrator not to be able to log onto clients, confirming the client’s servers file is up to date is a little annoying. With that functionality now available from the server, it’ll be a real time saver. Let’s look at it in operation.

To test this out I decided to pick on one of my physical Linux hosts to see whether the lazy backup administrator (me) had setup the servers file correctly. Oops, it turns out no:

As you’d know, not having that servers file in place is a security no-no. You really should have it defined. This caused me to jump across to the system (old habits take time to break) and create the servers file manually, forgetting of course that nsrclientserverlist can actually do that!

With the servers file updated, I could see the results by querying again from the server:

Now, what if I wanted to update the servers list? At this point the only authorised server for ‘krell’ is ‘orilla.turbamentis.int’, but what if I had another two NetWorker servers I wanted to give access to ‘krell’? Well, I can simply update the server list appropriately:

Finally, because I’d done it old-school initially, I wanted to double check that I could indeed not only add a NetWorker server to the servers file, but actually create the servers file remotely as a result of the operation. So on my client krell, I stopped NetWorker, deleted the servers file, then re-ran the probe + added my lab NetWorker server as an authorised server:

If you want more details on NetWorker 19.7, head over to the product page and check it out.