To validate that the clone recovery runs through last available log, we created a small test table and inserted a row. The test data would be recovered after a full recovery to last available log.

Log into SnapCenter as a database management user ID for Oracle. Navigate to the Resources tab, which shows the Oracle databases being protected by SnapCenter.

Select the Oracle log resource group and click Backup Now to manually run an Oracle log backup to flush the latest transaction to the destination in the cloud. In a real DR scenario, the last transaction recoverable depends on the database log volume replication frequency to the cloud, which in turn depends on the RTO or RPO policy of the company.

Asynchronous SnapMirror loses data that has not made it to the cloud destination in the database log backup interval in a disaster recovery scenario. To minimize data loss, more frequent log backup can be scheduled. However there is a limit to the log backup frequency that is technically achievable.

Select the last log backup on the Secondary Mirror Backup(s), and mount the log backup.

Select the last full database backup and click Clone to initiate the clone workflow.

Select a unique clone DB ID on the host.

Provision a log volume and mount it to the target DR server for the Oracle flash recovery area and online logs.

The Oracle clone procedure does not create a log volume, which needs to be provisioned on the DR server before cloning.

Select the target clone host and location to place the data files, control files, and redo logs.

Select the credentials for the clone. Fill in the details of the Oracle home configuration on the target server.

Specify the scripts to run before cloning. Database parameters can be adjusted if needed.

Select Until Cancel as the recovery option so that the recovery runs through all available archive logs to recoup the last transaction replicated to the secondary cloud location.

Configure the SMTP server for email notification if needed.

DR clone summary.

Cloned DBs are registered with SnapCenter immediately after clone completion and are then available for backup protection.

Validate the last test transaction that has been flushed, replicated, and recovered at the DR location in the cloud.

Configure the flash recovery area.

Configure the Oracle listener for user access.

Split the cloned volume off of the replicated source volume.

Reverse replication from the cloud to on-premises and rebuild the failed on-premises database server.

Similarly, to validate that the SQL clone recovery ran through last available log, we created a small test table and inserted a row. The test data would be recovered after a full recovery to the last available log.

Log into SnapCenter with a database management user ID for SQL Server. Navigate to the Resources tab, which shows the SQL Server protection resources group.

Manually run a log backup to flush the last transaction to be replicated to secondary storage in the public cloud.

Select the last full SQL Server backup for the clone.

Set the clone setting such as the Clone Server, Clone Instance, Clone Name, and mount option. The secondary storage location where cloning is performed is auto-populated.

Select all log backups to be applied.

Specify any optional scripts to run before or after cloning.

Specify an SMTP server if email notification is desired.

DR clone summary. Cloned databases are immediately registered with SnapCenter and available for backup protection.

Monitor clone job status.

Validate that last transaction has been replicated and recovered with all log file clones and recovery.

Configure a new SnapCenter log directory on the DR server for SQL Server log backup.

Split the cloned volume off of the replicated source volume.

Reverse replication from the cloud to on-premises and rebuild the failed on-premises database server.