Sealed DDB and WORM Pools

Question

It has been a while since i last read anything about WORM (Storage Lock) in Commvault and wanted to make sure I`m not misunderstanding or missing anything.

My general understanding is that once WORM Storage Lock is configured and retention criteria is met, DDB is sealed. Once DDB is sealed nothing else is written to that DDB.

New DDB is created and as per Arlie confirmation, the next job regardless of what the schedule policy may start (lets say an Incremental) that job gets automatically converted to Full Job so the baseline is estabilished. No issue until here unless Im missing something.

The above statement used to be in the documentation (not sure if Im just not finding it or it was rephrased) but I simple cant find.

Instead when looking at the documentation for WORM: https://documentation.commvault.com/2023e/commcell-console/recommendations_for_worm_storage_01.html it says "Add the ForceFullOnWORMDDBSeal additional setting to convert the next backup to synthetic full backup after sealing the DDB for WORM storage lock enabled storage pool"

And here is where I have some questions;

Is this saying that IF WORM is enable the additional setting MUST be entered to avoid an actual FULL baseline? And instead run a Synthetic Full?
If the above question is answered with a "Yes". We are not actually running a true Full where data is read from clients again, instead SF will read block/reference blocks already written to storage. Is this the new norm for WORM? When was it changed?
If answer to first question is "No" - how exactly are we running a Synthetic Full without having previously ran a Full and INC?
I am of the opinion that additional settings are "bandaids" - Does Commvault have plans to remove this and make it as part of the software when WORM is configured.
Not having to run an actual FULL after DDB is sealed is great. I`m just making sure Im understanding this correctly.

I think I am missing something here, so would be helpful to hear from the community.

Thank you

sbhatia · Accepted Answer

Hi ​@dude,I tried getting some insights from the Development team on the legit questions you asked, here is the response tailored with more explanations from my side:Q: With WORM enabled, is it mandatory to set ForceFullOnWORMDDBSeal to avoid a true Full backup and instead trigger a Synthetic Full after DDB sealing? A: No, it is not strictly mandatory. The ForceFullOnWORMDDBSeal setting should be applied only if your backup cycle does not naturally align with the DDB sealing schedule. If cycles, retention, and baseline backups are perfectly mapped to DDB seals, this is not required. It is a safeguard that ensures the next backup after DDB seal is a Synthetic Full, rather than a traditional Full, preventing unnecessary production read loads.Q: How does a Synthetic Full backup run if the previous DDB is sealed and no longer writable? How is a valid baseline ensured for Synthetic Full in this scenario? A: Once the DDB is sealed, the new backup jobs, including Synthetic Fulls - write signatures and references only to the newly created DDB. The Synthetic Full uses backup chain metadata to pull data directly from storage, not the sealed DDB. It creates new deduplication signatures in the new DDB for all referenced blocks, thus re-establishing a valid baseline using existing backup data on storage as its source. The sealed DDB is no longer consulted for dedupe operations, the baseline is rebuilt in the new DDB.Q: If the setting is not mandatory, how can a Synthetic Full backup run successfully without a prior Full and Incremental chain establishing the baseline? A: For a Synthetic Full to succeed, there must be an intact backup chain (previous Full or Synthetic Full and subsequent Incrementals) whose metadata can be referenced. If a chain is missing or corrupt, neither traditional nor synthetic Full can operate correctly. Administrators should ensure schedules provide periodic Full or Synthetic Full backups to maintain chain validity, especially around expected DDB seal dates.Q: Is reliance on such an additional setting a temporary workaround? Will future releases integrate this functionality natively? A: Today, the ForceFullOnWORMDDBSeal is an operational workaround. Product teams are aware and have optimizations in progress to automate Synthetic Full or backup scheduling in future releases, aiming to reduce manual configuration and better align chain maintenance with DDB lifecycle.Hope this helps :)

Damian Andre · Answer

Hey Dude,I’m not super knowledgeable on the WORM stuff myself - but I can confirm that if you seal a DDB it does not force a full backup - New DDBs are often associated with new storage policies or plans, which would be a full - but a new DDB on its own (e.g from a seal) does not - I think that is where Arlie got tripped up. We’ll get that fixed.If you switch storage policies to a “new” DDB, you get prompted to convert the next job to full (recommended as data will be across two different policies, which is not ideal).The team is looking into your WORM related questions :-)

Sign up

Login to the community

Scanning file for viruses.

This file cannot be downloaded