PowerProtect Data Manager 19.6

USC Australia needed to modernize their data protection services for fast, reliable protection of valuable research data and support future cloud projects. They chose Dell EMC PowerProtect Data Manager, which they had deployed and protecting workloads in less than an hour. Automated asset selection and a results-focused dashboard saved them hours of administration each day, and they achieved a VMware 100% restore success rate, with restores taking 10 minutes or less. But don’t just take my word for it – click here to see what they have to say on Data Manager!

Dell Technologies customers are already getting great value out of Data Manager. Its streamlined interface and emphasis on SLA-driven data protection automation lets customers save administration time while protecting mission-critical workloads. In the latest update to v19.6, workload support extends to provide agentless protection of databases within Kubernetes, native vCentre Storage Policy Management, support for in-Cloud Kubernetes and expanded cloud platform support – and more. So let’s check it out!

Here is a quick list of just some of the new features:

  • Kubernetes backup enhancements:
    • Application-consistent backups for containers with PostgreSQL or Cassandra.
    • Cluster resource protection – cluster roles, role bindings, and so on.
  • SaaS reporting enhancements – Data Manager can report into a SaaS monitoring engine, and reporting/monitoring has been added for showing reports based on weekends and previous weeks, all unprotected assets, and compliance violations.
  • Cloud DR updates:
    • Allowing UEFI virtual machines to be DR’d to, and recalled from Microsoft Azure
    • Restoring the Cloud-copy virtual machines from within the 19.6 GUI
  • Protection policy enhancements, including:
    • Changing the storage target for a protection policy.
    • Additional scheduling options.
    • The ability to pair a VMware Storage Policy management with a policy.
    • Options to only show resources you want to protect.
  • PowerProtect Data Manager on Azure. In addition to standard IaaS filesystem backups, within Azure, it can protect Oracle, SQL and SAP HANA databases. It can also protect virtual machines running in VMware Cloud for Azure, and can protect Kubernetes clusters deployed to Azure.
  • Updated/enhanced Job UI.
  • Further simplified upgrade functionality.
  • The maximum number of concurrent backup streams for Oracle, SAP and SQL backups can be configured.
  • Support for IDPA 2.6.
  • Recovery of application-aware SQL backups from within the Data Manager user interface.

There are a lot more updates, changes and new features than I’ve mentioned in the above list. To see the full details, check out the PowerProtect Data Manager 19.6 release notes, here.

I’ve put together some PowerProtect Data Manager 19.6 videos below – check them out! Each video is available in full high definition – and you can either watch them in-line or click the caption to go to the YouTube video directly.

PowerProtect Data Manager 19.6 Deployment and First Boot
PowerProtect Data Manager 19.6 First Login, and DR Backup Configuration
PowerProtect Data Manager 19.6, Adding a Data Domain Backup/Replication Target
PowerProtect Data Manager 19.6, Adding a vCenter Server
PowerProtect Data Manager 19.6, Deploying a Search Engine
PowerProtect Data Manager 19.6, Creating an Automated VMware Protection Rule

I’ve also created a playlist just for the above videos – you can access it here.

3 thoughts on “PowerProtect Data Manager 19.6”

  1. But honestly, how mature do you regard PPDM to be, compared to Networker?

    So apart from fancy new features that are only implemented into PPDM (like for K8S), how well do the features that we were using Networker for, compare to PPDM doing the same?

    PPDM will be getting there as it can compare itself with how Avamar and Networker do their thing, but at the moment we declared PPDM not yet being mature enough as it does not yet support enough of the options that for instance NW does.

    We’ll be doing a POC next year defenitely.

    Also I have to get used to the idea of each policy having its own mtree? How does that work for scalability on a DD, compared to having one mtree for NW with all underlying devices being a subsfolder?

    So imagine a dozen PPDM envs sharing a data domain, compared to the same amount of nw servers doing that now. You might be very likely reaching mtree limits there or not?

    Or protecting PPDM’s own database by having a cifs share on a DD to dump its own backup to? Is that still the case?

    I wouldn’t feel completely at ease when hit by a ransomware attack, if the backup of my backup environment is on a network drive (regardless if it is a DD). Especially with some of your posts in mind about ransomware, using the strengts of a DD and not putting backups on a share. I see a contradiction there…

    But I reckon PPDM will become the future in lieu of avamar and networker. So we better get used to it and the “path to power”…

  2. Hi Barry,

    PPDM is a newer product than NetWorker and the growth in workload support is an iterative, ongoing process. With a clean slate compared to products that have been around for a longer time, PPDM allows the easier integration of modern workloads. PPDM can meet the requirements of a variety of businesses – after all, we’re seeing an increasing number of businesses that have pretty much hit 100% virtualisation. The workloads are evolving rapidly – we’re already up to the 6th release of PPDM with 19.6, and each release has seen new workloads and enhancements added.

    Any product as flexible as NetWorker comes with the drawbacks that you’ve got lots of “knobs and levers” to pull and adjust within the product. PPDM’s architecture though is more autonomous – you tell it what you want to backup and the windows in which the backup should run, and it does the hard part. I’d argue that this prescriptive approach is likely to grow in popularity: do you as a backup administrator really want to coordinate when and how backups should run for 20,000+ virtual machines, or do you just want to set some broad brush-stroke directions on SLAs and priorities and let the system sort out all the minutiae of what executes and when? An ML-enabled backup system that applies optimal scheduling patterns is more scaleable than administrators adjusting the start times for a potentially large number of policies.

    In terms of Mtree scalability – I envisage this not to be an issue. In NetWorker, it’s typical to have a lot of highly granular policies and workflows. PPDM’s scheduling and SLA approach allows you to put a lot more systems into far fewer protection policies – again, with PPDM sorting out the details of the backups.

    PPDM does access the DR share via NFS – though the NFS access policies should be configured to only allow the PPDM server and search nodes to access the share. Since these are all appliances that should not be accessed in a “desktop” experience, there is a significantly lowered risk of a ransomware situation as you’re describing. I can’t go into future details of course, but I don’t see this being an ongoing challenge.

    Feel free to reach out to me when you’re doing your PoC. I’ll be very happy to understand how that goes.

    Cheers!

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.