Yes DDS is being used and sometimes inventory is correcting the volume labels and sometimes it doesn't (either by command line or GUI). I found a Powerlink fix that is similar to this issue below:
I increased the jukebox timers as suggested, but have no idea where to change adjust the MAX_LOAD_RETRIES variable? Is this fix applicable for Networker 7.4.2?
In 7.3.x fast remount was also introduced so this might be cause of the issue - it did cause some pain before. If that would be the case support would need to check your logs to confirm this is going on and give you env. variable to disable it.
If your tapes are becoming mismatched how are you removing media from the library? You should take your tapes out through the CAP (cartridge access port) using the eject/withdraw or deposit functionality, NOT opening the front door and switching tapes (unless you run a full inventory afterwards).
The other thing we may be seeing here is that your tape ordering has been screwed up - reconfigure your drives and it will work.... to overcome this you need to configure persistent binding.
Login to the web interface of library and check the barcode of the particular tape and check the in the networker also , if both varies , first troubleshooting is move the tape in to another slot in the Library web interface and check the same has been reflected in the networker after moving . If it reflected , try to take a inventory of the tape and check the volume name and the barcode is same or not . Then revert me back . Hope the issue will get resolved , because the same problem i faced many times .
I had this mismatch error recently after a re-install of Networker. In our case Solaris had decided to invert the order the tape drives were being detected and hence the WWN based Fibre Channel zoning was how wrong as as far as networker was concerned the drive identities were inverted.
Persistent binding is configured on both tape drives and each drive is configured as an NDMP device for 2 storage nodes so in effect we have 2 local drives with pb and 4 NDMP storage node devices.
The problem I'm seeing is that after a few days worth of backups, the volume labels and barcodes end up mismatching, Networker loads a mismatched tape and then cannot read it and ejects this as an unlabelled volume in Networker and after this happens to a few tapes we get drives going into service mode and the usual waiting for writeable volumes alerts.
Doing a reset and inventory never changes the incorrect volume labels to match the library barcode labels, and the only temporary fix I have found is simply to delete and rebuild the Networker jukebox (as an NDMP SCSI jukebox) using jbconfig, then we end up with all volumes and barcodes matching but then this happens again after a few more backups.
Do you think this could indicate something corrupting the Networker media database perhaps? I have checked the library web interface and I see that the barcode labels in each slot match what Networker thinks are the barcodes, so it seems like a Networker problem and not library. Any ideas?
The problem here is not within Networker per say, its the OS which is not consistently using the same device paths fo rthe tape drives. This causes NetWorker issues as when the jukebox is configured we assign device paths to the tape drives and in for instance a Windows reboot the OS changes the paths to the physical tape drives.
There is a very good document available on Powerlink which is maintained by EMC which can be downloaded and references all OS (not just Windows) with what is required and also requirements for drivers CDI etc. I think what you need to do is reference this in particular the Persistent Bindings for the relevant OS , in this case Windows I beleive. The document is called Configuring Tape devices for EMC NetWorker Technical Note.pdf search for this if the link below does not work for wome reason: -
If you are using Windows based Storage Nodes systems and you reboot a Storage Node or the library, check your inquire on the Storage Nodes as the SCSI buses can swap for no apparent reason. As far as I am aware this is fixed in NW 7.5+ but is still the case in 7.4.2 which we run. When you get your system working straight and barcodes all OK take a copy of the inquire output. Use this for cross reference against your storage nodes when it goes wrong.
Basically your problem is that one of your systems is seeing its tape drives in the wrong order compared to the main backup server/autochanger controller. We run an i2000 and I have seen this on that and Quantum PX720s and also VTLs so it is library independant. The thing you need to do is work out which system has the drives the wrong way round. Where your drive is rd= :\\.\TapeN reporting the mismatch when loading a tape then the storage node in question is the one that has the problem. Cross check which physcial drive should correspond to that drive on the storage node and then make a note of the serial number (from the library web GUI) for that drive. If you check this against your inquire you should find that this drive does not match the serial number.
The limited information about the error you have, it is most likely due to persistent binding not set properly. i know you have mentioned it is set. but i still feel thats where the problem is. under the device properties you may check to see if your device presistent is enabled or not. you may want to enable it and see if that makes a difference. another check you can do is to run the mt command to check the status of the device when you encounter this problem. this will tell you if the device / device file / hosts combinations are correct or not.
ble1
4 Operator
•
14.4K Posts
0
April 16th, 2009 07:00
earth2009
53 Posts
0
April 16th, 2009 09:00
https://solutions.emc.com/emcsolutionview.asp?id=esg91917
I increased the jukebox timers as suggested, but have no idea where to change adjust the MAX_LOAD_RETRIES variable? Is this fix applicable for Networker 7.4.2?
Message was edited by:
ee01akk
ble1
4 Operator
•
14.4K Posts
0
April 17th, 2009 03:00
DavidHampson
2 Intern
•
1.1K Posts
0
April 17th, 2009 08:00
The other thing we may be seeing here is that your tape ordering has been screwed up - reconfigure your drives and it will work.... to overcome this you need to configure persistent binding.
Jiju1
181 Posts
0
April 19th, 2009 23:00
Login to the web interface of library and check the barcode of the particular tape and check the in the networker also , if both varies , first troubleshooting is move the tape in to another slot in the Library web interface and check the same has been reflected in the networker after moving . If it reflected , try to take a inventory of the tape and check the volume name and the barcode is same or not . Then revert me back . Hope the issue will get resolved , because the same problem i faced many times .
Rajesh S
carwynedwards
38 Posts
0
April 22nd, 2009 09:00
earth2009
53 Posts
0
December 31st, 2009 09:00
Hi,
Thanks for that.
Persistent binding is configured on both tape drives and each drive is configured as an NDMP device for 2 storage nodes so in effect we have 2 local drives with pb and 4 NDMP storage node devices.
The problem I'm seeing is that after a few days worth of backups, the volume labels and barcodes end up mismatching, Networker loads a mismatched tape and then cannot read it and ejects this as an unlabelled volume in Networker and after this happens to a few tapes we get drives going into service mode and the usual waiting for writeable volumes alerts.
Doing a reset and inventory never changes the incorrect volume labels to match the library barcode labels, and the only temporary fix I have found is simply to delete and rebuild the Networker jukebox (as an NDMP SCSI jukebox) using jbconfig, then we end up with all volumes and barcodes matching but then this happens again after a few more backups.
Do you think this could indicate something corrupting the Networker media database perhaps? I have checked the library web interface and I see that the barcode labels in each slot match what Networker thinks are the barcodes, so it seems like a Networker problem and not library. Any ideas?
masonb
445 Posts
0
January 5th, 2010 03:00
The problem here is not within Networker per say, its the OS which is not consistently using the same device paths fo rthe tape drives. This causes NetWorker issues as when the jukebox is configured we assign device paths to the tape drives and in for instance a Windows reboot the OS changes the paths to the physical tape drives.
There is a very good document available on Powerlink which is maintained by EMC which can be downloaded and references all OS (not just Windows) with what is required and also requirements for drivers CDI etc. I think what you need to do is reference this in particular the Persistent Bindings for the relevant OS , in this case Windows I beleive. The document is called Configuring Tape devices for EMC NetWorker Technical Note.pdf search for this if the link below does not work for wome reason: -
http://powerlink.emc.com/km/live1//en_US/Offering_Technical/Technical_Documentation/300-008-352.pdf
Regards,
Bill
Bobski1
4 Posts
0
January 5th, 2010 03:00
I have had this before. I could be this:-
If you are using Windows based Storage Nodes systems and you reboot a Storage Node or the library, check your inquire on the Storage Nodes as the SCSI buses can swap for no apparent reason. As far as I am aware this is fixed in NW 7.5+ but is still the case in 7.4.2 which we run. When you get your system working straight and barcodes all OK take a copy of the inquire output. Use this for cross reference against your storage nodes when it goes wrong.
Basically your problem is that one of your systems is seeing its tape drives in the wrong order compared to the main backup server/autochanger controller. We run an i2000 and I have seen this on that and Quantum PX720s and also VTLs so it is library independant. The thing you need to do is work out which system has the drives the wrong way round. Where your drive is rd= :\\.\TapeN reporting the mismatch when loading a tape then the storage node in question is the one that has the problem. Cross check which physcial drive should correspond to that drive on the storage node and then make a note of the serial number (from the library web GUI) for that drive. If you check this against your inquire you should find that this drive does not match the serial number.
aismaili
25 Posts
0
January 5th, 2010 10:00
The limited information about the error you have, it is most likely due to persistent binding not set properly. i know you have mentioned it is set. but i still feel thats where the problem is. under the device properties you may check to see if your device presistent is enabled or not. you may want to enable it and see if that makes a difference. another check you can do is to run the mt command to check the status of the device when you encounter this problem. this will tell you if the device / device file / hosts combinations are correct or not.