Differentiated Retention Policies for SQL in Application-Aware Mode (Agentless)

Good Day ​@mahmoud Hatira,
 

Thanks for the detailed questions. Here’s some clarity on what is and isn’t possible today with Application-Aware SQL backups in Commvault.
 

1. Is it possible to configure differentiated retention policies in native Application-Aware mode?
 

Not at this time. Application-Aware SQL backups run at the VM level and use one storage policy and one retention rule for both data (full) and transaction log backups.

Per the documentation: https://documentation.commvault.com/11.40/commcell-console/microsoft_sql_server_requirements_for_application_aware_backups.html

“For application-aware backups, different storage policies for data and for transaction logs are not supported by default. When application-aware backup jobs run, the log storage policy is set to be the same as the data storage policy.”

If you need separate retention policies, that capability exists only when using the in-guest SQL Server agent, where you can create separate subclients and assign individual storage policies.

2. Is there a solution through the Commvault REST API to manage this programmatically?
 

Unfortunately, no. The REST API exposes subclient and storage policy associations, but Application-Aware mode still enforces a single unified retention for both full and log backups. It does not allow programmatic separation of storage policies for these job types.

There is an advanced configuration (SkipStoragePolicyAssocForTLBackup: https://documentation.commvault.com/additionalsetting/details?name=SkipStoragePolicyAssocForTLBackup) that allows assigning a different storage policy for logs, but:

• It is not enabled by default

• It requires additional setup on the VSA proxy

• It does not provide separate retention control beyond what the storage policy itself enforces

So it’s not a real solution for differentiated retention.

3. What would be the best practice to optimize storage in this context without installing an agent?

If you must stay agentless:

• You are limited to a single retention period for both full and log backups.

• Your only tuning option is to choose the shortest required retention that still meets your compliance or recovery requirements.

If you truly need:

• Short log retention (e.g., 7 days)

• Long full retention (e.g., 30+ days)

Then the best practice is to use the in-guest SQL Server agent. It is the only supported method that allows full separation of backup types, subclients, storage policies, and retention.
 

Recommendations

• For actual storage optimization and real retention flexibility, deploy the Commvault SQL Server agent in-guest.

• If agentless is mandatory, choose a compromise retention period and understand the architectural limitation.

Hope this helps out with the information, let us know if any additional questions - Thank you!