It may be something to do with my long Unix background, or maybe it’s because my first system administration job saw me administer systems over insanely low link speeds, but I’m a big fan of being able to use the CLI whenever I’m in a hurry or just want to do something small. GUIs may be nice, but CLIs are fun.
Under NetWorker 8 and below, if you wanted to run a server initiated backup job from the command line, you’d use the savegrp command. Under NetWorker 9 onwards, groups are there only as containers, and what you really need to work on are workflows.
There’s a command for that – nsrworkflow.
At heart it’s a very simple command:
# nsrworkflow -p policy -w workflow
That’s enough to kick off a backup job. But there’s some additional options that make it more useful, particularly in larger environments. To start with, you’ve got the -a option, which I really like. That tells nsrworkflow you want to perform an ‘adhoc’ execution of a job. Why is that important? Say you’ve got a job you really need to run today but it’s configured to skip … running it in adhoc will disregard the skip for you.
The -A option allows you to specify specific overrides to actions. For instance, if I wanted to run a job workflow today from the command line as a full rather than an incremental, I might use something like the following:
# nsrworkflow -p Gold -w Finance -A "backup -l full"
The -A option there effectively allows me to specify overrides for individual actions – name the action (backup) and name the override (-l full).
Another useful option is -c component which allows you to specify to run the job on just a single or a small list of components – e.g., clients. Extending from the above, if I wanted to run a full for a single client called orilla, it might look as follows:
# nsrworkflow -p Gold -w Finance -c orilla -A "backup -l full"
Note that specifying the action there doesn’t mean it’s the only action you’ll run – you’ll still run the other actions in the workflow (e.g., a clone operation, if it’s configured) – it just means you’re specifying an override for the nominated action.
For virtual machines, the way I’ve found easiest to start an individual client is using the vmid flag – effectively what the saveset name is for a virtual machine started via a proxy. Now, to get that name, you have to do a bit of mminfo scripting:
# mminfo -k -r vmname,name vm_name name vulcan vm:500f21cd-5865-dc0d-7fe5-9b93fad1a059:caprica.turbamentis.int vulcan vm:500f21cd-5865-dc0d-7fe5-9b93fad1a059:caprica.turbamentis.int win01 vm:500f444e-4dda-d29d-6741-d23d6169f158:caprica.turbamentis.int win01 vm:500f444e-4dda-d29d-6741-d23d6169f158:caprica.turbamentis.int picon vm:500f6871-2300-47d4-7927-f3c799ee200b:caprica.turbamentis.int picon vm:500f6871-2300-47d4-7927-f3c799ee200b:caprica.turbamentis.int win02 vm:500ff33e-2f70-0b8d-e9b2-6ef7a5bf83ed:caprica.turbamentis.int win02 vm:500ff33e-2f70-0b8d-e9b2-6ef7a5bf83ed:caprica.turbamentis.int vega vm:5029095d-965e-2744-85a4-70ab9efcc312:caprica.turbamentis.int vega vm:5029095d-965e-2744-85a4-70ab9efcc312:caprica.turbamentis.int krell vm:5029e15e-3c9d-18be-a928-16e13839f169:caprica.turbamentis.int krell vm:5029e15e-3c9d-18be-a928-16e13839f169:caprica.turbamentis.int krell vm:5029e15e-3c9d-18be-a928-16e13839f169:caprica.turbamentis.int
What you’re looking for is the vm:a-b-c-d set, stripping out the :vcenter at the end of the ID.
Now, I’m a big fan of not running extra commands unless I really need to, so I’ve actually got a vmmap.pl Perl script which you’re free to download and adapt/use as you need to streamline that process. Since my lab is pretty basic, the script is too, though I’ve done my best to make the code straight forward. You simply run vmmap.pl as follows:
[root@orilla bin]# vmmap.pl -c krell vm:5029e15e-3c9d-18be-a928-16e13839f169
With ID in hand, we can invoke nsrworkflow as follows:
# nsrworkflow -p VMware -w "Virtual Machines" -c vm:5029e15e-3c9d-18be-a928-16e13839f169
133550:nsrworkflow: Starting Protection Policy 'VMware' workflow 'Virtual Machines'. 123316:nsrworkflow: Starting action 'VMware/Virtual Machines/backup' with command: 'nsrvproxy_save -s orilla.turbamentis.int -j 705080 -L incr -p VMware -w "Virtual Machines" -A backup'. 123321:nsrworkflow: Action 'VMware/Virtual Machines/backup's log will be in '/nsr/logs/policy/VMware/Virtual Machines/backup_705081.raw'. 123325:nsrworkflow: Action 'VMware/Virtual Machines/backup' succeeded. 123316:nsrworkflow: Starting action 'VMware/Virtual Machines/clone' with command: 'nsrclone -a "*policy name=VMware" -a "*policy workflow name=Virtual Machines" -a "*policy action name=clone" -s orilla.turbamentis.int -b BoostClone -y "1 Months" -o -F -S'. 123321:nsrworkflow: Action 'VMware/Virtual Machines/clone's log will be in '/nsr/logs/policy/VMware/Virtual Machines/clone_705085.raw'. 123325:nsrworkflow: Action 'VMware/Virtual Machines/clone' succeeded. 133553:nsrworkflow: Workflow 'VMware/Virtual Machines' succeeded.
Of course, if you are in front of NMC, you can start individual clients from the GUI if you want to:
But it’s always worth knowing what your command line options are!
What about restarting workflow from CLI? I quickly checked 9.1 manual, but could not see that option.
I don’t think it’s an option in nsrworkflow. I suspect (though I’m away from my computer all day so I can’t confirm), the restart option will likely be in nsrpolicy, which is the more complex/complete option not only for stopping/starting jobs, but also for completely configuring them from the command line as well.
Indeed… just checked…
nsrpolicy restart
{ –policy_name policy_name | -p policy_name } { –workflow_name workflow_name | -w workflow_name } [ –job_id job_id | -j job_id ] [ –server server | -s server ]
Any option of starting workflow from client
Couldn’t see option in nsradmin like V8 ( Start now)
I’d suggest looking at the REST API for that.