Skip to main content
Question

Strange behavior of SQL cluster backup (caused Front-end license exceeded)



Hello Commvault Community,
 

I have a strange case where a connection loss occurred in the environment during an AG SQL backup, the Commvault system resumed the backup job for another attempt, but didn’t reset the Size of Application counter from the first attempt, which increased this parameter by x1.5 times, causing the Front-end license to be exceeded.
 

To clarify the situation, AG SQL in the case of Full Backup actually has 6.9 TB Size of Application - that's 22 databases. For example, a correctly performed backup tonight (from 21.01 to 22.01) for JobID [...]140, correctly recognized 6.9 TB Size of Application.

 

 


 

Last night (from 20.01 to 21.01) Full Backup was also performed and the network connection was interrupted (this isn’t the most important thing at the moment), then Commvault independently resumed the backup job in the second attempt, which ended correctly, but unfortunately the Size of Application from the first interrupted attempt was added to the second one, which was completed correctly.
 

This caused the AG SQL Full Backup job to indicate 11.1 TB instead of 6.9 TB according to the Size of Application parameter. Example of JobID [...]449:

 

 


 

This is important because in this environment where this happened there was a small  of Front-end licenses, which is why the available licenses were exceeded and the data protection tasks stopped working.
 

I would like to know if this is the correct behavior of the system, that it counts all attempts made within the same task, or maybe it should ignore the Size of Application parameter from the failed attempt in the event of an unsuccessful attempt.

Thanks in advance!

Kind Regards,
Kamil

3 replies

Forum|alt.badge.img+4
  • Vaulter
  • 21 replies
  • January 27, 2025

Hi ​@Kamil 

The issue you're experiencing with the Size of Application parameter showing an inflated size due to a network interruption and subsequent resume of the backup job is likely due to the accumulation of data sizes from both the interrupted and resumed backup attempts.

This is not typical behavior, as Commvault should only account for the latest successful backup size in the Size of Application parameter.

To address this, you may need to review the backup job details to ensure that only the data from the successful attempt is considered.
For more detailed guidance on managing and troubleshooting backup sizes, you can refer to the
https://documentation.commvault.com/2024e/expert/size_measures_for_virtual_machines.html


Forum|alt.badge.img+3
  • Vaulter
  • 11 replies
  • January 28, 2025

hi All

This is a tricky one as it all occurs under the same job - as you point out the first sequence succeeded in parts but then you had a critical communications failure and the shift occurred to the other AG replica to complete it successfully as you have it in the auto/failover mode. Which is critical to ensure you can satisfy your RPO to be recovery ready.

This scenario should be the exception case, if you are experiencing it frequently then you may need to check your configuration on why the network is dropping out.

The condition will automatically correct on the next Full, as the meter reflects the App Size on the latest Full ( or SF for VM, FS backups ) which allows the meter to reduce if the next Full is smaller.

For the immediate case, if you have exceeded your FET capacity rights - the system offers a safe-guard to allow you to reset to continue operations for a short period. 

ault.com/2024e/expert/resetting_license_capacity_in_commcell_console.html

Cheers

brock


Forum|alt.badge.img+3
  • Vaulter
  • 11 replies
  • January 28, 2025

Reply


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings