Solved

Configuring WORM on cloud storage

  • 13 June 2022
  • 7 replies
  • 440 views

Userlevel 3
Badge +11

Hi All,

 

Was documenting about the WORM activation on our cloud storage, from different threads here and using the documentation.

 

Came across different questions, which I hope will get some answer through this topic.

1 - On the link that follows, it’s stating that “Note: Once applied, the WORM functionality is irreversible”.

Does that mean when we activate the WORM on the storage through the workflow, we cannot change the retention ? We wanted as a first time test the WORM, with the setting of the retention of one storage policy copy on the storage pool as a test with 1 day only. Does that mean that we cannot change the retention of the workflow to something else ? Let's say 15 days.

 

2 - Same from the link, since our storage pool is using deduplication, it’s stated that the retention on the storage will be set twice of the one on the storage pool, our copies on the storage pool will be set to 15 days, does that mean the data will remain for 30 days on the storage without being deleted, after 15 days are passed with the data aging job ? If someone can clarify to me how this will work  between the CommServ and the Storage, especially regarding the data aging, we don’t want to end up with  a storage filling up quickly due to this.

 

Regards.

icon

Best answer by Collin Harper 13 June 2022, 20:26

View original

7 replies

Userlevel 4
Badge +12

@Commvault Engineer 

  1. Correct, WORM retention is permanent by design. Since the data is supposed to be immutable, retention cannot be altered at will. There is a process to lower or remove WORM retention but this requires a Support case where an authorization code must be provided by Commvault after a waiver is filled out by the organization.
     
  2. If your policy retention is set to 15 days the DDB must be set to seal every 15days. DDB sealing is done in the same interval as policy retention. Cloud WORM settings must be double the policy retention so that data doesn't get pruned before Commvault retention is up.
    For example, backups taken on day 15 have 15 day retention, preventing data from physically aging for 30 days will prevent data from being pruned from “underneath our feet” so to speak.
    For the second part of your question, we cannot micro-prune from cloud so sealing\macro-pruning is the only method of managing data. After the WORM retention is up (30 days in this scenerio) all of the data will physically prune.

    I hope this answers your questions.
Userlevel 3
Badge +11

Thanks a lot @Collin Harper for your quick feedback, still have some questions regarding these:

  1. It’s understandable that we cannot disable or lower the retention from the workflow, since this can be a vulnerability for the WORM, but still, can we increase the retention from the workflow at will, after setting it up the first time ? The main thing, is that, we want to test it before using it on Prod, we wanted to set it only on one storage policy copy that has a retention of 1 Day, then increase it to 15 Days after customer validates it.
  2. Understood after your explanation, had one more thing to ask. Are we obliged to set it up twice the storage pool retention ? As mentioned before, we want to prevent our storage to fill up quickly, so my question is, in case of our storage pool is having a retention of 15 Days, Can’t I set the retention on the workflow with same retention (15 days) so Commvault and Storage are aligned, or at least increase it for 1 or 2 days (16 days) ?

Thanks again Collin for your time.

 

Userlevel 4
Badge +12

@Commvault Engineer 

  1. Retention can be increased by running the workflow again with a higher retention value. It would probably be best to suspend jobs, seal the DDB, re-run the workflow with a higher value to prevent issues with blocks having mixed retention.
     
  2. No the WORM retention must be twice the policy retention to avoid data loss. Going back to the 15 day example, if you let data physically prune on day 15 any backups on day 15 would be restorable because all of the deduped data that ran on day 1 would be pruned.
    You would be pruning data for backups that are still within Commvault retention.
Userlevel 3
Badge +11

@Commvault Engineer

  1. Retention can be increased by running the workflow again with a higher retention value. It would probably be best to suspend jobs, seal the DDB, re-run the workflow with a higher value to prevent issues with blocks having mixed retention.
     
  2. No the WORM retention must be twice the policy retention to avoid data loss. Going back to the 15 day example, if you let data physically prune on day 15 any backups on day 15 would be restorable because all of the deduped data that ran on day 1 would be pruned.
    You would be pruning data for backups that are still within Commvault retention.

Thanks a lot, @Collin Harper For your prompt help.

Userlevel 4
Badge +12

@Commvault Engineer 

You’re welcome!

Userlevel 3
Badge +11

@Commvault Engineer

You’re welcome!

Hi @Collin Harper,

 

Hope this message finds you well!

Had a question regarding this configuration that we discussed months ago.

 

After setting the WORM lock as discussed, we noticed that our cloud storage space is filling up real quick (Almost reaching 100% of its space usage), we suspect that the pruning is not done properly.

 

From the SIDB logs, of the mediagents accessing the cloud storage, we can only find chunk deletion request being failed due to WORM retention (Which we suppose is the worm set at hardware level on the storage, and that is twice the one setup on Commvault side).

 

Do you have any idea what can be the cause ?

Kind regards.

Userlevel 4
Badge +12

Hello @Commvault Engineer 

This sounds correct. Commvault will still try to prune the data but encounter failures because the vendor WORM is preventing us from being able to.

 

Thank you,
Collin

Reply