Basics – Using nsradmin with NetWorker Policies

NetWorker 9 saw the introduction of the service-catalogue like Policy/Workflow/Action configuration engine in NetWorker, which replaced the previous group based configuration. While policies could be manipulated from within NMC, and from the command line using nsrpolicy, they couldn’t really be edited (unless you were feeling particularly brave) in nsradmin because they’re maintained in JSON format.


NetWorker 18.2 has introduced an updated nsradmin utility though that can be used to manipulate NetWorker Protection Policies, Workflows and Actions, and in this blog post, I’m going to take you through how that works.

CAUTION: I’ve always said that an advanced NetWorker administrator should be fluent with nsradmin. However, nsradmin lets you directly edit NetWorker resources, so if you’re not sure about what you’re doing, you should always practice on a test server first. Remember you can always run up a temporary NetWorker server and use it in ‘trial’ mode without enablers for a few weeks.

Let’s check out what the resource types are with NetWorker 18.2:

NetWorker Resource Types

Here you’ll see the NSR Protection Policy, but no workflows or actions. Is that correct? Well, yes. The reason for this is that there’s some interpretation work going on in the background. But don’t worry, we’ll run through what that means. To start with, let’s look at one of my protection policies. Now, I have a ‘Platinum’ protection policy, and I can see its details as follows:

nsradmin> print type: NSR Protection Policy; name: Platinum
type: NSR Protection Policy;
name: Platinum;
comment: "Template policy: Platinum";
restricted data zone: ;
Notification action: nsrlog -f policy_notifications.log;
Notification execute on: completion;
policy protection period: ;
manual saves: No;

Using nsradmin to manipulate policies, workflows and actions is covered in the NetWorker 18.2 Administration Guide, so I’m going to more briefly introduce what you need to do here to get to a workflow. Let’s start by finding out what workflows I have in the Platinum policy. I’ll use the ‘show’ command to only show the workflow names, then execute the print command:

nsradmin> show name:
nsradmin> print type: NSR Protection Policy Workflow; policy name: Platinum
name: Servers;

name: VM Filesystem Backups;

name: Laptops;

name: Desktops;

name: iTunes;

name: Uni;

So we’re using a ‘hidden’ resource name called “NSR Protection Policy Workflow”, and to identify the workflows that we want to use, we characterise them by a resource key of “policy name”, being Platinum.

Let’s drill down and have a look at one of those workflows, the Servers workflow.

nsradmin> show
Will show all attributes
nsradmin> print type: NSR protection policy workflow; name: Servers; policy name: Platinum
type: NSR protection policy workflow;
name: Servers;
comment: ;
Auto start enabled: Yes;
Interval end time: "23:00";
Group: Platinum_Servers;
Interval: "24:00";
Restart window: "24:00";
Start time: "23:00";
Enabled: Yes;
policy name: Platinum;
Notification action: "/bin/mail -s \"Servers Completion Notice\"";

Now, what if we wanted to look at the actions that are present for this workflow? Using the ‘show’ command first again to restrict our view to just the names, the command will look like:

nsradmin> show name                                       
nsradmin> print type: NSR protection policy action; policy name: Platinum; workflow name: Servers
name: backup;

name: clone;

Let’s look at the backup action, shall we?

nsradmin> show
Will show all attributes
nsradmin> print type: NSR protection policy action; policy name: Platinum; workflow name: Servers; name: backup
type: NSR protection policy action;
name: backup;
comment: ;
action enabled: Yes;
policy name: Platinum;
workflow name: Servers;
Concurrent: No;
action type: backup;
Backup subtype: traditional;
Force backup level: ;
period: week;
Actions: "incr,incr,incr,incr,incr,incr,full";
Destination storage node: nsrserverhost;
Destination pool: Backup_01;
Retention: 2 Months;
Apply DD retention lock: No;
Success threshold: success;
Client can override: clientCanOverride;
action retries: 1;
Retry delay: 15;
action inactivity timeout: 30;
action parallelism: 100;
Failure impact: continue;
Soft limit: "00:00";
Hard limit: "00:00";
Notification action: \
"/root/bin/mailer.pl -s \"[NetWorker] Servers Backup Results\"";
Notification execute on: completion;
Overrides: ;
start time: ;
DD retention lock time: ;
Driven by: ;

Here we can see the individual action associated with the policy and workflow. Like any normal nsradmin situation, we can edit these resources, too. For instance, let’s say I wanted to reduce the action parallelism from 100 down to 80:

nsradmin> update action parallelism: 80
action parallelism: 80;
Update? y
184066:nsradmin: 'Platinum / Servers / backup' Action will be updated
nsradmin> print
type: NSR protection policy action;
name: backup;
comment: ;
action enabled: Yes;
policy name: Platinum;
workflow name: Servers;
Concurrent: No;
action type: backup;
Backup subtype: traditional;
Force backup level: ;
period: week;
Actions: "incr,incr,incr,incr,incr,incr,full";
Destination storage node: nsrserverhost;
Destination pool: Backup_01;
Retention: 2 Months;
Apply DD retention lock: No;
Success threshold: success;
Client can override: clientCanOverride;
action retries: 1;
Retry delay: 15;
action inactivity timeout: 30;
action parallelism: 80;
Failure impact: continue;
Soft limit: "00:00";
Hard limit: "00:00";
Notification action: \
"/root/bin/mailer.pl -s \"[NetWorker] Servers Backup Results\"";
Notification execute on: completion;
Overrides: ;
start time: ;
DD retention lock time: ;
Driven by: ;

Now, what if I wanted to create an entirely new workflow for my ‘Platinum’ policy? Since NetWorker will automatically fill in defaults for resources, we can create a ‘templated’ workflow very easily that we can then adjust. For instance:

nsradmin> create type: NSR protection policy workflow; name: Demo; policy name: Platinum
type: NSR protection policy workflow;
name: Demo;
policy name: Platinum;
Create? y
183936:nsradmin: 'Platinum / Demo' workflow was successfully created
nsradmin> print type: NSR protection policy workflow; name: Demo; policy name: Platinum
type: NSR protection policy workflow;
name: Demo;
comment: ;
Auto start enabled: Yes;
Interval end time: "21:00";
Group: ;
Interval: "24:00";
Restart window: "12:00";
Start time: "21:00";
Enabled: Yes;
policy name: Platinum;
Notification action: " ";

Since I don’t really need that workflow, I can equally delete it. Because it’s still the target of my previous print command in my session, that’s as simple as:

nsradmin> delete
type: NSR protection policy workflow;
name: Demo;
comment: ;
Auto start enabled: Yes;
Interval end time: "21:00";
Group: ;
Interval: "24:00";
Restart window: "12:00";
Start time: "21:00";
Enabled: Yes;
policy name: Platinum;
Notification action: " ";
Delete? y
183985:nsradmin: Platinum / Demo Workflow deleted successfully

(If you’re unsure, you’d always fully target the resource you want to delete, but nsradmin will prompt you to confirm as long as you’re working against a NetWorker server in interactive mode.)

And there you have it: using nsradmin to manipulate Policies, Workflows and Actions in NetWorker 18.2. That’s yet another good reason to make sure you upgrade ASAP, as far as I’m concerned!

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.