DPX 4.15 is shipping with four areas of meaningful change: full NDMP management in the web interface, VMware backup scoping by vCenter tags, KMIP-compliant key management in vStor, and cloud archive encryption. None of these are speculative features. They deliver on capabilities that our customers have been asking for, and each one has a clear operational payoff.

This post walks through what each feature does, why it matters operationally, and where it fits in the broader context of how organizations manage NAS, VMware, and encryption today.

NDMP Management Moves to the Web Interface

If you manage NDMP backup jobs in DPX, this one is for you. Until now, NDMP configuration and operations lived in the Java desktop client while VMware, Hyper-V, and block backup jobs had already moved to the web interface. With DPX 4.15, NDMP joins them: node management, backup job configuration, restore operations, and monitoring are all available in the browser.

The goal is full parity with the Java GUI for NDMP workflows, which means organizations running NDMP backups for NetApp or Isilon NAS environments can consolidate onto a single management tool.

To appreciate why this matters, some context on NDMP is useful. NDMP is a protocol that dates back to the mid-1990s, co-developed by NetApp and Intelliguard to solve the problem of backing up NAS appliances that could not run third-party backup agents. The protocol separates the control path from the data path, allowing backup software to orchestrate jobs while the NAS appliance handles the actual data movement. It remains the standard approach for protecting NAS data on platforms like NetApp ONTAP and Dell Isilon.

The industry conversation around NDMP has evolved over the past several years. Vendors like Veeam have introduced changed-file-tracking approaches for NAS backup that bypass NDMP entirely. Rubrik and Cohesity have built their NAS protection around incremental-forever models. Veritas introduced Dynamic NAS (DNAS) as an alternative to pure NDMP workflows.

These approaches have merit in certain environments. But the reality is that many organizations continue to rely on NDMP, and for good reason. They have NetApp filers, Isilon clusters, or other NAS infrastructure where NDMP is the supported, tested, and operationally understood method. Replacing it involves requalifying restore procedures, retraining staff, and often re-architecting backup data flows. For those environments, investing in better NDMP tooling delivers more immediate value than migrating to a different backup paradigm.

Moving NDMP management into a browser-based interface reduces the number of tools administrators need to maintain, lowers the barrier for onboarding new team members, and opens the door to API-driven automation. If your team currently scripts against the Java client or CLI for NDMP workflows, it is worth exploring what equivalent automation paths the web interface and its APIs provide.

VMware Backup Scoping by vCenter Tags

DPX 4.15 adds the ability to define VMware backup jobs using vCenter tags as the selection criteria. When a new VM is created and tagged in vCenter, it automatically falls into the scope of the corresponding backup job. When a tag is removed, the VM drops out.

This is a welcome addition for VMware-heavy environments. Previously, VMware backup jobs in DPX were defined by selecting specific VMs, resource pools, or folders. That approach is straightforward, but in environments where VM provisioning is frequent (dev/test, CI/CD pipelines, dynamic workloads), it means someone needs to update backup job definitions as VMs are added, moved, or reorganized. Tag-based scoping removes that overhead entirely.

Tag-based backup scoping is an established pattern in the market. Veeam supports tag-based VM selection with individual tags and tag combinations. Commvault supports filtering by tags, tag categories, custom attributes, and other vCenter metadata fields. DPX 4.15 brings this capability to our customers, and for organizations already using vCenter tags to organize their infrastructure (by department, SLA tier, application criticality, or compliance scope), backup job definitions can now align directly with those existing categories.

A few things to keep in mind. First, this works with vCenter tags specifically. If your VMware environment is managed through standalone ESXi hosts without vCenter, tags are not available. Second, the operational benefit depends on having a disciplined tagging practice in vCenter. If tags are inconsistently applied, backup coverage gaps will follow. Third, it is worth confirming how DPX handles edge cases: what happens when a VM has multiple tags that match different backup jobs? What happens during a vCenter outage when tag resolution may fail? These are the kinds of questions your VMware administrators will ask during rollout planning.

The net result is less manual maintenance of backup job definitions and better alignment between how your VMware team organizes infrastructure and how your backup team protects it.

KMIP Key Management in vStor

DPX 4.15 introduces support for KMIP-compliant keystores in vStor, the software-defined storage appliance that serves as the primary backup repository for most DPX deployments.

KMIP (Key Management Interoperability Protocol) is an OASIS standard that defines how encryption keys are managed across systems. It allows organizations to centralize key lifecycle management: generation, rotation, revocation, and destruction of keys through a single key management server, regardless of which systems consume those keys. Major KMS platforms like Thales CipherTrust, HashiCorp Vault Enterprise, and Utimaco ESKM all support KMIP.

The practical significance here is separation of duties. Until now, encryption keys for vStor were managed locally, which is simple and works well for many environments. But organizations operating under compliance frameworks like SOC 2, HIPAA, PCI DSS, or NIST 800-171 often need encryption key management to be separated from the systems that store encrypted data. KMIP support in vStor makes that possible.

With KMIP support, vStor can now act as a KMIP client, retrieving and using encryption keys from an external key management server. This means the backup administrator manages backups, and the security team manages keys. Audit trails for key usage live in the KMS, not in the backup system. If a key needs to be rotated or revoked, that happens centrally without touching individual vStor nodes.

DPX 4.15 also supports migrating keys between keystore backends. This means organizations can move from a local keystore to a KMIP-compliant external KMS (or between KMS platforms) without re-encrypting all existing backup data. For teams that are adopting centralized key management incrementally, this is a significant convenience.

Key management configuration is available through both the vStor UI and CLI, which matters for environments where security configuration is managed through automation or infrastructure-as-code pipelines.

When planning your deployment, check which KMIP versions vStor supports and confirm compatibility with your specific KMS platform. KMIP is a standard, but testing against your exact configuration is always worthwhile. The DPX compatibility matrix has the details.

Cloud Archive Encryption

Alongside KMIP support, DPX 4.15 adds encryption for cloud archive jobs. Data is encrypted before it leaves the DPX environment, regardless of the cloud or S3-compatible target.

This is client-side encryption, which is distinct from transport-layer encryption (TLS) that protects data in transit, and from server-side encryption that some cloud providers apply at the storage layer. Client-side encryption means the data is encrypted by DPX before it is transmitted. The cloud target never sees unencrypted data. DPX handles both encryption on the way out and decryption on the way back during restore.

This matters because it gives the backup team control over encryption regardless of what the cloud target supports natively. Whether you are archiving to AWS S3, Azure Blob, a MinIO cluster, or another S3-compatible endpoint, the encryption is consistent and managed by DPX.

For organizations with data sovereignty requirements, this is particularly relevant. Client-side encryption ensures that even if a cloud provider is compelled to provide access to stored data, the data is encrypted with keys that the provider does not hold (especially when combined with the KMIP integration described above, where keys live in your own KMS).

vStor and Operational Improvements

Beyond the headline features, DPX 4.15 includes several vStor enhancements worth noting.

Image mounting in vStor now runs as a background task with progress reporting per disk, so administrators can continue working while mounts complete. In environments where mounted images are used for granular file recovery or testing, this is a quality-of-life improvement that adds up over time.

Direct raw file restore from mounted images to SMB shares is now supported without requiring ZIP packaging as an intermediate step. This simplifies recovery workflows, especially for end users or application teams who need specific files restored to a share they can access directly.

Per-volume deletion lock policies provide finer-grained retention control. Instead of applying a single retention rule across all volumes on a vStor node, administrators can now set different deletion lock policies on individual volumes. This is useful in environments where different backup workloads have different retention requirements, for example, keeping production database backups for 90 days while retaining compliance archives for seven years.

Aggregated event notifications can now be delivered as PDF attachments. For teams that rely on email-based operational reviews rather than logging into the DPX interface, this reduces the need to check the UI for routine status updates.

The Bigger Picture: Web UI Consolidation

DPX 4.15 continues the web UI consolidation that has been a priority since DPX 4.11. Each release brings more workflows into the modern interface: DPX 4.14 brought tape library management, and DPX 4.15 adds NDMP. The trajectory is deliberate, and we are getting close to the point where most organizations can standardize entirely on the web interface.

If NDMP was the last major workflow keeping your team on the Java client, DPX 4.15 is likely the release where you can move away from it. Check against your specific operational procedures, but that is the milestone we aimed for with this version.

Wrapping Up

DPX 4.15 is an execution release. It delivers on things our customers have asked for: NDMP management in the web interface, VMware backup scoping that aligns with how teams actually organize infrastructure, and enterprise encryption controls that satisfy compliance requirements out of the box.

The value is practical. A single management interface for all backup workflows. Less manual maintenance of job definitions. Better alignment with enterprise key management practices. Encryption that the backup team controls end to end.

If you are running DPX in production, the upgrade conversation should focus on three things: whether your NDMP workflows are fully supported in the new web interface, whether your vCenter tagging practices are mature enough to take advantage of tag-based backup scoping, and whether your security team has a KMIP-compliant KMS ready for the encryption integration.

Those are concrete, answerable questions. That is what makes this a useful release.

Paweł Staniec is CTO at Catalogic Software.