Wednesday, October 13, 2021

IBM Cloud resource reclamations: Some more details and my best practices

Reclaim resources
This is a quick follow-up to my "To restore or delete" post in which I discussed IBM Cloud resource reclamations and shared some tricks. Today, I have some more details and also want to share with you my best practices on handling resources.

Reclamation states

As described in my previous post, you can list the pending resource reclamations with the CLI command ibmcloud resource reclamations. Here is a recent screenshot of running that command:

Resource reclamations in different states

The screenshot above shows several resource in my account which are SCHEDULED for reclamation. The target date indicates the scheduled deletion. The Cloudant database instance, shown as second from the bottom, is in the state RECLAIMING because I used "ibmcloud resource reclamation-delete" just some seconds before. The last entry, a Certificate Manager instance, shows RESTORE_FAILED and was kept beyond the target date. Thus, I could investigate further. After creating the screenshot, I used "reclamation-delete" to permanently delete it. Then, it was no longer available and shown in the list.

Lessons learned and best practices

Fully deleting a resource which is SCHEDULED always works, the ability to restore it depends on whether the original "context" is available. The RESTORE_FAILED in the scenario above happened because I deleted the service and its resource group. Thus, the service instance could not be restored and the process failed. 

Some services require a unique instance name. Depending on the service, instances scheduled for deletion might be considered for the uniqueness check. Reprovisioning the resource with the same name could fail.

Based on my experience with resource reclamations and cloud security, I developed my best practices for handling resources:

  • Provision and delete resource groups as separate steps, e.g., when automating deployments with Terraform or Schematics. That way, the resource group could stay around and would allow to restore deleted resources.

  • Apply a naming scheme that guarantees unique resource names. This avoids naming conflicts in teams, projects, or sometimes even across accounts. I usually try to include information about the project, the resource location, dates if applicable, and more.


Resource reclamations are a safeguard to not accidentally delete still used services and data. It is possible to retrieve details on those resources and restore them if needed. The devil is in the details - as usual. Thus, it is a good opportunity to look at your own best practices in how to provision and organize resources. I shared mine.

To read more on the topic, I would recommend these two:

If you have feedback, suggestions, or questions about this post, please reach out to me on Twitter (@data_henrik) or LinkedIn.