# 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 backup 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 backup 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 backup plan.

  You can delete all backup schedules including the default incremental backup job. A backup plan without any backup schedules will will not have an RPO. You can associate such backup plans without an RPO to entities that run backups on demand. For example, you can associate a backup 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.

## Serverless Log Backups

Serverless log backups are available for the following agents:DB2, DB2 MultiNode, Informix, Microsoft SQL Server on Linux, Microsoft SQL Server on Windows, MySQL, PostgreSQL, Oracle, Oracle RAC, SAP HANA.

Note

Serverless log backup functionality is enabled by default on newly created plans.

If your current log backup schedule is hourly or several times a day, you can use Serverless 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 Serverless log backups enabled (Serverless log backups option) the log recovery point objective (RPO) can be set to as low as 5 minutes.

With Serverless log backups enabled, any interactively submitted job that results in a log backup uses Serverless log backups. 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 run, do not apply to database log backups that use Serverless log backups. One of the goals of Serverless log backups is to ensure they run according to their defined schedule, regardless of CommServe computer maintenance or downtime.

If you want to enable Serverless log backups, all clients, except the clients that have the SQL Server agent, must have indexing enabled. For more information, see Indexing.

Note

- The Serverless log backups of database log backup is supported only for MySQL traditional backup. To enable this setting, you need to enable $EnableDumpSweepFeatureForMySQL.

- The support for Serverless log backups functionality is not available for MySQL Cluster and Proxy Backups mechanism.

- Enabling the Serverless log backups feature will update archive_command to copy logs to MediaAgent. To append it to existing archive_command instead of overwriting it, set the bPreserveArchiveCommandWithDumpSweep under PostGres to 1.

- The Live Sync Replication support is not available for PostgreSQL instance with Serverless log backups enabled.

## 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 backup plans.

## Synthetic Full Schedules

Synthetic full schedules are automatically managed in the backup 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.

Note

Each backup serves as a full recovery point for compliance and regulatory purposes. For disk and cloud storage, synthetic fulls function as a garbage collection process and do not create new recovery points.

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 backup 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.

×

Loading...