The problem I am having is on multiple systems running on different OS Windows 2000 Pro, Window 2000 Server, Windows 2003 with different versions of BE from 9.x to 10.x. The drives are Exabyte VXA2 and the library is the packet loader 1x10.
The problem with the system losing the tapes happens when the system starts to verify the backup and can not find the tape it was using. If you check the device slots you will find the tape. The job will just hang waiting for someone to insert the tape.
As for the miss labeling of the tapes. The software will mark a tape as cleaning media when it is not and use it as cleaning media. It will mark tapes as blank media when it is not blank.
I have worked with Exabyte on this and they say it is a problem with BE.
Any solutions and or suggestions would be appreciated.
That's what mine does. But it cannot find the tape to create a backup or add to the tape - my server just grabs the next free tape and uses it....so after 9 jobs all the tapes will be offline and throwing errors.
The important thing to look for in the logs is the MEDIA= . This should never change, unless you erase the tape
This is the first data block that records the tape name and description, the Family ID, and the tape sequence number. If the tape is blank, all of these values are assignred by backup Exec and tracked by the BEDB.
If there is difficulty in reading this block (because of bad/dirty tape drive, or bad tape) then backupexec may misinterpret the tape as a cleaning tape or may assume you have inserted a new tape (with the same barcode) and assigns it a new GUID.
This is what I think is happening to you. I think if you repeatedly perform inventories, you will see the GUID value of the same tape change and change again. Once this happens, you've got major problems- becuase BE thinks you're switching out tapes (behind it's back :) ) and will prompt you to insert a tape that is already in the library.
So, perform multiple inventories on the same tape and watch the GUID value. Then clean the drive 3-4 times, and try again. Then try the same thing with a new tape. If it keeps happening, then it's a drive problem. I don't think it's BE fault if the drive is telling the database different things each time the same tape is loaded.
Hello Andrew, I have the same problem. I have been battling with it and symantec and the hadrware vendor for nearly a year now. I am so glad to see that other people are having the same problem. The support staff had just about convinced me that I was an idiot.
Anyway to the problem. It is a long story, but I will cut it short. I have an IBM X225 server with adaptec 29160 scsi adapter VXA-2 10-1u tape library. I back up approx 400GB of data over 5 x-23 ( i think) tapes, weekly. I have had the library replaced a numer of times. It will work ok for a little while and then the problem returns. Just in the last fortnight I have found the only way for the system to work anything close to reliably is to clean the drive after every backup. By which I mean I run the cleaning tape thru twice after the backup. I have to admit that my cleaning taps is getting a bit old now. It is stiill early days for this fix, it has worked the last 2 weeks. I am still battling with both symantec and the hardware vendor to get som more sense out of this. But It seems to me that it may be an inherent problem with the vxa-2 drives.
I just tried to do a test restore from the backup that was done last night and it can not find the tape that was used. The tape has not been removed from the library. This is no good. I need a fix ASAP.
The tape had the problem where it could not find the tape to do the verify of the backup as usual. I had to cancel the job to continue. They job only uses one tape by what the report says.
So one of my questions is how does it loss a tape it had just used for the backup that has not been removed from the drive.
Another is what needs to be done to get the system working again. I have worked with Exabyte to see if it was a drive problem they say it is a Backup Exec problem.
I have tried the OEM drives, Symantec drivers, cleaning the drive several times before a backup.
This is getting very old. I do not have any good backups for multiple sites due to this problem.
My higher up are starting to think of pulling all the systems that we manage and going with something else. That is bad for a reseller to say for the drives and the software.Message was edited by: Andrew Shaffer
We have tried the suggested steps. They also did not work.
We have finally had a Tech at Exabyte state that over 10% of the drive that leave the plant are junk. We are working with them to have them replace all of the drive we have with the Magnum lto-2 drives.