Restore node doesn´t work after Netapp Ontap Update

waelti

ADSM.ORG Member
Joined
Apr 20, 2010
Messages
54
Reaction score
2
Points
0
Location
Germany
PREDATAR Control23

We have updated our Netapp from version 9.1P9 to 9.3P5. Now it turns out that the RESTORE NODE no longer works (BACKUP NODE always works).
The problem is that the TSM does not find the volume set to "Restricted" (worked under 9.1P9):

ANR2017I Administrator ADMIN issued command: RESTORE NODE in-sv-nasvm01-mir /in-sv-nasvm01-mir/tpd /in-sv-nasvm01-mir/RESTORE TYPE=SNAPM
ANR2516E RESTORE NODE: The specified file space, /in-sv-nasvm01-mir/RESTORE, does not exist on the NAS device associated with the node IN-SV-NASVM01-MIR.

If we mount the volume on the Netapp again, you get the message that the volume is not set to "Restricted":
ANR2017I Administrator ADMIN issued command: RESTORE NODE in-sv-nasvm01-mir /in-sv-nasvm01-mir/tpd /in-sv-nasvm01-mir/RESTORE TYPE=SNAPM
ANR2688E RESTORE NODE: The SnapMirror Restore of NAS node IN-SV-NASVM01-MIR, file system /in-sv-nasvm01-mir/tpd, cannot be started. The destination file system /in-sv-nasvm01-mir/RESTORE is not set to "Restricted" on the NAS device.

Has anyone the same problem and knows how to solve it? Calls are made to Netapp and IBM.

Kind regards
Walter Reis
 
PREDATAR Control23

Hi, I had a customer who had the same symptoms and it was resolved by working with netapp.
Also this error ANR2688E means the target destination was not set up as a snapmirror target
volume.

Check also https://www.ibm.com/support/knowledgecenter/en/SSGSG7_7.1.7/srv.reference/r_cmd_node_restore.html

SNAPMirror Specifies that the file system should be retrieved from a NetApp SnapMirror image. SnapMirror images are block-level full-backup images of a NetApp file system. A SnapMirror image can only be restored to a file system that has been prepared as a SnapMirror target volume. Refer to the documentation that came with your NetApp file server for details.
After a SnapMirror image is retrieved and copied to a target file system, Tivoli Storage Manager breaks the SnapMirror relationship that was created by the file server during the operation. After the restore is complete, the target file system returns to the same state as that of the original file system at the point-in-time of the backup.

When setting the TYPE parameter to SNAPMIRROR, note the following restrictions:

Restrictions
  • You cannot specify the FILELIST parameter.
  • Neither the source_file_system_name nor the destination_file_system_name can be a virtual filespace name.
  • This parameter is valid for NetApp and IBM® N-Series file servers only.
 
PREDATAR Control23

Hi SElias,
mounting the volume was only a test (ANR2688E ).
Do know what Netapp changed to make it work again?
 
PREDATAR Control23

No, sorry ..

But it had to do with configuration and network.
 
PREDATAR Control23

It was a error from netapp. It is fixed since version 9.3P7 (or 9.4P1)

"In that case it was discovered that NDMP SMTape restores fail in OnTap 9.3. The reason for the failure was due a change in OnTap behavior such that the "restricted" volumes, which are required for a snapmirror restore, are not returned to the DMA in the NDMP_CONFIG_GET_FS_INFO reply message. The DMA in this case is IBM Spectrum Protect.
.
The result achieved:
- the restore fails with ANR2516E in case the volume is restricted.
- the restore fails with ANR2688E in case the volume is online.
Per Netapp documentation: SMTape restore destination volumes must be in "restricted" state. However, OnTap 9.3 does not allow restricted volumes to be mounted. This results in these volumes not being included in the NDMP_CONFIG_GET_FS_INFO reply message sent back to the DMA as available volumes. The IBM Spectrum Protect server will fail the restore and report that the destination volume is not valid because it wasn't in the list of available olumes in the NDMP FS_INFO reply message.

Additionally, this changed behavior causes another more serious problem: For a DMA to perform a Cluster Mode NDMP restore from a locally attached tape drive, it needs the Netapp cluster affinity identifier for the destination volume. And the affinity ID is supposed to be sent by the filer to the DMA in the NDMP_CONFIG_GET_FS_INFO reply message. Since the filer no longer sends "restricted" volumes in the NDMP_CONFIG_GET_FS_INFO reply message the DMA doesn't know the cluster affinity for a restricted destination volume and you can no longer perform an NDMP SMTape restore."
 
Top