To restore or to delete: Working with IBM Cloud resource reclamation

Resource management

Over the past weeks, I provisioned many resources in my IBM Cloud account. Typical to cloud computing, I also deleted and re-provisioned service instances. As part of that work, I dealt with resource reclamation and sometimes restored services or made sure they were "hard deleted", immediately gone for good.

In this blog post, I am going to give a brief overview of resource reclamation in IBM Cloud and share some tips and tricks from my experience.

Overview: Resource reclamation

Cloud providers offer many types of services, ranging from computing over storage and databases to all kinds of AI systems or full software solutions. To use them, a service instance or resource needs to be provisioned. When they are deleted by the user, they could be instantly removed or put aside for a while and scheduled for reclamation at a later date. The latter is useful if the resource was deleted by accident or it was found to include still useful data. In that case and within a defined period, users could simply restore the resource without any provider support required.

Many services on IBM Cloud support resource reclamation. That is, when I delete a resource, it's state is moved from "active" to "scheduled reclamation". It is no longer available and billed, but it is kept around until the configured period is over. Until then, I could restore it, delete it ahead of schedule, or just wait.

Investigate reclaimed resources

To look at resources with pending reclamation, I typically use the command line environment, but of course an API is available, too.

ibmcloud resource reclamations lists all reclamations, ibmcloud resource reclamation returns details about a specific one. Similar commands exist to either restore or fully delete a resource.

Looking at reclamations, the command returns the reclamation ID and the resource instance ID and CRN together with the state and the time of scheduled reclamation (full deletion).

$ ibmcloud resource reclamations
List all resource reclamations under account a4ff89015fbbxxxxxxx85 as HENRIK...
OK

ID                                     Resource Instance ID                   Entity CRN                                                                                                            State            Target Time   
d8997670-e99a-40e6-a7ef-404c7540b916   5220710f-0af6-4f13-a4d8-0d6059f68aa7   crn:v1:bluemix:public:cloudcerts:us-south:a/a4ff89015fbbxxxxxxx85:5220710f-0af6-4f13-a4d8-0d6059f68aa7::   SCHEDULED        2021-09-29T09:21:14Z   

The reclamation ID can be used to obtain details on that reclamation. The resource instance ID serves as input for, e.g., ibmcloud resource service-instance. I use the latter to investigate the actual resource, to see details on when it was created. You need to specify the right resource group to retrieve the instance details. An issue I ran is when not only the resource, but also the resource group has been deleted. In that case, I resorted to using this resource controller API to obtain instance details:

curl -s -X GET https://resource-controller.cloud.ibm.com/v2/resource_instances/5220710f-0af6-4f13-a4d8-0d6059f68aa7 -H "Authorization: $TOKEN" | jq -r

Fully deleting a resource which is SCHEDULED always works, the ability to restore it depends on whether the original "context" is available. To give an example, if the original resource group has been deleted, then the restore fails. I have not tested other dependencies.

Conclusions

Resource reclamations are a safeguard to not accidentally delete still used services and data. It is possible to still retrieve details on those resources and restore them if needed. The devil is in the details - as usual.

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