Restore requirements and limitations for Oracle
Consider the following before you restore an Oracle snapshot:
The destination host where you wish to restore the snapshot must have the same Oracle version installed as that at the source.
If you are restoring the snapshot to a new location, verify the following:
Ensure that there is no database with the same instance name running on the target host.
The directories that are required to mount the application files are not already in use on the target host.
Disk-level restore to a new location fails if the NetBackup plug-in for Oracle is not configured on the target host.
In such a case, to complete the Oracle snapshot restore to a new location successfully, you must perform the restore in the following order:
First, perform a Oracle disk-level snapshot restore.
Ensure that you restore the disk snapshots of all the disks that are used by Oracle. These are the disks on which Oracle data is stored.
Then, after the disk-level restore is successful, perform the additional manual steps.
See Additional steps required after an Oracle snapshot restore.
In an Azure environment, it is observed that the device mappings may sometimes get modified after performing a host-level restore operation. As a result, the Oracle application may fail to come online on the new instance, after the restore.
To resolve this issue after the restore, you have to manually unmount the file systems and then mount them again appropriately as per the mappings on the original host.
If you are using the
/etc/fstabfile to store file systems, mount points, and mount settings, Cohesity recommends that you use the disk UUID instead of device mappings. Using disk UUIDs ensures that the file systems are mounted correctly on their respective mount points.Snapshots of application data residing on a filesystem that is part of an LVM type of partition are not supported. If you try to take a snapshot of such a filesystem, the following error is displayed:
*flexsnap.GenericError: Unable to protect asset *