12-11-2014 06:16 AM
Hi all,
I’ve a problem with our duplicates to tape:
When a tape is full, the job is automatically set to Queued and will not take the next (empty) tape, although there are available tapes.
For your information, I’ll add some details about our configuration:
Back-up Exec 2012
We use media sets, there are enough (empty) tapes available in the affected media sets
Tape drive: NEO400S
Tape capacity: 1.47 TB
We had this issue since we migrated from Backup Exec 2010 to Backup Exec 2012.
The most current back-up exec 2012 updates are installed.
The only customization we did was changing the media description as described in this article.
My question is, does any one of you know how to make a “duplicate to tape” job automatically proceed to the next tape if the current tape is full?
Solved! Go to Solution.
12-23-2014 05:15 AM
Is the next available tape a "scratch" or an "overwriteable" tape ? If not, and if the second tape is only appendable, the backup (or duplicate) cannot move on to the next tape.
12-11-2014 06:31 AM
12-11-2014 07:02 AM
12-12-2014 12:49 AM
Hi pkh,
Thanks for your reply.
On both questions is the answer no, we had no alerts and we don't use the partitions option.
12-16-2014 03:13 AM
does anyone of you know what I can do or check to solve this issue?
12-16-2014 04:24 AM
First, do ensure the option to automatically display new alerts is enabled under BE button - Configuration & Settings - Backup Exec settings - Preferences.
Secondly, under the Storage section of the Duplicate stage, is it set to append to media, overwrite if not available or other option ?
Do all duplicates to tape fail to span to the second tape or are these specific jobs such as GRT enabled backups ?
12-16-2014 05:33 AM
Hi VJware,
Thanks for your reply.
1) I just had enabled the automatically display new alerts. I hope this helps me to find more information about the issues.
2) The duplicates are set to "append to media, terminate job if no appendable media is available.
3) The jobs they are failing are jobs with and without GRT enabled.
For now, I will check there are other alerts and share them here. If you've other suggestions, please let me know.
Regards,
Dennis
12-16-2014 06:00 PM
2) The duplicates are set to "append to media, terminate job if no appendable media is available.
Change this instead to Append to media, overwrite job...
12-17-2014 09:15 AM
Hi VJware,
Thanks for your reply.
I will change the duplicate jobs like as you say. After this weekend (when the duplicates runs) I will check if it's working. Will be continued.
Regards,
Dennis
12-22-2014 04:27 AM
Hi VJware,
Unfortunately it hasn't work, I've just yet the same error: the job is set to queued. I need to cancel the job, otherwise BE occupying the tape drive and thas has as result that the other external jobs can't run.
The logs don't show specific reasons about the failure.
Is there anything that I can do to investigate it more?
Kind regards,
Dennis
12-22-2014 07:45 AM
Have you tried recycling the tape device by executing the steps in the order they are listed below:
Also, if you manually run a job does is it still placed into a "queued" status?
12-23-2014 05:12 AM
Hi Laurie,
Thanks for your reply!
I will try that!
And yes, also the "manual jobs" wil has the queued status. But this is only happens when the tape is full, it's not switching from the full tape to the available empty tape.
Regards,
Dennis
12-23-2014 05:15 AM
Is the next available tape a "scratch" or an "overwriteable" tape ? If not, and if the second tape is only appendable, the backup (or duplicate) cannot move on to the next tape.
12-23-2014 05:46 AM
Hi VJware,
I add the next available tapes to a media set so I think the tape is not specific a "scratch" tape.
For test I will add the tapes to "scratch" and see if this works fine.
I will post the updates about this next monday because I'm not able to test this before the weekend.
Regards,
Dennis
01-12-2015 01:15 AM
Hi VJWare,
Your suggestion helps me to resolve the issue. I've added the tapes to the scratch media set, all jobs are running fine now.
Everyone realy thanks for helping!
Regards,
Dennis