Skip to main content
Solved

WORM data aging: Unfinished cycle in sealed DDB

  • September 24, 2026
  • 4 replies
  • 21 views

Forum|alt.badge.img+4

We have a primary copy which uses a deduplicated WORM enabled cloud storage pool as a target.
Therefore we have frequent sealing of the DDB so the data can be aged and block references are cleaned up.

I just recently discovered a client which for some reason had not started a synthetic full backup for two months despite being assigned to a plan where a synthetic full is configured.

Because of that a whole DDB generation is now blocked from aging because of the cycle dependency.

Is there an option to fix these kind of situations afterwards?
I was thinking about a synthetic full backup which only uses incrementals up to a user defined time so the cycle stays short.

As we are currently still on 11.40: I also read that there are improvements in data aging on WORM enabled pools which would enable pruning on job level rather than a whole DDB.
Would this change already prevent my current situation in advance?
From my understanding the DDB would still stay but only the blocks referenced by this one client would be retained on disk.

Best answer by Pradeep

Hi ​@Marcel_RE ,

I don’t find any specific requirements. However, the option is available from command center.

4 replies

Forum|alt.badge.img+17
  • Vaulter
  • September 25, 2026

Hi ​@Marcel_RE ,

When a synthetic full backup is not run for an extended period, the backup cycle remains open, and all jobs in that cycle including the DDB generation are retained until the cycle is closed.

This is by design to ensure recoverability. On WORM-enabled pools, macro pruning is used, meaning the entire DDB store is retained until all jobs in the cycle are eligible for aging. Improvements for job-level pruning on WORM pools are being developed, but as of 11.40, macro pruning is still the default.
 

At this time, I could not find an option to retroactively create a Synthetic Full backup that includes incremental backups only up to a user-defined point in time to shorten an existing backup cycle.

The Deduplication Database and all backup jobs associated with the current cycle are retained until the cycle is completed by either a Synthetic Full backup or a Traditional Full backup. Once the cycle is closed, the standard retention and aging processes can proceed as designed.

For now option is to run a new traditional full backup for the affected client. This will start a new backup cycle, allowing the previous cycle and its DDB generation to become eligible for aging once all jobs in that cycle meet retention.

Document for ref: https://documentation.commvault.com/2023e/commcell-console/synthetic_full_backups.html


Forum|alt.badge.img+4
  • Author
  • Apprentice
  • September 25, 2026

Hi ​@Pradeep,

I am aware of the functionality of WORM data aging and the implications of cycles for the most part.

So I will have to wait and monitor my clients so this doesn’t happen again.

I just noticed I forgot to mention that my question regarding WORM data aging optimizations was in regards of version 11.44 which we want to update to later this year.
Are the improvements for job based pruning already implemented in there and what are the requirements especially when upgrading with an exisiting WORM pool?

 

Thanks in advance!


Forum|alt.badge.img+17
  • Vaulter
  • September 25, 2026

Hi ​@Marcel_RE ,

You can proceed with planning the upgrade to the latest LTS SP44 release. At this time, I could not find any specific details regarding requirements or enhancements related to job-based pruning.

I will further verify whether there are any new changes, improvements, or prerequisites associated with the job-based pruning feature in SP44, particularly for environments with existing WORM pools, and provide an update.


Forum|alt.badge.img+17
  • Vaulter
  • Answer
  • September 25, 2026

Hi ​@Marcel_RE ,

I don’t find any specific requirements. However, the option is available from command center.