Data Protection Software 19.3 – What’s New?

Last week saw the release of version 19.3 of Dell Data Protection Software – Avamar, NetWorker, Data Protection Advisor and Data Protection Central.

Over the coming weeks I’ll provide some more detailed updates, but to start with, I wanted to run through the release notes and some of the key details of the new versions.

Avamar

Avamar’s journey towards a HTML5 interface is now pretty much complete. I’ve been loving the new Avamar UI for a long time now – it’s cleaner, flatter, simpler and thoroughly enjoyable to use. I’d honestly say that if you’re still, for some reason, using the Java interface, the AUI by itself these days should be sufficient cause to upgrade.

Virtual Avamar has seen some nice enhancements, including support for the Google Cloud Platform, and a deployment option for OpenStack KVM as well. But that’s not all: Avamar has supported a virtual NDMP accelerator for some time, but that’s always required a qualification. Not any longer: the deployment OVA for Avamar’s vNDMP accelerator is now available for download with the rest of 19.3 for user installation.

There’s been some enhancements to security in this version of Avamar, including:

  • A simple command to help you replace the Avamar Root CA with your own CA certificate
  • The option to turn on FIPS mode.
  • Additional STIG/SRG CAT-I hardening.

(The SLES OS under the hood also gets an upgrade – to SLES 12 SP5.)

From a client perspective:

  • The NDMP accelerators can now handle shares of up to 200 million files
  • Support has been added for dedicated 64-bit Mac platforms (i.e., macOS 10.15/Catalina and higher)
  • File level recovery (FLR) from VMware Image-Based backups can now be performed without administrator/root privileges
  • FLR also supports Dynamic Disks in Windows virtual machines
  • Instant access now scales to 64 simultaneous operations when you’re using a PowerProtect DD 9400 and higher running DDOS 7.2 or higher.
  • Compatibility updates for a bunch of different operating system types, NAS platforms and NAS platform versions.

Data Protection Advisor

Data Protection Advisor has now completely done away with the last remnants of an Adobe Flash interface, and now has a 100% HTML5 interface.

PowerProtect Data Manager (PPDM) discovery, reporting and dashboarding has been made more effective in this release. This means that as you leverage your Data Protection Suite licensing to put PPDM into your environment, DPA can more readily track and report on your data protection activities.

Just as Avamar and now NetWorker (see below) have been updated to be Year-2038 compliant, DPA has been updated to support year 2038 and beyond.

DPA has also had some FIPS compliance fixes.

Data Protection Central

Data Protection Central has also had FIPS 140-2 compliance enabled.

There’s some enhancements to sign-on as well, including:

  • LDAP channel binding
  • LDAP channel signing
  • Support for SSO when FIPS mode is enabled

There’s also year-2038 compliance, too.

Additional support includes:

  • Eliminating the need to use the Avamar root password when adding an Avamar 19.3 or newer system.
  • Enabling of hardware-agnostic deployments, thereby making standard OS deployments (rather than from the OVA) simpler.
  • Support for deploying DPC on vSphere 7.0.
  • Support for PPDM 19.3 through to 19.5.

Upgrading DPC is really quite simple, and here’s a video that shows you the process:

Video demonstration of DPC Upgrade

NetWorker

NetWorker has certainly had some amazing updates in this release, too.

To start with, NetWorker has also achieved Year-2038 compliance, so “forever” savetimes now map, not to Jan 19 2038, but to approximately 292 billion years into the future. (As a Doctor Who fan, I particularly love this.)

The NetWorker HTML5 UI (NWUI) has seen some great updates, including:

  • Support for filesystem and block-based recoveries for clients
  • Support for redeploying vProxies from within the NWUI

NetWorker has added support for global indexing, too. This has been primarily designed to help users with global/clustered storage, such as GPFS filesystems. How this works is simple: the NetWorker client can be deployed on multiple hosts connecting to the storage and you run the backup. Sounds normal? Well, the difference here is that you can index all the backups against a single client. While previously NetWorker has supported GPFS filesystems, this method ensures that you don’t ever have to worry which client mounted what part of the filesystem – you can just search across it.

But here’s the thing: global indexing can be used on things beyond a literal GPFS formatted filesystem. The performance labs looked at this and thought … what might this do with an Isilon cluster?

So yes, ideally, an NDMP backup of a NAS platform is the most recommended approach, but it never hurts to have other options available. So the performance lab team created a configuration consisting of an Isilon cluster getting globally indexed backups via 5 NetWorker clients all mounting the filesystem and participating in the backup. The results were impressive.

Writing the backups to Data Domain, the team configured the following backup scenario:

  • Initial full backup of 798 TB.
  • Following that first full backup: 7 days of incremental backups at 1-5% change (in this case, growth) per day
  • At the end of 7 days, the Isilon system was 836 TB.

Now as you’d expect, the first full backup still took a while – it ran for 320 hours. That might sound like a lot, but that comes out to a consistent backup performance for the first full backup of around 695 MB/s.

The subsequent incremental backups took well less than an hour each of course, as you’d expect.

Here’s where it gets mind-blowing though: because why would you ever run a full backup again when you can leverage Data Domain virtual synthetic fulls?

The final backup – at 836TB was a virtual synthetic full, generating a new full backup for us to continue to work with. (And remember, Data Domain virtual synthetic fulls never need a new traditional full run!)

That completed in an hour. One hour, for an 836TB backup. 232 GB/s processing to get a new 836TB full backup in one hour.

So what that means is simple: if you’ve got a scale-out, multi-petabyte filesystem, it’s quite likely that NetWorker + Data Domain is going to offer you practically unparalleled backup performance.

That’s not all the enhancements in NetWorker though – let’s keep running through.

Package management has become better: The NetWorker client package management system (nsrpush, et al) can now run parallel sessions against hosts to inventory and upgrade – the result being a significant increase in performance for inventorying clients and pushing out new versions. Package enhancements aren’t just limited to the clients, either: upgrading the NetWorker packages on a Linux server now recognise if there are existing AuthC, NWUI and NMC configs, so you’re no longer prompted to re-run their initial configuration tools to accept all the existing values, post-install. You can see a video of the streamlined Linux NetWorker Server upgrade process below:

Streamlined NetWorker 19.2 to 19.3 Upgrade Process

There’s been some great enhancements for VMware backups, including:

  • Using a snapshot free space threshold for datastores – vProxy checks for the value then checks for the capacity of VMware datastores to make sure a backup isn’t attempted if you’re running out of snapshot space.
  • Remote authentication support for file-level recovery from an image-level backup in the vSphere Web Interface plugin.
  • Support for vSphere 7.0.
  • vSphere Web Interface plugin staging pool selection – if you recover a virtual machine backup from a non-Boost device, you can now what Data Domain pool to land the clone on that NetWorker automatically performs prior to recovery.
  • NetWorker now supports up to 300 concurrent backups per vCenter server (if configuration conditions are met in vSphere).
  • Backup retries are now supported for vProxy backup activities.

The REST API hasn’t been left out, either. The following additional actions are supported via the REST API:

  • SQL Server VDI configuration, backup and recovery
  • File-level recovery from block-based backups (BBB)
  • vProxy redeployment
  • AuthC user and group management

Additionally, there’s support now for backup, clone and recovery with SNMP v3.

NetWorker can now tap into the Data Domain automated multi-streaming (AMS) process for block-based backups and Hyper-V backups as well, speeding up their replication process.

Finally, you’ll want to note that NetWorker 19.3 has dropped support for the vSphere Flash plugin and using 32-bit Linux platforms as storage nodes. (They can still be used as clients, of course.)

Wrapping Up

All the details above are just a quick high-level view. Keep an eye out over the coming weeks for deep-dives and examples of a variety of the new features I’ve described.

Don’t forget, I’ve just released the second edition to Data Protection: Ensuring Data Availability. Jam-packed with new information and updates, if you work in data protection, this is a must-have resource for your bookshelf or desk. You can see from the photos below that it’s significantly larger! It’s now available in hard-cover, paperback and electronic formats.

5 thoughts on “Data Protection Software 19.3 – What’s New?”

  1. Hi Preston,

    Great read and some really interesting new features in Networker 19.3 especially, I wondered if there was any more information about the Global Indexing in relation to how that was configured with an Isilon. We have a new greenfield Data Center with an Isilon and I have been investigating the best way to do this. You mention the performance lab team doing this as an example, is it possible for me to view this and if so where can I see it?

    Thanks in advance

    1. As I understand it, it was simply a case of having different NetWorker clients mount specific areas of an Isilon filesystem (e.g., in the simplest scenario, think of something like Client 1 mounts /ifs/homes, Client 2 mounts /ifs/workgroups, Client 3 mounts /ifs/projects, Client 4 mounts /ifs/marketing, and so on). The clients were then backed up using the global indexing option with 19.3. Since this backup was done as a regular client backup then, rather than an NDMP backup, the configuration was able to leverage synthetic and virtual synthetic fulls more readily.

  2. I am on 19.1 still but I’m very interested in these updates as our NetApp NDMP backup takes a long time each month. But I’m confused at the information you gave. Does DataDomain do virtual synthetic full with an NDMP client type? Or would it require NetWorker clients mounting to the NetApp filer via CIFS/NFS in order to take advantage of DataDomain’s one full incremental forever technology?

  3. Hi Carl,

    The performance process outlined stepped away from NDMP to get the effects described. Keep in mind this was done as a test of the global indexing function, not necessarily a reflection of how NAS backups should definitely be configured. That being said, if you’ve reached a point with a NAS backup where conventional NDMP just doesn’t cut it any more, it might be a viable option to consider.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.