We have a BackupExec 2012 media server directly attached to two robotic libraries by SAS. When backup jobs run on more than one tape, they usually stay confined to one library and everything stays happy. Sometimes (rarely), a backup job that spans more than one tape starts the job in one library and then (for some reason) starts writing to another tape in the other library. BackupExec finishes the backup fine in this case, but during the verify that comes after, the job waits for the tape in the second library to be inserted into the first. When this happens, I find it easier to cancel the job and run a new verify job on that backup. The new verify job succeeds with no issues. This happens more frequently if the job spans three tapes and has only happened once when the job spans two (in this particular instance, it happened at the same time a three tape job jumped libraries, so it may be related). Both libraries have plenty of tapes that can be overwritten, so there's no reason that I can think of for the job to have started using a different library. Aside from that, there seems to be an issue in the post backup verify stage that doesn't like that the job used tapes in more than one library. When this happens, the job will sit on the first library that was used for the backup waiting for a tape that resides in the second library and continue to send emails asking for the tape to be inserted.
Here's how one such example played out:
* Job starts and selects tape 1 from library A.
* Tape 1 fills to capacity and selects tape 2 from library A.
* Tape 2 fills to capacity and selects tape 3 from library B.
* Job finishes before filling tape 3.
* Verify starts on tape 1 in library A.
* Verify finishes tape 1 and moves on to tape 2 in library A.
* Verify finishes tape 2 and sends an alert that it needs tape 3 to be inserted into library A (even though BackupExec knows that tape 3 is in library B).
* I get annoyed with the email alerts and cancel the backup job.
* I submit a verify for the canceled job (which, by the way, shows the correct byte count for such a job at roughly 1.7 TB)
* Verify job successfully finds all three tapes and shows the same byte count as the canceled job.
While jumping from library A to library B isn't exactly how I think the backup needs to run, it's probably unimportant that this behavior change. What I would really like to see changed is the logic that the new verify job used to successfully find all three tapes be applied to the backup post verify. Just to be complete, every backup job to these two libraries is allowed to append first, then overwrite. This process has been working fine, for the most part. Sometimes, append jobs somehow leave behind an extra appendable tape. This is a separate issue and only a very minor annoyance. I just end up moving out some extra tapes that still have free space on them from time to time, but it's no big deal. Each library holds 22 tapes and it's never been so bad that I've had to move out more than two appendable tapes (leaving two behind, because they'll just be appended to anyway).