Skip to main content
commvault.com commvault.com

Hello All,

Prior to 11.30 the Enable WORM Storage Workflow was available to use that set the required Retention/Seal parameters on the Storage Pool and in addition, if applicable to the vendor, enabled a lock on the bucket.

https://documentation.commvault.com/2022e/expert/configuring_worm_storage_mode_on_cloud_storage.html 

This is no longer supported and is instead set on the Storage Pool. 

https://documentation.commvault.com/v11/essential/enabling_worm_storage_and_retention_for_cloud_storage.html

 

Unlike the 11.28 Documentation, I am unable to find information and clarification on if there is a process to configure the bucket lock settings directly from Commvault.  It was implied in 11.28, that the workflow would set this.

For GCP Storage “What Does the Workflow do? The workflow enables retention policy on the bucket.”

My questions would therefore be:

  1. Should/Can Bucket Lock be set by Commvault when setting up the Storage Pool in Commvault or is this to be set manually using the usual guidelines of double the retention?
  2. The 11.28 Documentation stated (I cannot find the equivalent in 11.32) that GCP was only supported with the lock at the bucket/container level. 
  • “Vendors who support only bucket/container level retention:
    • Google Cloud Storage
    • Oracle Cloud Infrastructure Object Storage”

When looking at the GCP Bucket settings in the GCP Console, there is an option to enable object based retention.  Is there a specific recommendation by Commvault for this - assume bucket level is still the option to go for?

Finally, is there a recommendation for any setting on buckets on creation in GCP.  I have had a look in the latest GCP white paper and couldn’t see anything specific.

The 11.28 documentation around the WORM workflow seemed a lot easier to follow than subsequent versions, though that said - maybe I am just not looking in the right place. 😏

 

Any advice appreciated, and thanks for your time.

Thanks

G.

Hello G,

Thank you for reaching out on this.  With changes in 11.30 and beyond we no longer require the workflow to set the necessary options on Cloud Storage,

Within 11.30 and 11.32 when the WORM lock tools are enabled for Hardware Lock, the software will automatically reach out to the Storage and set the appropriate WORM rules the first time it is written to.  Additionally, in 11.34 and beyond, we have added integration with Google Cloud Object Controls, for more granular pruning and a reduction in space bloat caused by traditional container level locks.

You can find the changed requirements here:

https://documentation.commvault.com/2023e/expert/configuring_worm_storage_lock_and_compliance_lock.html

https://documentation.commvault.com/2023e/expert/supported_vendors.html

 

For the changes in 11.34, you can review these documents:

https://documentation.commvault.com/2024/expert/configuring_worm_storage_lock_and_compliance_lock.html

https://documentation.commvault.com/2024/expert/supported_vendors.html

 

Let us know if you have any other questions.

 

Regards,

Josh

 Hey Josh,

 

thanks fo the response - much appreciated.

I have done some testing around the Hardware Lock enablement and although the Library in Commvault displays the ‘WORM Storage Lock; Status is ‘Enabled (Bucket Level Lock)’ - (Testing on 11.32),  the Properties of the bucket in GCP does not have any lock or retention applied (even after writing some data).  I need to troubleshoot this a bit further - is there a specific log file that details the attempt to apply the bucket settings so I can check the attempt or errors?  I’ve checked the credentials have all the permissions applied correctly, can provision new buckets from Commvault, write data etc so reasonably confident on that side.

Thanks in advance

G.

Hi All,

I wanted to update this community ticket for any future viewers which may be referencing this thread when attempting to configure WORM on their GCP environment.

Previous iterations of the “Enable WORM Storage” workflow have attempted to automatically set the cloud bucket/container level retention for vendors which do not support object level retention, however the most recent versions of this workflow will no longer do this for you. Instead, when the workflow is run, you will be prompted with a notification that recommends that you are required to manually set the bucket/container level retention on the cloud storage vendor side.

Documentation has also been updated to advise that for vendors which only support bucket/container level retention, this retention must be set manually on the cloud storage:

https://documentation.commvault.com/2023e/expert/configuring_worm_storage_lock_and_compliance_lock.html

“Bucket Lock:

  • Commvault will write data and objects will be locked as per the retention days set on the bucket/container on cloud vendor side.”

The documentation confirms all of the settings that Commvault is implementing within the Commvault environment to expect WORM retention on the storage vendor side, however we are not setting retention on the bucket/container.

 

Development made the decision to remove this from the workflow and want users to manually set the retention for bucket/container level retention going forward.

I suspect it’s possible this decision was made as there are numerous different cloud storage vendors which may have different API calls required for setting bucket/container level retention, and we want to remove responsibility of configuring this individually in the workflow code and certifying it for all of the different cloud storage vendors in the market.

Reply


Terms & ConditionsCookie settings