cancel
Showing results for 
Search instead for 
Did you mean: 

BE V20.5: Import Export fails with E0008213 / E0008214

KPS_BV
Level 3

Library: "NEOs StorageLoader", 8 physical slots, 1 Mailslot (defined inside library), 7 Slots visible to Backup Exec

1) The full backup job has been set to export the tape after backup completes --> this immediate export fails with "E0008213 destination location is full". Manually rerunning the job succeeds.

2) An Import job has been created to run every Monday. The job fails with "E0008214 source location empty". Manual rerun doesn't help.

Checked the library using the webinterface before rerunning the import: Mailslot has a tape, slot 3 is empty, all other Slots have a tape, drive is empty

Checked the libray using Backup Exec before rerunning the import: Mailslot not visible (as expected), Slot 3 is empty. All other slots have a tape (Slot 7 is CLN), drive is empty

See also attached log files

Any help woud be very much apprecited. Thanx

1 ACCEPTED SOLUTION

Accepted Solutions

pkh
Moderator
Moderator
   VIP    Certified

You can achieve what you are trying to do.  I did what you are trying to do with my jobs.

You should add the tape export as another stage so that after the backup, it would be moved to the mailslot.  Do not use another job and schedule it because this job will not know which tape is used by the backup job.

To import a tape, you need to specify a specific slot.  If the slot is not empty, the import will naturally fail.  Unless you can ensure that the slot that your import job target is free everyday, you need to use a BEMCLI script to find an empty slot for the import tape to go to.

You should set up a very small backup job (backup one file) with an export stage to test.  If it fails, then there is probably something wrong with your tape library.

View solution in original post

12 REPLIES 12

Larry_Fine
Moderator
Moderator
   VIP   

The attached XML logs don't show much details.  If possible, please submit the actual job log, saved in .mht format.  I would also be curious to see your adamm.log file.  Assuming that you are using bar codes on your tapes, sharing an inventory job log and/or a scan job log would alo be helpful.

To investigate the export failing, it would be curious to see the exact commands sent to the robot and what the responses were.  This can be done with tracer.exe  https://www.veritas.com/content/support/en_US/article.100007801.html  Then you can compare the MOVE commands with the manual job run that worked.  This may be a BE issue or it may be a library issue.  Please post the .bin file here.

Scheduling an import is generally not done as it is very likely that you don't know what empty slot to import to.  That being said, BE should not fail with an error implying that the portal is empty.  But both export and import errors sound like something weird with the portal, so I bet they have the same root cause.

KPS_BV
Level 3

Thanx for your thoughts. I'll have a look into it an respond late today.

KPS_BV
Level 3

Finally I got the testing done and traced a scheduled import and a manual import.

Attached are logfiles, tracer files and a single file in Word Format describing the process.

I really can't trace the export during backup because that happens around 5 o'clock in the morning. Thats not really my time.

Hope this helps.

Thanx for your support

Larry_Fine
Moderator
Moderator
   VIP   

The adamm.log confirms that BE sees the tape library as expected, with 1 mail/portal slot.

  • 1st Slot Number 1
  • Number Of Slots 7
  • Portal Slots 1
  • Import/Export Robotic
  • Drives 1

"Tracer Log für Medium - Import Scheduled Test with tracer and new adamm.bin" and "Auftragsprotokoll für Medium - Import Scheduled Test with tracer and new adamm" show lots of "Changer error - destination completely occupied." errors (per Google translate).  But the import job log shows all 7 slots.

A scheduled import job can only do one slot, since you only have one portal slot.  Only 1 tape can be imported without human intervention.  I suspect that this scheduled import job was created incorrectly, by trying to import to the whole library, which cannot be done.  You must pick a specific slot (#3) to import a tape to.  This is what makes scheduling an import tricky, as you likely will not always know what the empty slot is to create the job.

The tracer.bin file shows the tape library reporting the expected/matching error result.

------------------------------------------------------------------------------------------------------------------------------------------------------------------
Event Check Start End Target Operation
------------------------------------------------------------------------------------------------------------------------------------------------------------------
734 C 53b0d 9/27/2019 02:35:49.233 916 03:00:02:01 [BDT FlexStor II 00DE64003488_LL0] MOVE_MEDIUM
==================================================================================================================================================================

Event: 734 Start: 2:35:49.233 Stop: 2:35:50.149 Duration: 0.916052
SCSI Address: 03:00:02:01 [BDT FlexStor II 00DE64003488_LL0]
Function SRB_FUNCTION_EXECUTE_SCSI
SCSI Status SCSISTAT_CHECK_CONDITION
Sense Length 18
Data Length 0
Driver Result STATUS_SUCCESS

Raw CDB
A5 20 00 00 03 EF 00 65 00 00 00 00 . .....e....

CDB Operation MOVE_MEDIUM
LUN 1
Transport 0
Source 1007
Destination 101
Control 0x00

Sense Data
70 00 05 00 00 00 00 0A 00 00 00 00 3B 0D 00 00 p...........;...
00 00 ..
Filemark False
EOM False
ILI False
Sense key ILLEGAL_REQUEST
ASC SEQUENTIAL_POSITIONING_ERROR
ASCQ MEDIUM_DESTINATION_ELEMENT_FULL

Is there a chance that your original post had the import/export events & errors reversed?  You originally reported that the import failed with "E0008214 source location empty" but I am seeing the opposite (destination full) in your logs.

Thanx for looking into that. I really can't follow the logic of the BE.

Here is what we try to achieve: Because usually the weekly full backup fits onto one tape and there is no IT personal around to manually start jobs I thought that: 

- The export after backup knows which tape it used and therefor can export it to the portal.

- We trained one person at the site to once a week open the portal slot, pick the tape manually, insert the new tape and close the slot again. We exptected that a scheduled Import could do the rest. It could pick the tape from the portal slot and move it to any empty inside slot. This should work because BE should "know" which slot it empty.

But it looks as if this expectation is wrong. If Import fails we don't need to debug the failing export. Do you have any idea how this could be resolved?

Larry_Fine
Moderator
Moderator
   VIP   

As far as I know, it is not, nor has it ever been, possible to run an import job against the library in general.  You always have to specify the target slot in the import job.

I agree that your scenario & desire make sense, so I would suggest you pass it along as a product enhancement.  I am not sure the best way to do that now though.  There used to be a section on the forum here for ideas and suggestions, but I think it is gone.

pkh
Moderator
Moderator
   VIP    Certified

You can achieve what you are trying to do.  I did what you are trying to do with my jobs.

You should add the tape export as another stage so that after the backup, it would be moved to the mailslot.  Do not use another job and schedule it because this job will not know which tape is used by the backup job.

To import a tape, you need to specify a specific slot.  If the slot is not empty, the import will naturally fail.  Unless you can ensure that the slot that your import job target is free everyday, you need to use a BEMCLI script to find an empty slot for the import tape to go to.

You should set up a very small backup job (backup one file) with an export stage to test.  If it fails, then there is probably something wrong with your tape library.

Thanx for the hint with the bemcli. I will test that.

The Backup job in question with the export activated worked fine at the weekend. No idea why.

I will look into it to see if I can add an additional step to the backup

Will post the results here again.

Thanx to all of you. I consider the issue as resolved because:

- The export worked fine after last full backup

- My expectation on the import was corrected as far as it alwas requires the empty slot to definded. It doesn't search for an empty slot during import. Here would be room for improvement.

@pkh Do you have a script for the import available to share here?

Thanx pkh. I will give it a shot

Finally got the time-window to test the script.

Works just perfect now. No Manual invervention required except for the mailslot tape change.

Perfect. Thanx to all contributors. Expecially to pkh.