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!”? ¹ 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).

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:

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

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?

Well, you can try, but NetWorker still says:

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!

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