Using NetWorker with Data Domain Retention Lock

You know when you’ve got a secret herb or spice you use in a recipe that turns it from “this is good” to “holy cow this is great!”? 1 Well, I’ll let you in on a little secret: Data Domain retention lock is like that.

Data Domain is good by itself – but when you bring retention lock into the mix, it’s just a stellar tool for data immutability within your organisation. Both NetWorker and PowerProtect Data Manager support retention lock straight out of the box, and in this post I’ll take you through getting it running with NetWorker.

The overview of the process is:

  1. Enable retention lock for your NetWorker Mtree on the Data Domain.
  2. Create Data Domain boost device(s) with retention lock enabled.
  3. Start backing up with retention lock automatically applied to successful savesets.
  4. Whee! (OK, this part is optional, but I do find backup exciting.)

Now, obviously, enabling retention lock is something you should think very carefully about. So I’m going to run through the steps, but if you want to work with retention lock, please be sure you read the NetWorker and Data Domain documentation about it before you configure it.

Before I get started – the second edition of Data Protection: Ensuring Data Availability has been released. You can check out what’s new here.

On the Data Domain

On your Data Domain, log into System Manager, then:

  1. Go to Data Management > Mtree
  2. If the first Mtree gets selected and it’s not your NetWorker Mtree, deselect it.
  3. Find your NetWorker Mtree and select it so the information panels under the Mtree list is populated with its details.
  4. Scroll down in the information panels to the Retention Lock section and click the “Edit” button to adjust the settings.
  5. Enable Retention lock in either Governance or Compliance Mode (Governance will be enough for many companies), choose the minimum/maximum length of time, but leave the use at “Manual”, then click OK to apply.
  6. You should then see retention lock enabled.

I’ve encapsulated that process in the gallery below:

In NetWorker

Now, in my example, I’ve got a NetWorker server already configured with regular Boost devices. I.e., no retention lock. So with the Data Domain now configured for retention lock, I’ll be adding a new device, and with it a retention lock-enabled pool.

Aside:
That’s the great thing about retention lock: it doesn’t have to be an “all or nothing” approach. Of course, you can use retention lock on all your backups, but if you want to use it on just a subset, you can. You might, for instance, configure a pool for backup testing that has no retention lock, so you can delete those backups whenever you want.

Here’s a view of the device creation wizard process:

The quick overview:

  1. Start the New Device Wizard
  2. Choose Data Domain Boost device
  3. Choose your Data Domain, enter your Boost credentials and choose the “Browse and Select” option – we’ll be creating a new folder in the NetWorker Mtree.
  4. Create a new folder and select it. I gave it a name of “boostRL”. I think if you’re going to have a mix of retention lock and non-retention lock pools/devices/volumes, making sure you’ve got an easy way to usually identify them is important.)
  5. Select the option to create and use a new pool, giving that pool an appropriate name.
  6. Pick the storage node and enable Data Domain retention lock.
  7. Step through the rest of the device configuration as normal.

Once you’ve got this done, you’ve got a Data Domain Boost device created, with a volume labelled in a pool that has retention lock enabled. The next step is using it!

Configuring Backup with Retention Lock

I wanted a simple test, so I created a folder on my backup server and dropped a couple of files in it, then created a new client instance with a saveset of just that folder. I didn’t think to grab screenshots but it’s a pretty straight forward process.

The next step is to create a backup policy that will enable retention lock as part of the backup process.

So the process here was:

  1. Create a new policy, or choose an existing policy.
  2. Create a new workflow for retention lock backups.
  3. Create a backup action, setting schedules/etc. appropriately.
  4. Configure the retention for the backup, and enable retention lock, specifying the retention lock settings as well.
  5. Review the settings and complete the creation of the Policy/Workflow/Action.

Backing up with Retention Lock

Once you’ve got a workflow/action configured with retention lock, backing up is no different from normal. NetWorker automatically applies retention lock to successful savesets (so if the saveset fails halfway through and would normally be deleted, don’t worry, it’ll still get deleted, since retention lock won’t have been applied).

Running a backup with retention lock is no different from running a regular backup
Running a backup with retention lock is no different from running a regular backup

Verifying it’s Locked

To verify the backup I’d just taken had retention lock applied, I figured I’d try to delete it. To start with, that meant finding the saveset ID:

Finding the saveset ID for the completed backup
Finding the saveset ID for the completed backup

So, with that saveset ID in hand, what happens if I try to delete it? Well, NetWorker says no:

nsrmm won't let you delete a backup with retention lock enabled
nsrmm won’t let you delete a backup with retention lock enabled

If you try to use nsrmm for instance to delete a saveset that has retention lock enabled, NetWorker firmly says no. Now note in this case it’s saying “One or more clones”: this is because if you just give the saveset ID to nsrmm to delete, it’ll delete all the instances of the saveset. (If you had an original backup with retention lock enabled but a clone without retention lock enabled, you’d still be able to delete the clone by specifying a SSID/CloneID combination to nsrmm.)

So I can’t delete the saveset. What about the volume?

Try to label a volume with a retention locked saveset
Try to label a volume with a retention locked saveset

Well, you can try, but NetWorker still says:

NetWorker doesn't allow you to delete a volume that has retention locked savesets on it
NetWorker doesn’t allow you to delete a volume that has retention locked savesets on it

That’s a pretty secure backup at this point. Short of someone racing into your datacentre and taking an axe to the Data Domain, it’s going to be preserved.

Some Notes and Considerations

One thing I hope you’ll see from this process is that it’s easy. Enabling using Data Domain retention lock with your NetWorker server is really quite simple to get up and running, and you get a level of data immutability that most other backup products just can’t deliver. With Boost enabled devices, your backup volumes don’t “appear” on host operating systems as shares anyway, but this is a further way of guaranteeing that malware isn’t going to destroy your backups. Some backup products get taken out during a ransomware attack by the backup data being targeted for encryption. Data Domain Boost devices prevent that in normal operations, but even more so in this case, even if you find malware that tries to tell NetWorker to delete the backups, it’s not going to be able to.

Obviously this was a test server for me. The thing to keep in mind with retention lock is: once it’s locked, it’s locked. You can have multiple retention lock times associated with backups, but you do want to ensure you don’t lock something for longer than you really mean.

A few general architectural considerations it’s worth knowing about:

  • Your NetWorker retention and Data Domain Retention Lock don’t have to match. (For example, you might prefer to keep certain backups for 3 months, but only want retention lock enforced for the first month.)
  • You can retention lock on the backup copy, the clone, or both.
  • You can still Cloud Tier with retention lock enabled.

That’s all there is to it!

Footnotes

  1. For me, that’s got to be powdered French Onion soup mix on slow baked lamb.

9 thoughts on “Using NetWorker with Data Domain Retention Lock”

  1. Hi Preston,

    thank you for your information. Very helpful as useful.

    I recently found out that the RL ‘flag’ can only be set via a policy/workflow/action. However, if one uses the nsrclone command directly (as executed by NW which you can see from the logs),
    the RL will not be set.

    This looks weird to me – I do not see any reason why it should not be possible. In the end it is just setting some specific attributes in the media db. Especially I see a problem as you cannot apply ‘scripted cloning with setting a RL’ as it has been possible for standard browse/retention time for decades.

    Do you consider this a bug or a feature?

    Thanks and best regards, Carsten

    1. Hi Carsten,

      It’s my understanding this is a feature: the file has to be touched to set retention lock, so it makes sense to do it as part of either a backup or clone operation. I get that there might be a desire to do it via nsrmm, but the goal should be that retention lock is set as soon as it’s successful, rather than manually at a point in the future.

      Cheers.

      1. Hi Preston,

        thank you for your quick response.

        The issue is that I in fact use the nsrclone command, for example: nsrclone -b rlock_pool -y “4000 Days” -S ssid

        If you verify ddrltype & ddrltime later, you will see that these attributes will in fact not be set for the clone instance.
        This is what I verified with NW 19.2.1.0/Windows.

        Best regards, Carsten

        1. In similar fashion just as with save command, it needs to be action set within policy. I didn’t try nsrclone yet (except seeing it does not work for what I was after), but I suspect should be possible to fake it just as I could fake save command (check my other post on this article).

          1. Retention lock is at this time is integrated for NetWorker to activate it as part of an action/workflow for a policy, not individual cloning commands/etc. I see your points regarding migration (I’m assuming you’re referring to staging) and the server database backup. (I’ll look into RFEs for these.)

  2. My tests (after one day) so far:
    – for some strange reason, if you run save (manual backup), you can’t set retention lock – I understand rl should be checked when backup is successful, but server can know that via nsrexecd also by checking exit of command. I can fake it via -a ‘*policy action DD retention time=unixtime_for_ddrltime’, but in some cases this would be an issue (think of SAP HANA logs for example)
    – if I want to migrate data from non rl volumes to rl volumes, I see no way of doing that
    – for some strange reason, server db backup action does not have option to set rl

  3. Hi

    Thank you for this nice elaborated doc on RL. I checked the Dell RL guide and it says that automatic RL can only be enabled if you are using CIFS\NFS with mtree and DD-Boost is considered as a logical storage unit and can’t be used for auto Retention Locking with Networker.

    1. Hi,

      There’s a difference between BoostFS and a Data Domain Boost device in NetWorker.

      If you’ve configured the devices in NetWorker as Data Domain Boost, NetWorker can automatically apply retention lock.

      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.