In the first blog post of this series, we mentioned that using the Cohesity PowerShell module, we can suspend/disable our Cohesity Protection Jobs using a single line of code. However, that single line of code will not check for the existence of any active running protection jobs. That line of code will disable future protection jobs from running on the cadence that was specified in the policy for the protection job. We need to dig deeper into the object information that is returned from a Cohesity Protection Job in PowerShell to get the details we seek.
If you want to consider some object hierarchy, a Protection Job is a series of Protection Job Runs. Each run is the history of data that is being backed up by the Cohesity platform. With that in mind, we can use a cmdlet in the Cohesity PowerShell module named Get-CohesityProtectionJobRun. This cmdlet will effectively run through the entire system and return all existing protection job run information from all of the protection jobs on the system. However, we want to filter this data. While the PowerShell module is in constant development, at the time when I wrote these scripts for the truck, I had to use some basic PowerShell filtering to find the data, rather than pass any parameters to the Cohesity PowerShell cmdlet. I did this with the following line of code:
Get-CohesityProtectionJobRun | Where-Object {$_.BackupRun.Status -match “kAccepted”}
If you aren’t well versed in PowerShell, this line of code can look a little daunting. Let’s break it down into each part of the pipeline. To begin, we are gathering all the protection job run information using the Get-CohesityProtectionJobRun cmdlet. We then pipe that data to the Where-Object cmdlet, which will filter the data on our request. In this case, in the object, there exist properties and methods. Methods used to run other low-level cmdlets against the data and properties are usually the data you seek, whether in the form of numbers (like integers) or string values. In this case, in the object, we seek properties under BackupRun. Specifically, we want the string value of Status. We are looking for all instances of this property that match (using Regex) the string kAccepted. Within the Cohesity system, there are status properties that exist under various conditions. In this case, kAccepted means that the job run has been accepted by the system and is currently in a running state. If the job run was complete, you’d likely see the value as “kSuccess”.
Now that we’ve found all jobs that are currently running, we need a bit more information to pass to the Cohesity PowerShell cmdlet to cancel the job. I did this by running the following line of code:
Get-CohesityProtectionJob | Where-Object {$_.BackupStatus -match “kAccepted”} | Select JobName, JobId, @{n=”JobRunId”;e={$_.BackupRun.JobRunId}} | ForEach-Object { Stop-CohesityProtectionJob -Id $_.JobId -JobRunId $_.JobRunId }
As you can see, a lot is going on here. So, let’s break down this cmdlet. We’ve seen the first couple of cmdlets already. We are obtaining all running protection jobs. The Select part is where I’m creating a custom PowerShell object and storing specific information I need from those objects. In this case, I want the properties called JobName and JobId. The last property is buried under a different property in the object, so I’ve created a custom property and asked for the JobRunId value, which is under the BackupRun property. I want to store that, as it’s essential to running the last cmdlet in our line of code.
ForEach-Object is a nice way of piping all the object’s information then running a quick and dirty ForEach loop. Meaning we are going to run through all the objects that exist from the pipeline (which means, the running jobs) and issue the following cmdlet, Stop-CohesityProtectionJob. To properly issue this against the right JobId and JobRunId, this is why I stored them in the custom PowerShell object on the pipeline. By running that entire line of code, we’ve effectively issued stop commands to all the running protection jobs on the system.
You can add more code, like a do..while loop, to keep checking the status to make sure that all jobs have stopped. That will add more steps to ensuring all jobs are no longer running and give you peace of mind in the overall shutdown procedure that you should have on interference or need to wait on protection jobs to finish before shutting down other parts of the infrastructure.
As always, if you want more information on the Cohesity PowerShell module and other Cohesity developer integrations, check out the Cohesity Developer website.
