Skip to main content
commvault.com commvault.com

Overview 

In release 11.38 update pack 32,  we are introducing a new feature for both Software and SaaS database customer environments: log backup with caching for SQL, Oracle, and SAP HANA databases. This allows you to perform log backups at more frequent intervals and leverage a caching mechanism to securely and efficiently transfer transaction logs from the database server to backup storage. The Log Backup with Caching feature enhances database protection by enabling high-frequency transaction log backups—even during control plane/CommServe computer downtime. Logs are first written to a secure cache before being backed up to storage, allowing for data consistency and the potential to improve RPOs. 

This change will be enabled for new backup plans automatically and does not require action. Existing backup plans for SaaS customers will be updated over the coming months. Read through our FAQ below for more details.

 

Q: What is Log Backup with Caching?

Log Backup with Caching allows transaction logs to be dumped to a cache at frequent intervals (as low as 15 minutes), even when the Commvault control plane/CommServe computer is temporarily unavailable. Logs are then swept from the cache to backup storage using a secure, efficient pipeline​. 

📽️ We’ve created a quick Readiverse video that explains this feature available for customers and partners.

 

Q: Why was this feature introduced?

The addition of Log Backup with Caching helps to improve RPOs, maintain data protection during control plane/CommServe computer outages, and reduce the load on the control plane/CommServe computer by offloading log backup tasks to the client side​. 

 

Q: How does it work?

The process includes two phases: 

  • Dump Phase: Logs are written to a cache at defined intervals.
  • Sweep Phase: Logs are later transferred (swept) from cache to backup storage over Commvault’s encrypted and compressed Secure Data Transfer (SDT) pipeline​.

 

Q: What are the key benefits?

  • Improved RPOs with backups as frequently as every 15 minutes.
  • Resilience during control plane/CommServe computer downtime. 
  • Secure and compressed log transfers using SDT. 
  • Reduced load on the control plane/CommServe computer. 
  • Log backups included in SLA tracking and alerts​. 

 

Q: What use cases benefit from this feature?

  • High-transaction environments requiring frequent log backups. 
  • Unreliable connectivity to the control plane/CommServe computer. 
  • Control plane/CommServe computer resource constraints. 
  • Compliance-driven environments that need frequent, secure backups​. 

 

Q: How do I enable Log Backup with Caching?

  1. In the Commvault Command Center, go to Manage > Plans. 
  1. Create a backup plan or edit an existing one. 
  1. In the RPO section, configure log backup frequency and toggle the option to “enable log backups with caching.” 
  1. Assign the backup plan to your database sub-clients​. 

Note: Starting with release 11.38.26 (May 2025), this feature will be enabled by default for all new backup plans. 

 

Q: What happens to existing backup plans after 11.38.26?

Existing backup plans will continue to honor their current log caching setting and backup frequency. The Log Backup with Caching feature will not be automatically enabled or modified for these plans—you can update the setting manually if desired.

 

Q: Where is the cache stored?

The cache resides on the backup storage associated with the primary copy of the backup plan. No manual setup is needed—Commvault handles this automatically​ when caching is enabled.

 

Q: Are there limits or recommendations in terms of capacity that need to be accommodated when this feature is enabled?

No, customers do not need to worry about accommodating any additional capacity. Whatever is accommodated for the storage library should be sufficient.

 

Q: Is this supported where the primary storage leverages a cloud storage target, e.g. S3?

Yes, it is supported in cases where the primary storage leverages cloud storage as well. In this case the logs are cached to the cloud storage location itself.

 

Q: How does this affect log backup jobs?

Commvault jobs will run during the sweep phase (when logs are moved to storage), not during the dump phase.  This helps to reduce the overall number of Commvault log jobs visible within the GUI and improves system efficiency​. Dump backup jobs continue to be performed in the background to the cache.

 

Q: How can I monitor log backups with caching?

  • SLA Reports automatically include log backup SLAs when caching is enabled. 
  • Alerts like “Missed Log Backup SLA” can be configured​. 

 

Q: How does this impact my ability to do point-in-time restores?

There is no change to the restore process. Restores can be performed from any log backup.


Q: Are log backups with caching supported for Oracle Dataguard?

Not at present. This support is in the works and will be announced soon.

 

Q: What are the requirements?

Please refer to the official Commvault documentation for supported versions, agents, and prerequisites:

 

Q: Where can I learn more?

Refer to:

 

 

 

Thanks for sharing ​@Sudha Iyer! I have some questions:

  • It's not clear to me if this will be supported in case the primary storage leverages a cloud storage target like S3. Currently it is not supported, right?
  • If in case you use cloud strorage are there plans to introduce it for these kind of storage types as well? For example by using a local disk that is attached to the MediaAgent for caching.
  • Are there any recommendations in terms of capacity that you need to account for when this is enabled (by default as of 11.38.26)?
  • You mention you can monitor it through an alert called "Missed Log Backup SLA”". So, in case it does fallback to the caching mechanisme it thus doesn't count for a successful SLA score? 

Hi Onno,

 

  • It's not clear to me if this will be supported in case the primary storage leverages a cloud storage target like S3. Currently it is not supported, right?

pSudha] It is supported in case the primary storage leverages cloud storage as well. In this case the logs are cached to cloud storage location itself.

 

  • Are there any recommendations in terms of capacity that you need to account for when this is enabled (by default as of 11.38.26)?

  • You mention you can monitor it through an alert called "Missed Log Backup SLA”". So, in case it does fallback to the caching mechanisme it thus doesn't count for a successful SLA score? 

uSudha] Can you please elaborate on this question. I did not understand the question.

 

hello Sudha,

When you say, cache location is your primary copy location for eg: I use Storeonce as my target.

Now, by default the T logs will be going to the SO(Storeonce) directly, now where is this Cache created ?

 

hello Sudha,

When you say, cache location is your primary copy location for eg: I use Storeonce as my target.

Now, by default the T logs will be going to the SO(Storeonce) directly, now where is this Cache created ?

 

In the regular folders on your storage target (i.e catalyst in this case). A separate job then runs to scoop them up and commit them to the CommServe database.

The original post has been updated with a Readiverse video link which explain how this feature works.

Highlighting the links for customers and partners.

Reply


Terms & ConditionsCookie settings