Please insert overwritable media into the robotic,although media is loaded?

[Erik_Nettekoven]

Hi,

Problem Description
We are experiencing some strange problems with Backup Exec 10.0 SP4.
* There are two HP C7200 (aka HP Surestore E Tape Library Model 2-20) libraries attached to the backup server.
* One library is loaded with 14 tapes and the other is loaded with 13 tapes.
* According to the "Devices" tab in the BE program all tapes belong to the Media set: "Scratch media" and all the tapes are overwritable.

Although when a scheduled job starts, backup exec comes up with the alert: "Please insert overwritable media into the robotic library using the import command."

No matter what kind of response I give the alert keeps returning. The tapes in the libraries vary from age and usage, some are rather old and used successfully before, but other tapes are fairly new and also successfully used before.

Strange thing is that if I load other tapes with the same age and just as often used before, the scheduled job does backup correctly. The point I try to make here is, there is no real distinction between the tapes which are used successfully and which aren't.

So, for some unknown reason some tapes are used successfully and other are not. Any ideas on this one?

Things I've tried, but did not provide a solution:
* Using the import command (as suggested by the alert)
* Run HP LTT, run some tests and diagnostics, all turn out ok
* Set the scsi id of the libraries lower than the scsi id's of the tape drives
* Run a quick erase
* Run a full inventory of the tapes in the library
* Tried some suggestions as mention in: http://seer.support.veritas.com/docs/255501.htm and http://seer.support.veritas.com/docs/191957.htm
* Checked eventlog on scsi conflict or other errors (none related found)
* Searched this forum for same problems, but they all do not seem to apply to my specific problem.
* Labeled all tapes in the library usin BE

Last thing I tried
* Loaded some tapes which surely work. Moved around the tapes a bit, but BE only loads the tapes that do work and skips every other tape. So put a working tape in slot 9, and BE skips the other 8 tapes and loads the one in slot 9! I am completely lost

==
Systemspecs Backup Server:
* Hardware: Compaq DL580 G2, 4Gb RAM, 4x Adaptec SCSI 39160 (1 per tape device), 2x HP Surestore E Tape Library Model 2-20, 4x HP StorageWorks Ultrium 230 Tape Drives
* Software: Windows 2003 Standard - SP1, Veritas Backup Exec 10.0 - SP4

[Erik_Nettekoven]

BE did it again
BE skipped 15 tapes.....again!

The OPP is set to 6 days and the Append Period is set to 14 hours. 14 hours is the backup window we currently have and as we do not want to have jobs of different days on the same tape we have set the Append Period to 14 hours. So, if we, for what ever reason, are not able to retrieve the tapes for a specific day, we still have different sets on daily basis. We only make full backups by the way.

Our backup/company policy is to store a minimum of 10 (working)days of tape sets. Following this policy, a tape is never being reused before it has been in storage for at least 10 days. The backups made on friday are even stored for one year! This excludes that OPP could be the problem.

Here is some on screen info taken from the devices tab:
Slotnumber: slot 2
Bar code: FDX989L1
Media Label: FDX989L1
Media Description:
Allocated Date: 28-2-2006 14:53:48
Media Set: Scratch Media
Media Location: HP5 (Library) (WBABKP01)
Overwrite Protected Until: Overwritable (Scratch Media)
Appendable Until: Not Appenable
Available Capacity: 97,7 GB
Total Capacity: 97,7 GB
Bytes Written: 64,0 KB
Compression Ratio: 1:1

The other 14 tapes show exactly the same info (except for the Bar Code en Media Label of course!)

Why oh why, does BE keep on asking for: "Please insert overwritable media into the robotic library using the import command."

[Asma_Tamboli]

Hello,

Are all the tapes recognised correctly? please clean the drive a couple of times. Also check out for any read or write errors on the media.


NOTE : If we do not receive your reply within two business days, this post would be marked assumed answered and would be moved to answered questions pool.

[Erik_Nettekoven]

Are all the tapes recognized correctly?
How can I be 100 % certain that the tapes are recognized correctly? If I follow the information shown in/given by BE, I assume the tapes are recognized correctly.

Better yet, the tapes now being skipped have been used correctly before! (The oldest correctly used since may 2005 the youngest, correctly used since december 2005)

Also check out for any read or write errors on the media.
Well, some of the skipped tapes contain Soft Write Errors and Read Errors but less then a tape that contains a backup. Hence, a skipped tape contains 1 Soft Write Error and no Soft Read Errors, the correctly used tape contains 37 soft write errors and 24 soft read errors. (Figures?)

please clean the drive a couple of times
The drive(s) has (have) been cleaned for a couple of times. There is, by the way, a cleaning schedule for the drives which runs at least once a month.

[Erik_Nettekoven]

Ok, I have found a work around, but I think it is a bug in BE 10.0.5484 SP4.

Although, the skipped tapes seem to be scratch media (at least BE says so), they actually are not. That is the reason they are skipped.

Running a quick erase, a long erase or an inventory does not change this state. The only way to get the skipped tapes working again is to move the tapes between different media sets.

In our case I moved (drag & drop) the skipped tapes from the "Scratch Media" to our custom defined media set "Tapes". Then I moved them back again to "Scratch Media" and the tapes aren't skipped any longer. So my guess, there is some hidden state, which is reset when manually moved from and to the "Scratch Media" set.

Is there some fix or other option to fix/automate this process? I find I rather ridiculous to move around the tapes between the media sets manually every day, just to be sure they will not be skipped.

By the way
Never experienced this problem in previous versions of Veritas

Another dilemma: Can I assume my question as answered/fixed or not? It is merely a workaround....

[Amruta_Bhide]

Hello Erik,

As you said, That is only a Workaround.

This Alert normally comes if you are trying to use an Overwrite Protected Media for an Overwrite Operation.
The Media Set Settings that you have configured just now does not make the Tape / media Overwritable on the 10 working day. This is Because the OPP starts after the Last Append Operation performed on the Tape / Media.
You can go through the following Article to uderstand this better:
An explanation of the "Overwrite Protection Period" and the "Append Period"
http://seer.support.veritas.com/docs/237374.htm

Thus, with the Configuration that you have (AP: 14 Hours and OPP to 14 Days), the Tape becomes available for an Overwrite Operation on the 11-12th Working day instead of the 10th.

You can try setting the OPP to 12/13 Working days.

NOTE: this is a issue where you need to do tests to see if configuration is meeting your Requirements. So if the Abouve mentioned configuration does not help try different combinations of the AP and OPP.

Hope this helps you. Please write back to us with an Update.

******************************************************************
*****************************************************************

Note : If we do not receive your reply within two business days, this post would be marked ?assumed answered? and would be moved to ?answered questions? pool.


Thanks.Message was edited by:
Amruta Bhide

[Ken_Putnam]

Amruta - You completely ignored the most important question -

He has tapes that are displayed as being in the Scratch Media set. BackupExec will NOT accept them as overwritable.

If he moves them manually from the Scratch media set to a Production Media set and back to the Scratch set, then BackupExec will accept them as overwritable


ANY TAPE in the scratch set, by definition, should be overwritable, regardless of the media set properties of any media set that may reside on it.

He also said that he has never seen this behavior with prior builds, so it sounds like he has used BackupExec long enough to know what he is doingMessage was edited by:
Ken Putnam

[Erik_Nettekoven]

Firstly:
Thanks Ken, for backing me up here. (5 points for that :-D)

Second:
Dear Amruta Bhide,

Did you really read what I posted?
In your answer you say my config is like:
"AP: 14 Hours and OPP to 14 Days"

But my post clearly says:
"The OPP is set to 6 days and the Append Period is set to 14 hours."

So, I have no clue where you get the "OPP to 14 days" idea. Or should I've made more clearly that we PHYSICALLY store the tapes for at least ten days before reusing them. This has nothing to do with the OPP setting in BE!

Furthermore, Ken said it all. So nothing more to add for me.
Too bad I can't grade post as: "Completely useless"

[Erik_Nettekoven]

> ******************************************************
> ************
> ******************************************************
> ***********
>
> Note : If we do not receive your reply within two
> business days, this post would be marked ?assumed
> answered? and would be moved to ?answered questions?
> pool.
What kind of bogus policy is this?

How about:
If the customer does not receive a reply within a month, this post would be marked as unsolvable and would be moved to "sorry, we are too incompetent to help you" list.

Do I maybe sound a little to dissatisfied? Well, I AM!

[Asma_Tamboli]

Hi Erik,

Sorry for the inconvenience caused! Does the issue still occur?

Could you please update us on the issue?

Thanks.

[Kenny_Bevins]

I have the same issue with my version of Backup Exec. I have Backup Exec 10.1d Rev 5629 and ALL of my tapes are currently in Scratch and BE will never use my scratch tapes unless I do as suggested in this thread. I created a new media set called Tapes Import with Infinite Append and Infinite Overwrite. I moved all of my tapes to this media set and then back to scratch..... voila, it works.

As Ken mentioned earlier, shouldn't any tape in scratch media be useable regardless how it got there the first time?

--Kenny