Please insert overwritable media into the robotic library using the import command.

[kajtek]

Please insert overwritable media into the robotic library using the import command.

Overwritable media includes scratch, blank, and recyclable media. Please note that depending on the current Media Overwrite Protection setting, imported and allocated media may be overwritable as well. Consult the online help for more information on overwritable media.

At the moment I`ve on the robot 2 tapes on Scratch Media - but I cannot to record for this tapes.
I`ve changed Option in Media Management to no promt, and i checked overwrite sctach media before recycable.

What is wrong with this settings ?
I`ve change almost everything - please tell me what am I post to do to finish that backup ?

[Hemant_Jain]

Please go to the media tab and see if there are tapes in "Scratch Media" media set. Run an inventory job on the robotic library to make sure the correct tapes are detected by Backup Exec.

Please mark it a solution, if this is useful
Thanks

[RahulG]

Have created partition in your robotic library ?? If so make sure the partition to which you have target your backup Job has overwritable media . Also before running the backup job run inventory and make sure the tape it he robotic library is overwritable ..

[kajtek]

At the moment i can`t check, because I cancel backup, erase all data from tapes and run backup again, and backup still running.
You write to check the media on "Scratch Media" - yesterday I`ve got 2 free (no data) tapes in this media, I ran inventory and the problem still persit.
In this week i simulated again run full backup and I check Yor solution.
Thanks for help,
Regards

Kamil

[corey_weeklund]

I'm having almost the same issue.  I have an autoloader with partitions defined (one for each day of the week) and all of my jobs run fine unless I put in new/blank media.  The new media shows up in the scratch set, but when a job runs, it says:

Please insert overwritable media into the robotic library using the import command.

I even turned off media management/overwrite protection in BE and am still having the issue.  

--Update - If I right click on the partition and actually import the media, the job will run.  But I don't recall ever having to do this before.  Any idea why this is happening this way?

[RahulG]

Please run quick erase on the new tape before running any Job

[rndxpert]

If any one receive "Warning: Please insert over writable media into the robotic library using the import command."

Reason 1: If you are using "Append to media, overwrite if no appendable media is available" option and your backup service or any component fail while backup.

Solution: If you have important data on tape then you can move this data in another temp area and ten you have to Erase the tape or you can change the tape.

If you are frequently receive this error then you have to diagnose the backup exec server.

[kajtek]

Hi. I`ve got the same problem at the moment.
I have got 2 tapes (with no data) in schratch media:
1) i erase media again
2)  i inventory one tapes
3) i catalog media one tape
4) I click right button on job - respond to alert - and I click OK - the allert message is the same.
Please insert overwritable media into the robotic library using the import command.

Please write in few steps what should I do. Thanks again.

[kajtek]

I resolve this problem: I drag and drop media from scratch to retired media and put the media in to the set with backup.
Thanks for help.

[BernardJL]

We can find nothing on this problem (or perhaps there is a configuration issue). 

We use "Backup to Disk" folders for our backup.  There is plenty of space for the folders.

But last night when doing a backup of the Exchange Storage using the "GRT" method, we got this message "Please insert overwritable media into the robotic library using the import command...etc.".

This message must have repeated all last night since there was over 1,500 of these in the log.  Looking at the machine, there was space on the drive, there were a number of the "BD2D" files that were marked as "Scratch". 

In short there was nothing we could figure to do since there is NO "robotic" library and no media that could be "imported" that we can tell.

We cancelled the job and restarted it.  However, it again started up with the "Please insert overwritable media into the robotic library.."

Please help.

Thanks in advance.

[kajtek]

Did you have some free tapes in Scratch Media ?

[WATC]

I think we're having the same problem BernardJL was - the Exchange backup runs for a while, but eventually starts requesting we "insert overwritable media" into the robotic library, and refuses to proceed.

The job is targeting a backup-to-disk device pool, which consists of 3 devices:

D:\Backup-to-disk\Array 1
D:\Backup-to-disk\Array 2
D:\Backup-to-disk\Captive

Array 1 and Array 2 are two different logical arrays on the same direct-attached MSA-20 (just over 1 TB each), while Captive is actually part of the D: filesystem and consists of the additional disks in the server itself (about 500 GB free). Backup Exec is configured to create 4 GB files in each of these locations, with the low disk space threshold set to 5 GB.

Array 1 has been mostly used (11 GB available) but most of these are overwritable. Array 2 has about 200 GB free on the disk, with a dozen or so B2D... files overwritable. None of the IMG files are overwritable, which may be what's upsetting Backup Exec; but I don't know why it's not creating new ones. The job, when running, has selected Array 2 for the job, though I understand it's supposed to automatically span to other devices in the same device pool as needed.

The Captive area has nothing in it. It did previously and I had this problem, so I removed the folder from Backup Exec and deleted the physical files, creating it over fresh. So it's completely empty and able to be written to, but no jobs have needed to hit it yet. When that change was made, we were pretty low on space so I also changed the media set configuration to reduce the overwrite protection period to ensure there was always capacity available for it to use.

So to recap: Exchange GRT backup is targeting a device pool consisting of 3 backup-to-disk folders, each of which has available capacity (either unallocated or overwritable), but the job only gets so far before it starts requesting overwritable media and there's no way to get it to continue.

Last time I got the impression that Backup Exec considers the "IMG" folders separate to the B2D files, i.e. overwritable B2D files are not sufficient if it's doing a GRT backup. At the time we had overwritable B2Ds, but not any free space on the disk to create new IMGs (and no overwritable IMG folders). However this time, we have hundreds of gigabytes of free disk space and the job is still stalling.

We're using an up-to-date Backup Exec 12.5 on Server 2008, 64-bit.

[CraigV]

Hi WATC,

If this is a new call, I'd suggest logging it in the forums...better response from people to something they can close a solution on.

Laters!

[BernardJL · Accepted solution]

WATC,

Just as a follow-up to our original post:

We finally created a case with Symantec to resolve this issue.  They gave us a solution and explained how the "IMG" backup is different that the "B2D" backup files.

In effect, an "IMG' backup will NOT move to another drive in a pool if the current drive is full.  Instead it issues the incessant message "insert a tape in the robotic library".  In addition, even if you create more space on the drive it is using, it will not continue.

The solution for us (we are backing up an Exchange Store) is to point the backup job to a particular disk and NOT a pool. 

It turns out that the "IMG" folders have their own space management process.  By using the same drive every time, the "IMG" space is managed and old data space within the "IMG" is released, etc. 

This is not exactly what we wanted but since doing this our backups have been running fine, no space issues, and the "IMG" files have not been "growing" as previously.

I hope this helps your situation.

[WATC]

Thanks for that. I suspected it might be something along those lines - it did seem to be treating them differently to regular B2D. While not ideal, we can also dedicate one of our arrays to the Exchange backups to ensure there's always plenty of space for them.

Thanks again for following up. Time to do a bit of re-architecting!