Summary
Snapvault restore, IA (iSCSI) map, or BMR restore from a secondary filer that is a SnapMirror destination, fail.
Symptoms
If you are attempting to Snapvault restore data from an 'Alternate Secondary' that is in the Snapmirrored state, you may see errors in the job log similar to the following:
127.0.0.1 sssvh Fri Dec 01 16:07:53 2006 SNBSVH_240N Task 1 NDMP_LOG: id(1,448), type(NDMP_LOG_WARNING), text(SVP:OSSVNegotiateRestoreRequest() failed:[OSSV_NEGOTIATION_ERR][Source dataset does not exist].)
127.0.0.1 sssvh Fri Dec 01 16:07:53 2006 SNBSVH_240N Task 1 NDMP_LOG: id(1,448), type(NDMP_LOG_WARNING), text(SVP:restore failed requesting [syncui.txt] from Secondary.)
127.0.0.1 sssvh Fri Dec 01 16:07:54 2006 SNBSVH_240N Task 1 NDMP_LOG: id(1,448), type(NDMP_LOG_NORMAL), text(SVP:Restore is done [0].)
127.0.0.1 sssvh Fri Dec 01 16:07:54 2006 SNBSVH_240N Task 1 NDMP_LOG: id(0), type(), text(NDMP_SVP_NOTIFY_RECOVER_BACKUP operation failed. Error(7, NDMP_IO_ERR); Rseq(1))
127.0.0.1 sssvh Fri Dec 01 16:07:54 2006 SNBSVH_973E Recover backup for(C.alternate) failed with exception: <EXCEPTION CATEGORY="BEXEXCEPTION"><CODE>501</CODE></EXCEPTION>
If you are attempting an IA map from an 'Alternate Secondary' that is in the Snapmirrored state, you may see an error similar to the following:
If you are trying to BMR a snapshot from a volume that is in the Snapmirrored state, you may see a failure similar to the following:
Resolution
Filer volumes that are SnapMirror destinations are put into a special "SnapMirror" state that can at times be difficult to work around. A SnapMirrored volume can result from creating a SnapMirror relationship between two NetApp Filers, or from an 'smtape' (SnapMirror to tape) restore operation.
This is the behavior of your Filer, and not a problem specific to DPX. You can check the status of SnapMirror entities by using the snapmirror status command from the ONTAP command line. Volumes that are locked will be displayed with status Snapmirrored.
SnapMirror destinations are intended to be immutable copies of data from a primary Filer. Typically these SnapMirror destinations are synchronized automatically, but they can also be updated on a schedule or by manual request.
When volumes are locked in the SnapMirror state, they cannot be updated in any way unless you break the SnapMirror relationship.
Various operations within DPX including Snapvault restore, IA map, and BMR restore, require that the volume be in a writable state so that various application-level data can be maintained. Since a SnapMirror destination is read-only, any operation that requires the creation of application-specific data will fail.
The easiest way to manage this is to break the SnapMirror relationship using the snapmirror break <vol-name> command. Once SnapMirror is turned off, you can perform restore operations. When you are finished with a restore, the SnapMirror relationship can be reestablished via the snapmirror resync <vol-name> command.