Skip to main content
Backup and restore methods available for Oracle server databases
Updated over a week ago

Enterprise Workloads Editions: βœ… Business | βœ… Enterprise | βœ… Elite

This section provides insights into the backup and restore methods used for Oracle server databases. Before Druva can back up your databases, you have to configure your databases for backup and restore. See, Quick steps to set up Druva to back up databases.

Backup methods

Full backup

After you configure databases for backup, Druva performs a full backup of the databases on your server hosts. When a full backup is triggered based on the backup policy, the Hybrid Workloads agent backs up database files, archived logs, control files, and the server parameter file in the database.

If your databases are getting backed up for the first time, the databases are backed up entirely. If your databases are not getting backed up for the first time, a full scan of the databases is executed but only the updates to your databases are backed up after deduplication is applied. When the backup job is successful, Druva creates a recovery point in your storage.

Incremental backup

When you configure databases for backup, Druva performs a full backup of databases on your server hosts. Druva performs all subsequent backups as incremental backups. When an incremental backup is triggered, the Hybrid Workloads agent requests information about databases that are updated. Druva backs up the changed data and creates a recovery point in your storage. An incremental backup can be triggered if a recovery point from a full backup exists. If a recovery point from a full backup does not exist, an incremental backup is automatically converted into a full backup job.

Recovery point created after every incremental backup is self-sufficient and can restore the entire server without depending on any other recovery point.

Archive Log backup

Druva allows you to perform archive log backups on your server hosts. When Oracle databases run in the ARCHIVELOG mode, the databases make copies of all online redo logs after the databases are filled. The changes made to the database after the backup are stored in the archive logs. Druva backs up such archive logs and helps you to recover your database transactions lost during any server or network failures.

You can define a backup schedule for archive logs while creating backup policy and specify the interval at which Druva should back up archived logs. The default value is 1 hour. However, Druva allows you to provide value in the range of 15 minutes to 12 hours.

When a full backup is triggered based on the backup policy, the Hybrid Workloads agent executes a full scan of all the databases included in the backup and backs up database files and archived logs. Druva then continues to trigger archive log backups separately based on the schedule defined in the backup policy. You can track the archive log backup jobs on the Jobs tab.

Druva allows you to restore your databases to any point-in-time between the available range of the archived logs. It is a useful, lightweight approach to backup and restore. Archive log backups are incrementally triggered after a full backup job has completed, and a recovery point exists. The archive log is backed up every few minutes based on your settings.

Archive log backups initiated by the Oracle on-demand backup API

There could be situations where an API-initiated Oracle archive log backup coincides with an archive log backup running or scheduled to run from the Phoenix Management Console. The following table explains the scenarios and the API-initiated archive log backup behavior.

Scenario

Behavior of the API-initiated archive log backup

No archive log backups are running in the Phoenix Management console, and you initiate an Oracle archive log backup using the on-demand backup API

A new API-initiated archive log backup is created. This backup runs once and returns the job ID.

An archive log backup for the Oracle database is running in the Phoenix Management console, and you initiate another Oracle archive log backup using the on-demand backup API.

The archive log backup in the Phoenix Management Console continues to run and the API returns the job ID of this backup.

An archive log backup for the Oracle database is in progress with the next attempt scheduled to run again in x minutes/hours, and you initiate another Oracle archive log backup using the on-demand backup API

The archive log backup in the Phoenix Management Console is canceled, and the API initiates a new archive log backup.

This backup runs repeatedly as per the frequency defined for the archive log backup schedule in the associated backup policy. This archive log backup continues to run until the next full or incremental backup of the backup set. The API returns the job ID of this newly triggered backup.

Restore methods

Restore databases from recovery point

Druva allows you to restore databases from the warm recovery points that are stored in the Druva Cloud and cold recovery points stored in the AWS glacier. The databases can be restored to the original Oracle server host where the databases were backed up or to a different Oracle server host. For more information on how the recovery point restore works, see the Restore an Oracle database from a recovery point.

Restore databases to a point in time

When Oracle databases run in the ARCHIVELOG mode, the databases make copies of all online redo logs after the databases are filled. Druva backs up such archive logs, and you can use it to restore your databases to any point-in-time between the available range of the archived logs. It is a useful, lightweight approach to backup and restore. Archive log backups are incrementally triggered after a full backup job has completed, and a recovery point exists. The archive log is backed up every few minutes based on your backup schedule settings.

Druva uses the recovery point and the archive logs that were logged, to perform a point-in-time restore. When you restore the database using archive logs, Druva restores databases to the last available committed transaction before the specified point-in-time. For more information on how the point-in-time restore works, see the Restore an Oracle database to a point-in-time.

Did this answer your question?