Hi, We’re planning to use Commvault with on-prem disk storage that has the WORM feature enabled. At this moment, we know that when using WORM on the storage side, Commvault WORM must be also configured (WORM Copy property). I had an open Incident 221229-281 to describe additional settings. The support reply is to run a workflow, but this is specific to Storage Pools. That is not our case. We’re planning to use WORM with Secondary Copies with deduplication. We can’t use Storage Pools right now, because we already have some copies bound with a Global Deduplication Policy. What other settings do we need to?
Below I have a list of things that need to be done.
Could you confirm if is this correct and add something to it if necessary?
- Check WORM Copy property
- Disable the CV option “Prevent Accidental Deletion”
- Have Scalable Resources enabled during the aux copy job (same source)
- Follow the steps here (https://kb.commvault.com/article/55258) before running the first aux copy (same source)
- Set the WORM retention on the storage side to be twice the Storage Policy copy retention (I read another article that states to set the retention to 3x the Storage Policy Copy retention)
- Set DDB seal frequency to the same value as Storage Policy Copy retention
And what about the Start New Media and Mark Media Full On Success options (Auxiliary Copy Job Options) to prevent reusing?
On Storage side.
I think that I should Disable Automatically Delete since Commvault should purge the data after data aging. Right?
What about Lockout Wait Time (hours)?
Before enabling WORM at the storage we would recommend sealing the DDB store and then before any new activity to this storage, run WORM workflow.
Hello, I have some more very important questions in addition to the list above.
We are reviewing the storage documentation and just learned that, in a few words, the system protects Commvault files according to their timestamps and internal clocks. If Commvault updates the access and/or modification times of your data structures, the Storage System can reset those timestamps to pre-determined values.
Since we are thinking of working only with secondary copies (with dedupe enabled), in theory, only Auxiliary Copy jobs will write data to Mount Paths. Unless processes (or threads) open files for writing data and don't finish their work within a reasonable amount of time I don't see how this can cause us problems.
Of course we must remeber and understand some points:
Does anyone have anything to add?
These shouldn’t be updated. The point of WORM is that once the file is written it cannot be modified until the Lock retention is up.