Decomissioning Servers from Commvault: Are You Doing it Right?

The reason for this post is that I often come across CommVault environments that have hosts which have not been decommissioned correctly. This results in the unnecessary consumption of both licensing and storage space/media. It seems that the correct way to decommission servers from Simpana isn’t something that gets highlighted enough during CommVault training. This also seems to be one of the first things people get wrong when they inherit a system. Backup administrators often complain that jobs aren’t being aged correctly, or they have unexpectedly used up all their licensing. Incorrectly decommissioned servers are the #1 reason for this.

Depending on how the server you are decommissioning is protected, will change how it needs to be removed in Simpana. Licenses may need to be released, and backup jobs may need to be cleaned up.

The following flow chart describes the considerations and procedures required to successfully decommission servers from CommVault:

decomissioning a server

Click to see full image.

Here are the procedures outlined in the flow chart:

A. Go through each installed agent and note down with which Storage Policies it is associated. It is important to do this first because after releasing the license this will become more difficult.

B. Right click on the host in the CommCell browser and select All Tasks -> Release License. More info is available on BOL. In completing this step you have now freed up the licenses utilised on this server. For people with capacity based licensing this will only be reflected when Data Aging is run (normally scheduled to run daily at 12pm).

C. Here is where most people get caught out. If you remember back to your CommVault training you will recall that retentions for copies are specified in days and cycles. Days are pretty straight forward and cycles refer to the number of complete backup cycles (new ones are started every full backup). Both need to be met before the job can be aged. Wait a minute, how can that be? The cycles dependency will never be met for the last full backup cycle on a deconfigured agent since it will never produce any new jobs. That’s right. Simpana will keep the last backup cycle (full + any incrementals) forever until you manually delete the jobs.

There are two solutions to this challenge:

I strongly suggest doing the latter, since it makes management much easier. It’s really how most people would expect the system to operate.

E. Simply right click on the subclient and select delete. Historic jobs will be aged as per normal using the configured days retention. Since this is subclient level stuff, cycles don’t apply, so you don’t need to worry about manually deleting any jobs. To restore VMs from these old backup jobs, do your Browse/Restore operation on the backup set, or alternatively browse history at the backup set level.

F. Browse the properties of the subclient associated with the VM, and delete it from the contents. For capacity based customers, licensing will be freed up when the subclient next runs a full backup.

I hope you found this useful, don’t hesitate to contact me with any comments or questions.

Serge Bakharev
Serge is an integration specialist at Perfekt with specialisation in backup, virtualisation, storage, and server infrastructure. He has a strong working knowledge of modern storage technologies, popular business applications, and networking, as well as the underlying operating system inner workings. He has worked in development previously, giving him unique insight into common backend processes and systems.


Need to make an informed decision? Contact a Perfekt specialist to get a free consultation.