Changes in version 11.36

Wow, we recently upgraded to 11.36 and i was not aware of this. I will change the schedule back to daily in our enviorment. I’ve been working with commvault for the last 10 years more or less and don’t see any reason why you would not back up your ddb’s each day.

A corrupted ddb in a big enviorment that’s not backed up each day could possibly be a nightmare to restore.

With version 11.36, the default backup schedule changed from daily to once every three days based on field feedback regarding resource requirements for DDB backups. To support this decision, we conducted a study comparing recovery times for daily versus three-day backups. The results demonstrated that a three-day schedule offers a well-balanced engineering compromise, optimizing resource usage while maintaining acceptable recovery times. This change is feasible due to optimizations in the DDB recovery process, which help minimize recovery times.

Hi,

Thank you @ManojKVijayan, for the detailed explanation.

This is quite surprising. As @Kim Andre mentioned in his response, a corrupted DDB in a large environment that isn't backed up daily could be a nightmare to restore.

Forcing such a change during version upgrade without considering the size of the environment is very risky. 

Not every environment is the same, and not every DDB is the same.

Providing a workflow that analyzes the system and offers optimization suggestions for the DDB ( like reducing the frequency of the DDB backups ) would be a much more suitable approach.

I agree with DDB backups 2 times a day.   I want to minimize my rebuild time in the event of an issue.

​@TNO, ​@Farmer92,  Thank you for your feedback. We understand that the optimal schedule for DDBs may vary depending on the DDB size and environment. Based on the information previously provided, the general recommended frequency remains three days. 
However, this schedule can be adjusted as needed to best suit your environment. Please note that if you set a custom frequency, we will not modify the schedule automatically in the future.

​@ManojKVijayan  how big was your test enviorments in the study? Our biggest client is a filecluster at 2PB in size with several millions of files and for this 3 days between the ddb backups is a situation i rather not put myself in in case of a ddb recon.

I think what matters more than the total size is the change rate. That is the applicable measure that would impact recovery. Enabling the option for prune logs on the DDB (should be on by default) is also a major factor and helps supercharge reconstructs.

As Manoj mentioned, you can certainly decrease the interval between DDB backups for faster recons if your environment has a large change or rate.