Question

Decommisioning a DDB to reclaim space on the DDB SSD

  • 14 September 2021
  • 2 replies
  • 16 views

Userlevel 2
Badge +7

We want to use space on an SSD for a new DDB (horizontal scaling) and the old DDB is not being used. It only has jobs with long term retention as it was used for file archiving(onepass). The onepass jobs are not active anymore. Data only needs to be restored. If Commvault doesnt need the DDB for restores, how can I get rid of the DDB as we dont have any backups running.

Sealing could be an option. However BOL mentions:

The sealed DDB is automatically deleted only after all the jobs (with their data block signatures stored on the DDB) are aged or deleted and the corresponding volumes are deleted from the disk.

So the DDB is required for purposes other than the backup. 

https://documentation.commvault.com/commvault/v11/article?p=12591.htm

For now we will be moving the partition to a different drive. 

Any ideas?


2 replies

Userlevel 7
Badge +19

You are correct that you only need the DDB for restores.  You could just remove it and the store will seal and be marked corrupt, though it will attempt a reconstruction.

Why not move the DDB to something local?  If you never run another backup, then performance won’t be an issue.

Userlevel 2
Badge +5

Hey @neuwiesener,

 

The DDB is not actually required for restores, so deleting the directory will have no impact on your recoverability.
It is retained however to allow granular data aging.

 

If removed, we can only reclaim the disk space associated with this ddb once ALL jobs have aged. I.e. If retention is 7 Years, and the storage associated with this DDB is 100TB, you won’t see that 100Tb until the newest job in the DDB is atleast 7 years old.

Mike’s guidance though is best.

Since its archiver data wiith long term retention and we’ll only start the DDB up to perform data aging, its likely to be very rare that we need the IOPs.

I’d recommend moving the DDB off to spinning disk/san storage mounted to the media agent. It will perform horrendously, but it will be accessed so infrequently that this is likely never going to cause you any concern.

 

Cheers,

Jase

Reply