BackupExec 12.5 ejecting tape b4 ending the backup

[GNS_GmbH]

Hello,

I'm using Backup Exec 12.5 on Windows Server Essentials 2008 and have a weird issue. For a long time backup was running fine. Now the tape gets ejected before the job is done!

18:00:02 Backup starts

18:00:04 Alert: Please insert backup media

It looks like Immeadtly after the job starts the tape is ejected. Sadly there are no error messages or anything what would help me to clear out the issue. If I tell my customer (I'm a remote technican) to put in the tape, the backup job continues and pretends that nothing has happened.

I'm using a Tandberg LTO-2 tape system with 400GB (200 uncompressed) tapes. Normally the backup job has an output of around 280-290.000.000.000 Bytes and runs for 5-6 hours.

The backup job is set to overwrite the tape and NOT throw it out when the job is done because there is another job following at 1:30 in the night. The second job is supposed to eject the tape. 

If you need any more information to help me please ask, I want to clear this issue as fast as I can.

[Jaydeep_S]

Is the Tape that you are using Overwritable? Cause if it is not and the job is set to overwrite, Be will eject the tape out. Also, look for the overwrite protection period on the Tape.

If you and the customer are very sure that the Tape can be overwritten by the backup, then perform a quick erase on the Tape media before the job starts.

[GNS_GmbH]

Hello, 

Thank you for replying.

You want me to create a third job, putting it in front of the other jobs, to erase the data from the tape? or is there an option in my job to wipe the tape b4 writing on it?

[Jaydeep_S]

Scheduling a erase job before the main job can be an option. However, use caution vwile inserting the tape in the drive for being erased as this is an ireversable process.

The overwrite protection is managed by setting up the Media Sets correctly. Check the properties of the Media Set used on this job. 

[CraigV]

...check the compression you are now getting on the tapes. If it is less than before, then get hold of the Tandberg tape utility and run a compression test on an available tape.

Thanks!

[Donald_Eady]

You may want to consider running the debug monitor durring the job to try and get a better understanding as to what its thats going on. I would start it a few minutes prior to the job runnning and allow it to run for at least a few minutes after your client reinserts the tape.

http://www.symantec.com/docs/HOWTO11932

[Biker_Dude]

Assuming this is a stand-alone tape drive environment AND the media is ejected immediately after the jobs starts (as you've stated)...it sounds like BE might think the previous media is still in the drive.

Prior to running the next backup...if the user is manaully ejecting the media from the drive, BE has no knowledge of this interaction.  After manually inserting the "new" mediam BE could still believe the "old" media is still in the drive.

If the "new" media is not inventoried then BE deem it to be the wrong tape...hence the eject.  Once the user re-inserts the tape (for the second time) this allows BE to take a peek at it (via and inventory) and run the backup as expected.

After the user ejects the "old" and inserts the "new" media, please have them run an inventory job.  This will ensure that BE knows exactly which tape is in the drive before the next backup runs.

If the backup appears to write to the media but ejects it latter on, then heed CraigV's recommendation.

Nonetheless, there should be alerts in both scenarios above.  It's possible there are Alerts but they could be surpressed to not pop up in the UI, which is not the defualt behavior for BE.

[Kunal_Mudliyar1]

Is it happening with all the tapes you are using for the job or a particular tape?

It could be a bad tape.

[Larry_Fine]

When did this problem start?  What changed around that time?

Is the tape drive firmware up to date?  I know this is an older drive, but have you installed new firmware about the time that this issue started?

Is there any chance that the previous nights jobs never actually finished because they are now spanning to two tapes?

Are we sure that the new tape was in the drive at 17:55?  Can the end user confirm that the media is ejected exactly at 18:00 when the job starts?

I would suggest scheduling an inventory job at 17:45 to confirm that the new tape is in the drive and readable.

[GNS_GmbH]

Hello, 

Thank you all for replying, I didnt expect so many responses. I will try and cover as much as I can in my answer.

I couldn't try erasing the tapes b4 the backup yet, will do it next week when I schedule a meeting.

The compression I seems to be 1,4:1   I don't know the compression I had 2 weeks/2 month ago, is there a way to check?

I'm going to run the debug monitor for the whole day and during my meeting next week, thanks for the hint.

All medias are inventoried in a tape set in BE. Normally the job#2 ejects the tape after the finish.

I've seen this happening with my last friday tape, the monday, tuesday and wednesday tape. I doubt that is a bad tape. The tapes aren't the newest ones and will be replaced soon though.

The problem started last friday. From my admin side nothing changed. The last change to the system we made was upgrading RAM and HDD three weeks ago. The backups between then and last friday were fine.

I can not be 100% sure that the tape is in at 17:55 because the customer heads out about an hour earlier.What exactly would that inventory job do?

thanks again for responding to my thread, it's much appreciated.

[CraigV]

...if you have a monthly tape from a couple of months ago you can check the compression on that!

An Inventory job is basically going to make sure that the tape in the drive is useable...I've done something similar on an HP StorageWorks 1/8 G2 autoloader as I was having issues with a user changing tapes out correctly. In this case I set it to run an hour before...maybe you can do the same thing before the user leaves work so you can at least respond to any potential media availability issues.

Thanks!

[GNS_GmbH · Accepted solution]

It looks like the issue was caused from bad tapes. We've received our new set of tapes and they are working properly. 

The behaviour was weird and I'm sorry that I've bothered you with this easy problem.

Kind Regards