Skip to main content

Hi,

 

For data security I was told to do search on the WORM option at Primary copy level of our storage policies..

 

Just a bit of background of our environment, we have short data retention set on our Primary Copy - 35 days 1 cycle. My understanding is that this WORM option in storage polices work within Commvault software and no admin(or anyone) can delete backup jobs after it is enabled, and we have to wait for job to age out and then be pruned by commvault automatically.

 

Then I was advised that if I enable WORM, DDB for its storage policy will be sealed. A new DDB will be created automatically after rebaselined. So I have some questions below.

 

  1. is DDB sealing an automate process? i did enable WORM option more than a month ago for a storage policy for testing but I cannot see a sealed ddb under ‘Deduplication engines’.
  2. Our disk libraries are quite big (from 300 TB to 800TB). if we need to do the rebaseline every time, will this take long time and have impact on performance?
  3. With only 35 days 1cycle retention set for Primary copy, do we need to seal DDB? What is the purpose of sealing a DDB? I was told that there is micro-pruning involved to reclaim space back but I dont really know how it works and how WORM option will have impact on it.

Any idea or feedback would be greatly appreciated.

 

Thank you.

Hello @Boyi 

  1. Can you confirm if you used the Enable WORM workflow to enable WORM? Sealing should be configured automatically if you used the workflow. 
  2. Re-baselining will take a full cycle of backups. We have to re-write the unique data, which will happen as new backups run after the DDB has been sealed.
  3. Micro-pruning allows us to prune individual blocks but also requires us to modify the data. Since the data is protected by WORM, we cannot modify it, hence we cannot Micro-Prune. Since we cannot micro-prune WORM data, the DDB does need to be sealed periodically.

If you did not use the workflow to configure the WORM settings, it would be best to get a case opened with Support. Enabling WORM manually can cause problems and we would need to fill out a “Disable WORM” authorization and have it approved by our Legal Team. The Legal Team will provide an authorization code to remove the WORM so that it can be re-configured correctly with the workflow.

Configuring WORM Storage Mode on Cloud Storage - https://documentation.commvault.com/11.26/expert/9251_configuring_worm_storage_mode_on_cloud_storage.html

 

Thank you,
Collin

@Boyi 

If you are asking about the Worm Copy functionality which is enabled at the Storage Policy Copy level (Rather than Worm Storage which needs enabling / configuring at the the Disk Library level) then there is no need to seal your DDBs.

The Worm Copy functionality stops anyone from lowering the data retention or deleting jobs on the Storage Policy Copy. i.e. you cant delete the data from within the application. Data Aging and pruning operations continue as normal per the defined retention settings. 

With Worm Storage, the worm functionality is coming from the underlying disk technology which Commvault integrates with but to do so requires a different approach to data aging and pruning and thus the periodic sealing of the DDB. Think about how dedupe works - if you have worm storage, you do not want to deduplicate against a block of data that no longer has the worm lock applied..]

HTH 

Niall  

Hi guys,

 

Thank you for the prompt response.

@Niall we are doing the Worm Copy only within Commvault for our storage policies at Primary Copy level so it is good to know that we don't have to seal DDBs manually for that. I have marked your reply as the best answer.

 

Kind regards,

Boyi

So, for Worm copy in Primary Storage Policy is not mandatory to enabled through workflow ?

It works just by checking the “WORM copy” under Storage Policies properties?

 

@Nikos.Kyrm The Enable Worm Storage workflow is used to set up Worm Storage when disk based “Worm” functionality is being used. It enables the periodic sealing of the DDB to align with the disk based “Worm” functionality and enables the Worm Copy functionality on the associated Storage Policy Copies.

If you are not using disk based “Worm” functionality but wish to prevent anyone from deleting jobs, or lowering retention, from within the application then you are correct in saying it can be enabled by checking the “Worm Copy” option on the Storage Policy Copy. Note that it cant be ‘unchecked’ once enabled. 

HTH

Niall

 

Hello @Niall 

I come back to this topic about Commvault immutability.

Although o365 agents are still not supported for WORM Storage https://documentation.commvault.com/2022e/expert/9251_configuring_worm_storage_mode_on_cloud_storage.html

I assume that Worm Copy is the only way to protect these o365 backups, right?
Their Backup Repository is an Azure Blob Storage.

Best regards,
Nikos

Reply


Terms & ConditionsCookie settings