Skip to main content
SnapManager Oracle

What restore preview plans are

Contributors NetAppZacharyWambold
PDFs

SnapManager provides restore plans before and after a restore operation is completed. The restore plans are used to preview, review, and analyze regarding different restore methods.

Structure of the restore plan

The restore plan consists of the following two sections:

  • Preview/Review: This section describes how SnapManager will restore (or has restored) each file.

  • Analysis: This section describes why some restore mechanisms were not used during the restore operation.

The Preview/Review section

This section shows how each file will be or has been restored. When you view the restore plan before a restore operation, it is called a preview. When you view it after a restore operation is completed, it is called a review.

The following preview example shows that the files are restored by using storage-side file system restore and storage-side system restore methods. To determine why all the files would not be restored by using the same restore method, see the Analysis section.

Preview:
The following files will be restored completely via: storage side full file system restore
E:\rac6\sysaux.dbf
E:\rac6\system.dbf

Each restore method has one subsection that contains information about the files that can be restored using that restore method. The subsections are ordered according to decreasing levels of storage method efficiency.

It is possible for one file to be restored by multiple restore methods. Multiple restore methods are used when the underlying logical unit numbers (LUNs) used for a file system are spread among different storage system volumes and some volumes are eligible for volume restore, while others are not. If multiple restore methods are used to restore the same file, the preview section will be similar to the following:

The following files will be restored via a combination of:
[storage side file system restore and storage side system restore]

The Analysis section

The Analysis section presents the reasons why some restore mechanisms will not be or were not used. You can use this information to determine what is required to enable more efficient restore mechanisms.

The following example shows an Analysis section:

Analysis:

The following reasons prevent certain files from being
restored completely via: storage side full file system restore
   * LUNs present in snapshot of volume fas960:
        \vol\disks may not be consistent when reverted:
        [fas960:\vol\disks\DG4D1.lun]
     Mapped LUNs in volume fas960:\vol\disks
        not part of the restore scope will be reverted: [DG4D1.lun]

Files to restore:
     E:\disks\sysaux.dbf
     E:\disks\system.dbf
     E:\disks\undotbs1.dbf
     E:\disks\undotbs2.dbf

* Reasons denoted with an asterisk (*) are overridable.

In the example, you can override the first failure either from the command-line interface (CLI), or by selecting Override in the graphical user interface (GUI). The second failure about mapped LUNs in the volume is mandatory and not overridable.

You can resolve checks by doing the following:

  • To resolve a mandatory check failure, change the environment so that the check will pass.

  • To resolve an overridable check failure, you can change the environment, or override the check.

    However, you must be careful because overriding the check can result in undesired consequences.