Replies inline

Thomas Ashby wrote:

> On 2 of our backup servers, both running Backup Exec for Windows NT 7.3 build
> 2575, I have observed the following problem.
>
> The slots in the Autoloaders on these systems have been partitioned using
> PARTUTIL.EXE. Some of the partitions are 2 or 3 slots in length. We do
> this because we want the backups of specific servers to go to specific (pre-labeled)
> tapes, which will be retained for varying durations and which are stored
> in both offsite and onsite locations.
>
> In one example, a partition is defined for slots 5 and 6. The backup job
> loads from slot 6. When the end of the tape is reached, the message: Warning
> .. A library operation has been attempted that is invalid at this time ...
> The media provided to continue the backup already contains data from one
> or more sets created during this operation. The operation can not be continued.
>

Because it grabbed the last slot first, it can't continue.

It may be a pain for a while, but when you swap magazines, re-label the tapes in each
partition, starting with the lowest numbered slot. BENT uses the "oldest" scratch tape
that it can find first. By re-labeling this way, the first slot should be the oldest
tape.

Once you have done this for a complete rotation of tapes, BENT should then continue OK.

>
> In another example, a partition was defined for slots 5, 6 and 7. When the
> backup job runs, the tape in either slot 5, 6 or 7 will be loaded. When
> the backup job reaches the end of the first tape, often a tape from *** slot
> 1 *** will be loaded and used.
>
> Therefore, in the 2nd example, the backup job is overlaying other production
> data and has been for quite some time.

I have no idea why it's grabing a slot out of the partition, but if you hve your media
set properties defined correctly, the job should pause and ask for a scratch tape, not
overwrite another valid backup.

>
> I don't know how long this has been going on for us, but this is a serious
> problem.
>
> Is this a known problem in Backup Exec and is there a way to correct it?

Ken,

Thanks for responding. I checked the backup logs and determined that in
some cases, the backup job did successfully load the 2nd tape from a lower
numbered slot in the correct partition. In the 2-slot example, the only
2 tapes in the autoloader were in the 5-6 slot partition, so that may be
the reason it failed.

Tom


Ken Putnam wrote:
>Replies inline
>
>Thomas Ashby wrote:
>
>> On 2 of our backup servers, both running Backup Exec for Windows NT 7.3
build
>> 2575, I have observed the following problem.
>>
>> The slots in the Autoloaders on these systems have been partitioned using
>> PARTUTIL.EXE. Some of the partitions are 2 or 3 slots in length. We
do
>> this because we want the backups of specific servers to go to specific
(pre-labeled)
>> tapes, which will be retained for varying durations and which are stored
>> in both offsite and onsite locations.
>>
>> In one example, a partition is defined for slots 5 and 6. The backup
job
>> loads from slot 6. When the end of the tape is reached, the message:
Warning
>> .. A library operation has been attempted that is invalid at this time
...
>> The media provided to continue the backup already contains data from one
>> or more sets created during this operation. The operation can not be
continued.
>>
>
>Because it grabbed the last slot first, it can't continue.
>
>It may be a pain for a while, but when you swap magazines, re-label the
tapes in each
>partition, starting with the lowest numbered slot. BENT uses the "oldest"
scratch tape
>that it can find first. By re-labeling this way, the first slot should
be the oldest
>tape.
>
>Once you have done this for a complete rotation of tapes, BENT should then
continue
>OK.
>
>>
>> In another example, a partition was defined for slots 5, 6 and 7. When
the
>> backup job runs, the tape in either slot 5, 6 or 7 will be loaded. When
>> the backup job reaches the end of the first tape, often a tape from ***
slot
>> 1 *** will be loaded and used.
>>
>> Therefore, in the 2nd example, the backup job is overlaying other production
>> data and has been for quite some time.
>
>I have no idea why it's grabing a slot out of the partition, but if you
hve your media
>set properties defined correctly, the job should pause and ask for a scratch
tape, not
>overwrite another valid backup.
>
>>
>> I don't know how long this has been going on for us, but this is a serious
>> problem.
>>
>> Is this a known problem in Backup Exec and is there a way to correct it?
>