Configurations for RPO

RPO (recovery point objective) backups are based on intelligent automatic scheduling. The RPO is defined as the maximum amount of time during which data is not backed up and as a result can be lost. The frequency of backup jobs configured in a server plan define the RPO.

To get started, specify the following options in a plan. After you specify the following options, automatic schedules and dynamic priorities are used to achieve your RPO.

• Backup frequency: The frequency of backup jobs. By default, an incremental backup job runs everyday at 9:00 PM according to the time zone of the client.

  You can modify the default backup job schedule, or click Add and schedule additional full, differential, or incremental backup jobs. When a server plan has multiple backup jobs the most frequent backup job or the least amount of time between backup jobs is considered as the RPO of the server plan.

  You can delete all backup schedules including the default incremental backup job. A server plan without any backup schedules will will not have an RPO. You can associate such server plans without an RPO to entities that run backups on demand. For example, you can associate a server plan without an RPO to an SQL instance and run backups on demand.

• Backup window: The days and times when an incremental or differential backup job can run.

• Full backup window: The days and times when a full backup job can run.

Disk Caching of Database Log Backups

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 way, without adding to the workload of the CommServe computer. Log backups continue to work even if the CommServe computer is down for maintenance or if connectivity to the CommServe computer is disrupted. With disk caching enabled (Use disk cache for log backups option) the log recovery point objective (RPO) can be set to as low as 5 minutes.

With disk caching enabled, any interactively submitted job that results in a log backup uses disk caching. 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.

Backup windows, which define when backup operations are to be run, do not apply to database log backups using disk caching, 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 want to enable disk caching of log backups, all clients, except the clients that have the SQL Server agent, must run Indexing Version 2. For more information, see Indexing Version 2.

The disk caching of database log backups is available for the following agents: Informix, Microsoft SQL Server on Windows, Oracle, Oracle RAC, SAP HANA, DB2, DB2 MultiNode and MySQL.

Schedules

• An incremental backup schedule is configured to automatically convert to a full backup job based on Commvault backup conversion rules.

• A synthetic full backup schedule is configured to be an automatic schedule.

• A full backup schedule is configured manually. This schedule applies only to server plans.

Synthetic Full Schedules

Synthetic full schedules are automatically managed in the server plan based on basic retention, extended retention, and selective copy settings. Synthetic full jobs are automatically run as needed to meet the above configuration, or when space reclamation warrants it.

Examples:

1. If extended retention rules are setup to retain Monthly Fulls with the option First Full Backup, a synthetic full is automatically scheduled to run on the first of every month.

2. If a copy is added to copy Weekly Fulls with the option Last Full backup, a synthetic full is automatically scheduled to run at the end of every week.

Note that when multiple configurations exists for extended retention and copy, the system chooses the minimum configuration (that is, the most frequent) to schedule the synthetic full.

Automatic Backup Level

For all database agents, the jobs from the incremental schedule are automatically converted to a full backup job every 7 days.

For SQL agents only, a differential backup job runs everyday and converts to a full backup job every 7 days.

• You can modify the full backup frequency in the server plan.

Dynamic Priority

Using machine learning and the following criteria, the dynamic priority intelligently prioritizes backup jobs:

• Strike Count: The strike count for a subclient is defined as the number of failures that occurred since the most recent successful backup job of the same backup level. The strike count is computed dynamically.

• Estimated Completion Time: The estimated completion time is calculated based on previous backup job patterns of the same backup level on the subclient. The estimated completion time is calculated using machine learning.

• Priority Calculation: When backup jobs have equal priorities at the operation, client, and agent levels, the subclient that has the greater strike count is prioritized. If backup jobs also have equal strike counts, the subclient that has the higher estimated completion time is prioritized.

Important Things to Know About a Recovery Point

• The recovery point for a subclient is the start time of the most recent successful backup job. The recovery point for a client is the earliest recovery point of all subclients. You can recover all the data on the client computer that was created before the recovery point.

• Jobs that start later than the recovery point and fail are not included in the calculation of the recovery point.

• The creation of a new recovery point is neither dependent on the previous recovery point nor related to the RPO.