Backup Exec 12.5 sits and waits for autoloader

[tv126]

I have 2 Exabyte 1x10 VXA autoloaders and suddenly backup exec is doing the strangest thing.  It runs a scheduled differential job to one of the tapes, then ejects the tape from the drive, and it should be done.

But BE does not recognize that the autoloader has ejected the tape successfully, and just sits there waiting forever.  No alerts, no error messages, just waits for the autoloader.  if I restart the services BE realizes the correct state of everything.  You of course cannot issue an inventory or something command because it still thinks the autoloader is doing something.  BE offers almost no autoloader controls.  With no alerts or errors, I am at a loss what the problem is.

[pkh]

By eject, I take it to mean that the tape was returned to its slot.  How do you verify this?

Have you run a diagnostic on the library?

[Larry_Fine]

Start here: http://www.symantec.com/docs/TECH24414

It is possible that the loader/drive is no longer signaling the proper status to BE, so you may want to activate the SCSI tracer or run SGmon in verbose mode to see what communication is ahppening at the end of a backup.

After restarting services, can you run an inventory without error?

[tv126]

There are some Event 9 timeouts in the system log.  The server has 2 adaptec scsi cards each one has an autoloader.  That should be a no-brainer, been running that way a long time.

I can run an inventory no prb after restarting services, but sometimes BE thinks the tape that was in use prior is now unknownm media.

MORE INFO: I lowered the SCSI speed, no diff.  The problem is that when BE needs to _read_ the second tape, it just sits there and times out, then thinks that the next needed tape is "blank media".  Even if I do an Import, forcing BE to re-recognize its own tape, it will not try and loadthe 2nd tape.  Of course, I cannot do an inventory, which would kick BE, or restart the services, which would also kick BE, because either of those would mean stopping the job.

It is pretty clear a case of BE not being in control properly.  I found elsewhere on forums similar problems with no solutions, the people left BE.  I have tried bith Symantec and Windows drivers.

[tv126]

MORE INFO: It is not limted to tape drives!!!!  Now whenever BE reaches the end of any backup where multiple servers were backed up, EVEN BACKUP UP TO A DISK, BE just sits there stuck, and the job never ends.

The problem seems to be BE not realizing the job is over or needs as new tape or what the status is.

[tv126]

MORE INFO

Now I am getting an alert to insert the next tape (i.e. tape 002), even though the correct tape is there. I tried doing the import with auto-inventory, but it just runs forever and does nothing.

[tv126]

MORE INFO

I found a similar case on a third party (non-symantec) forum.  They concluded the problem is that BE is failing to recognize sometimes its own media, be it tape or disk, and thus all of a sudden BE thinks the roght media is not there.

[tv126]

MORE INFO

Every time I restart the services we go back to normal and BE sees what is really in the loaders.

[tv126]

MORE INFO

Doing an overwrite nbackup across tapes is fine until the last tape. restores are a problem the second tape.

[tv126]

I have spent days and days and have found the problem.  It is a significant bug in BE.  It has been reported around the web since version 9.x.

If you create a backup set consisting of , for example, 4 different C:\ drives from 4 different machines.  Then you run the backup to tape.

When you restore, verify, or duplicate, you cannot select the backup set, i.e. the 4 drives.  You have to do each one separately.  BE cannot understand how to find all the components of the set across tapes.

This makes no sense, as it can handle ONE c:\ drive if it spans tapes.  But if two drives span tapes, BE cannot figure out what to do and sits in an endless loop.  In some cases it will give an alert to insert tape X, even though tape X is currently in inventory.  Import jobs will not help, they will just also get stuck.

Restarting services is the only way out of this mess.

I have confirmed this with 4 different autoloaders from 4 brands, running on Win2003 and Win2008 and WinXP.  It is 100% a bug, and I wish somebody would have just admitted that up front.  I have no idea why somebody would put a down vote on these posts either.