These tape drives are shared among other storage nodes and NDMP devices. We are using dynamic drive sharing licenses. These tapes are also zoned to other storage nodes and other NDMP devices.
Have you checked KB at now.netapp.com for this? I can see several outputs on the subject, but you will know better if one of them matches your case. Perhaps opening a case with NetApp would be good idea. Do you see any error message related to drives at the same time on the other nodes sharing the same drive?
Think I have checked the KB at now.netapp.com but I don't remember having any good feedback. Will check again. The other storage nodes which are sharing the same tape drives are backing up fine but they are not NDMP devices, just storage nodes.
It might have. The reason for the failure is "DUMP: Tape write failed" and you will probably see some more error in daemon.log. I assume these tapes are dedicated to filer. Are they also zoned to filer only?
That's fine, but do you see any error/warning messages on them for the same time when you get the error on the NetApp side? Sometimes SAN events for shared objects will cause same error to be logged on all machines using this shared object. The message here may be different than the one from NetApp and may additionally help you troubleshoot this.
As you probably know, SCSI error reservation conflict implies that some other host has the device reserved. This brings the question on how do you set reservation abong your hosts. (if you are suing 7.3 then even NW might be involved as reservation has been added as an attribute for device in that release).
Can you let us know what version of Networker you are using? Versions before 7.2.1 (if I remember rightly) must dedicate drives to NDMP; you cannot share them with regular backups.
On saying that I've never tested this situation so I am not too sure what would happen if it was configured so!
I am using networker 7.2.1 . We have other NDMP devices : EMC CNS and they share their drives with other storage nodes and they are backing up fine. It is just with this netapps filer.
However, we have set up a test environment connecting the netapps to another tape library and install networker 7.3. We use dynamic drive sharing on devices in the tape lib and it is backing up fine for a week. So I really suspect it has something to do with networker version. But, the fact that CNS is backing up fine on 7.2.1 leaves much to ponder about.
7.0.4 is the latest if you follow the date of the release (addresses some serious bugs within DAR implementation), but 7.1 is the latest feature code. Have in mind that latest officially supported version by EMC is (or at least it was few weeks ago) 7.0.2. I had a case with 7.0.3 and case got dropped because 7.0.3 was not on compatibility list. Even these are only patch releases they didn't want to hear it - currently their support queue is rather full so they are trying to clean it up as possible - if something is not on compatibility list it gets denied support. I do remember that 7.1 had RFE created to be supported.
Hi, please could you tell about the version of Ontap used. There is an issue with tape drive handling in version 7.0.1 and 7.0.2. Behavior was changed between version 6.5 and 7.0 making handling of tape errors less flexible which causes backup abort. The robust handling used in 6.5 was re-implemented in 7.0.3 version of Ontap. Please contact NetApp support for details about this.
Yes I can confirm that support is denied if product in use is not listed in the compat guide. Recently I also had a case with Ontap 7.1 being closed due to not listed. Further there should be an RFE getting Ontap 7.1 supported release. I think this is addressed in LGTpa85701 but I'm not sure.
Hi There, How did you manage to solve the problem, if you did; will appreciate a reply since we are experiencing exactly the same problem with Networker v7.2.2 ... Thanks & Regards,
It looks like the problem originates at the tape drive which fails after about 26 GB. You could verify this by running a normal dump directly on the NetApp. This would write the backup to the tape without any of the NDMP functionality being used. If this also fails, get the tape drive serviced or renew your media or both.
If not, you will need to look elsewhere. I think the other errors in your log are a consequence of the tape failure.
SCSI reservation is used by hosts to "lock" or "reserve" a specific device for the use of a specific host. This makes sense on a SAN when multiple hosts may have access to devices and you need to prevent clashes. Normally once a host has finished with a device, it releases the reservation. Sometimes a failure can cause the session to finish without the lock being cleared.
Are there multiple hosts making use of the drive(s) in the library ? i.e. is it shared ? In that case, you may need to manage the access to avoid conflicts.
If not, rebooting the library should clear the reservation. Cheers, John Hope-Bailie
ylam1
35 Posts
0
March 27th, 2006 00:00
ble1
4 Operator
•
14.4K Posts
0
March 27th, 2006 00:00
ylam1
35 Posts
0
March 27th, 2006 00:00
ble1
4 Operator
•
14.4K Posts
0
March 27th, 2006 00:00
ble1
4 Operator
•
14.4K Posts
0
March 27th, 2006 01:00
As you probably know, SCSI error reservation conflict implies that some other host has the device reserved. This brings the question on how do you set reservation abong your hosts. (if you are suing 7.3 then even NW might be involved as reservation has been added as an attribute for device in that release).
oiturbe
2 Posts
0
April 4th, 2006 12:00
This is a new install?
Was running before?
Did you have multiples instances of the same NDMP client?
oiturbe
2 Posts
0
April 4th, 2006 12:00
Did you have an output of the nsrndmp_save command?
DavidHampson
2 Intern
•
1.1K Posts
0
April 4th, 2006 14:00
On saying that I've never tested this situation so I am not too sure what would happen if it was configured so!
ylam1
35 Posts
0
April 4th, 2006 20:00
I am using networker 7.2.1 . We have other NDMP devices : EMC CNS and they share their drives with other storage nodes and they are backing up fine. It is just with this netapps filer.
However, we have set up a test environment connecting the netapps to another tape library and install networker 7.3. We use dynamic drive sharing on devices in the tape lib and it is backing up fine for a week. So I really suspect it has something to do with networker version. But, the fact that CNS is backing up fine on 7.2.1 leaves much to ponder about.
ble1
4 Operator
•
14.4K Posts
0
April 5th, 2006 02:00
ylam1
35 Posts
0
April 5th, 2006 02:00
We have upgraded the OnTap version to 7.1 recently hoping that it will solve the problem but still persist. I belive 7.1 is the latest version.
guenterH1
117 Posts
0
April 5th, 2006 02:00
please could you tell about the version of Ontap used.
There is an issue with tape drive handling in version 7.0.1 and 7.0.2. Behavior was changed between version 6.5 and 7.0 making handling of tape errors less flexible which causes backup abort.
The robust handling used in 6.5 was re-implemented in 7.0.3 version of Ontap.
Please contact NetApp support for details about this.
Regards
guenterH1
117 Posts
0
April 5th, 2006 05:00
Recently I also had a case with Ontap 7.1 being closed due to not listed.
Further there should be an RFE getting Ontap 7.1 supported release. I think this is addressed in LGTpa85701 but I'm not sure.
tpoyraz
1 Rookie
•
8 Posts
0
November 2nd, 2006 05:00
How did you manage to solve the problem, if you did; will appreciate a reply since we are experiencing exactly the same problem with Networker v7.2.2 ...
Thanks & Regards,
jhope-bailie
21 Posts
0
November 3rd, 2006 03:00
If not, you will need to look elsewhere. I think the other errors in your log are a consequence of the tape failure.
SCSI reservation is used by hosts to "lock" or "reserve" a specific device for the use of a specific host. This makes sense on a SAN when multiple hosts may have access to devices and you need to prevent clashes. Normally once a host has finished with a device, it releases the reservation. Sometimes a failure can cause the session to finish without the lock being cleared.
Are there multiple hosts making use of the drive(s) in the library ? i.e. is it shared ? In that case, you may need to manage the access to avoid conflicts.
If not, rebooting the library should clear the reservation.
Cheers,
John Hope-Bailie