Disk Caching for Frequent Log Backups

Applies to: Informix, Microsoft SQL Server on Windows, Oracle, Oracle RAC, and SAP HANA

If your current log backup schedule is hourly or several times a day, you can use disk caching of log backups to decrease the load on the CommServe computer. You can run log backups at a greater frequency, in a scalable manner, without adding to the workload of the CommServe computer.

Log backups continue to run, even when the CommServe computer is down for maintenance and when connectivity to the CommServe computer is disrupted. With disk caching enabled, you can set the log recovery point objective (RPO) to as low as 5 minutes.

Without disk caching for log backups, if you run transaction log jobs frequently, then you must manage those scheduled jobs and store the job data in the CommServe computer. However, with disk caching for log backups, the CommServe computer doesn't have to run frequent backup jobs throughout the day. Instead, log files are backed up at the desired frequency using native backup utilities, are cached to a mount point on the MediaAgent, and are available for database restores. The Scheduler runs only at the interval defined by the Use disk cache for log backups and commit every setting to ensure cached data is committed to the CommServe computer.

For Oracle and SQL Server agents, the frequency of checking to determine whether a log backup should run is governed by parameters defined for the database type. If a defined maximum time has elapsed (the Force a backup every setting on the GUI), a log backup is run if no backup was run during the elapsed time. For SAP HANA agents, when HANA initiates a log backup through the Commvault backint interface, the logs are cached to a mount point on the MediaAgent. At intervals defined by the Use disk cache for log backups and commit every setting, a scheduled job runs to commit to the CommServe computer all cached log backups made since the most recent scheduled job.

For the Informix agent, when a log backup operation is initiated through the onbar program, the logs are cached to a mount point on the MediaAgent. At intervals defined by the Use disk cache for log backups and commit every setting, a scheduled job runs to commit to the CommServe computer all cached log backups made since the last scheduled job. Application command line log backups do not initiate any job in the job controller for writing logs to disk cache. Commit jobs initiate the job and will be present in the backup history.

Any interactively submitted job that results in a log backup uses disk caching when the feature is enabled. The job history of these jobs displays an application size of 0 to prevent the size from being counted twice if capacity licensing is enabled.

If you enable the Use disk cache for log backups and commit every setting, backup windows, which define when backup operations run, are not applicable to database log backups using disk caching. This is because one goal of disk caching is to run disk caching backups as defined in the schedule, regardless of a CommServe computer's maintenance or downtime.

If you are already running automatic scheduled log backups and want to run disk caching of log backups instead, enable disk caching by selecting the Use disk cache for log backups and commit every checkbox, and enter the interval of time between each log commit operation to the CommServe computer.

Disk caching of log backups is also supported using a HyperScale X configuration. The following lists the CVFS versions necessary on HyperScale X to support disk caching:

• For SQL Unicode database support, the CVFS version must be 4.7.6 or greater.

• For other databases, the CVFS version must be 4.7.4 or greater.

For the procedure to create a log backup for a subclient, see Scheduling Database Log Backups Using Disk Caching.