How It Works

To perform instant recovery, Veeam Explorer for Oracle uses the Veeam Explorers Recovery Service. The service is installed on the backup server and every mount server deployed in the backup infrastructure, and runs in the background. During instant recovery, Veeam Explorer for Oracle uses the service running on the mount server associated with the backup repository. This removes the necessity to keep Veeam Explorer for Oracle running during an entire instant recovery session. Once you have started an instant recovery session, you can close Veeam Explorer for Oracle and then launch it later when necessary.

When you start the instant recovery session in Veeam Explorer for Oracle, the following happens:

  1. Veeam Explorer for Oracle uses backup files to publish the database on the target production server directly from backup.
  2. While the published database is online, Veeam Explorer for Oracle starts to create a copy of the database on the target Oracle server.
  3. After the database is published, all changes to its database files are saved in the write cache.

[For Windows-Based Oracle server] The instant recovery write cache is stored on the mount server. You can view and change the write cache location in the mount server settings. For more information, see the Specify Mount Server Settings section of the Veeam Backup & Replication User Guide.

[For Linux-Based Oracle server] The instant recovery write cache is stored in the /var/tmp folder on the target server.

  1. After all database files are copied to the target server, Veeam Explorer for Oracle uses archived redo logs to synchronize changes in database files.
  2. After synchronization, you can switch over to the up-to-date copy of the database on the production server. Depending on the option you choose, switchover starts in one of the following ways:
  • Automatically, immediately after synchronization
  • Automatically, according to a specified schedule
  • Manually

During switchover, Veeam Explorer for Oracle does the following:

  1. Stops the published database.
  2. Uses redo logs to synchronize differences between the published database and the copied database files.
  3. Drops the published database.
  4. Starts the recovered database.

Instant recovery session is resilient to network disruption, backup server or mount server crash. If anything disrupts the restore process, the restore process stays in the waiting mode and performs 10 automatic retries every 5 minutes. If the retries fail, you can launch retry after the server or network is up.