commvault.com commvault.com
Solved

Deconfigure Clients with no Backup History

  • 29 March 2023
  • 4 replies
  • 425 views
R
Rank
Userlevel 1
Badge +6

I am trying to find a solution where we can automatically deconfigure clients which have no backup history.  While also making sure we don’t mistakenly deconfigure any MediaAgents/proxies/CS/etc.

 

We’re trying to implement a set of policies/settings that would result in decom of a server simply by disabling backup activity at the client level.

I want to enable the Data Aging MM parameter to ignore cycles on backup activity disabled, so that if we disable backup activity it would prune the data after 35 days.

Then I want the client to remain for some time and if it has no backup history, then I want to have it automatically deconfigured after X days.  Then we would turn on the option to delete deconfigured clients that have no protected data, so that things would eventually clean up automatically.

 

I am trying to find a setting to deconfigure clients which have no backup history - the closest thing I was able to engineer would be:

Smart Client Group

Deconfigure Client Workflow scheduled against that group.

 

But when trying to configure the smart group, the closest setting I can find is “Clients With No Archive Data” -- but it seems like that option only includes clients that are already deconfigured (Rules Available for Smart Client Computer Groups (commvault.com)).  So I’m also playing around with smart client computer groups where “days since last backup” are greater than 35 days and not associated to infrastructure group.  Also trying “client offline days” greater than X -- but that one seems to get the virtualization clients and index servers, which we do not want to deconfigure.

Does anyone have a better way to automatically deconfigure servers with no backup history?

icon

Best answer by SANAdmins 18 August 2023, 18:35

View original

4 replies

Damian Andre
Rank
Userlevel 7
Badge +23

I think you’re going to have to use groups of rules - one rule wont rule them all. Ha Ha. 😅

I think you are on the right track with “days since last backup” - you’ll need to add rules to filter out pseudiclients (discovered VMs) or index client (I think there are rules for that) until you have a client list that matches your requirements.I don't see anything cookie cutter that will make this easier other than what you have already discovered.

 

If you are already manually disabling the schedule or activity on a client, why not retire it at that time using the retire option? that could save you the headache of automating around a manual function anyway.

 

Chris Hollis
Rank
Userlevel 6
Badge +15

@RobAbate 
 

If retiring client feature doesn’t meet your needs - Only way I can see you get something like this is via a custom workflow which you coordinate with your CV account manager. These usually incur costs for design / creation however. 


Thanks,

Chris

R
Rank
Userlevel 1
Badge +6

Damian - we do not want to use the retire functionality because we often get decommission requests followed by requests to put them back into production (happens surprisingly frequently around here in MSP environment).  Therefore this option to disable backup activity seems to be the best option for our environment, as it would allow us the flexibility to quickly put things back into production if needed, while retaining the schedules and all other settings.

I assumed that the built-in ClientDeconfigure workflow was going to accept a client group as input (because why would I need a workflow to deconfigure just one client when I can simply do that interactively) - but of course, it only accepts one client as input.  If the workflow accepted a group it would work great and I would have the functionality working the way I want it to.

The “retire” feature does not meet our needs and tries to do too much at once.  Like I said, I’ve already got the hard part done - and I’ve got the clients I need to deconfigure contained within a group with data aged off.  So at that point I can just deconfigure them - which would just be cleanup as the data would be aged off already - so no urgency to deconfigure at that point.

I was really looking for another MM Data Aging parameter to accomplish this - there’s one to automatically delete deconfigured clients with no protected data - so the only missing link is a process to deconfigure them -- I want it to be tiered where activity is disabled for 35 days, then data is aged off, then it gets deconfigured and stays for 30 days and then is finally deleted.

I realize that this is not the way most customers would do things - but this is the way we want it to work for our environment and needs.

S
Rank
Badge

I found a workflow called “RetireClients” in the CV store and was skeptical, but now it works like a charm.  I create an auto-group for “Deleted VMs” and we have another auto group for CV clients with the word DECOM in their notes.  These are the two we focus on about 99% of the time as far as purging everything.  When you execute the workflow “RetireClient” it prompt for a Computer Group to delete the clients from and also has another checkbox for “Force Delete” which wipes any backup history away for clients in the group you directed it to.  If you do not check it, it will hold on to the data per your retention settings and age off as normal.  I was able to do major cleanup of 500 servers in less than 10 minutes - and this would have taken days by hand thanks to our favorite Java console.  The date on the workflow I have is 5/12/23 so I don’t know if that is when I deployed it or when it was modified.  Have a look.  I was presently surprised.  I hope it suits your needs.

 

Bryan

Reply


Terms & ConditionsCookie settings