Skip to main content
Solved

Data aging on old WORM enabled primary copy

  • March 10, 2026
  • 1 reply
  • 26 views

Forum|alt.badge.img+3

Hello Community,
 

we recently switched our primary copy to an object lock (WORM) enabled storage pool.

After a while we noticed that the storage space will not be sufficient regarding the additional space required for deduplication.

Therefore we switched all clients to a new primary copy without object lock to let the data age out before going back to locked storage.

The data on the locked copy should now already age out but one cycle is stuck with “BASIC_CYCLES” because the copy was created with 1 cycle retention initially.

 

Is there an easy way to clean up this cycle for all clients?

I could already free up the jobs from our VSA backups by disabling the subclients and enabling the option to ignore cycle retention on disabled subclients, but this is not practical for all other clients.

 

Thanks in advance for your thoughts.

Best answer by Pradeep

Hi ​@Marcel_RE ,

When a storage policy copy is created with 1 cycle retention, Commvault's default behavior is to retain the last cycle of data indefinitely especially on WORM or Compliance Locked copies. This is due to the "BASIC_CYCLES" retention reason, which means the system is holding the last cycle as required by the retention policy.

This is expected behavior: since we always retain at least one complete cycle (a full backup and its dependent incremental/differentials) as long as the client is not retired or deconfigured.

If the client is still active and the copy is set to 1 cycle, the last cycle will always be retained. This is by design and cannot be bypassed unless the client is retired or deconfigured and the ignore setting is enabled.

1 reply

Forum|alt.badge.img+17
  • Vaulter
  • Answer
  • March 11, 2026

Hi ​@Marcel_RE ,

When a storage policy copy is created with 1 cycle retention, Commvault's default behavior is to retain the last cycle of data indefinitely especially on WORM or Compliance Locked copies. This is due to the "BASIC_CYCLES" retention reason, which means the system is holding the last cycle as required by the retention policy.

This is expected behavior: since we always retain at least one complete cycle (a full backup and its dependent incremental/differentials) as long as the client is not retired or deconfigured.

If the client is still active and the copy is set to 1 cycle, the last cycle will always be retained. This is by design and cannot be bypassed unless the client is retired or deconfigured and the ignore setting is enabled.