BackUp Exec 2012 - tape/slots which tape takes precedence

[Inspiration]

I'm running Backup Exec 2012. My system is set to run a full backup (Fridays) and incremental (Mon-Thurs)

I am under the impression that when you have many overwritable tapes is the drive, the system will first look for tapes that has matching media set, and ifthere isn't any, it will look for scratch media. When it looks for scratch media, it will look for the one with the oldest date in "Allocated Date".

Am I right on this?

But on a few ocassions it has not followed this "rule".

I'm attaching a screencap of my backup from last night. As you can see from the Allocated date, on Monday I scratched and labelled all tapes in order from Slot 1 to 5. I did this so that the allocation date will be in sequence. But somehow yesterday (Tuesday) it skipped the oldest allocated tape and took the second oldest tape.

Any idea why?

[Inspiration]

Attaching the image file, since its too small above.

[VJware]

Haven't come across this behavior...Was an inventory run prior to the backup job (guessing if the last allocated date wasn't updated properly, then this might be the case)

[Colin_Weaver]

If you want to force jobs to go to specific tapes on specific days then you will probably need to partition your library AND create a separate stage per day with the partition for each days' stage set to the appropriate slot (and the schedule for each stage set to only 1 day per week)

This does have some disadvantages

1) the job will sit asking for media if there is no usable tape in the partition

2) If a job fills the tape mid job, it cannot span to another tape, because it won't choose from outside the partition (you can create partitions based on more than one adjacent slot to help with this)

3) Multiple job definitions needed

4) Extra complexity in configuring each stage.

[Inspiration]

Inventory ran before I labelled the tapes. I did not run it again after completing the label or before the job ran. Could that have been the reason?
 

So it's true that it looks for the oldest tapes right? Any other criteria it looks for?

[Inspiration]

We had partitions before, faced some of the issues you mentioned. That's why I reverted to this way.

[pkh]

When you are using a tape library without partitions, it is very difficult to target a specific tape. If you want to target a specific tape, you might as well save money and stock to a stand-alone tape drive. What you are trying to do is to manage tapes when this is better accomplished by BE and the tape library. See my article below https://www-secure.symantec.com/connect/articles/must-mondays-backup-be-monday-tape Also, you should look into using barcode labels. They are much more efficient. See my article below https://www-secure.symantec.com/connect/articles/using-barcode-labels-why-and-how

[Colin_Weaver]

Ok I had 5 tapes in my library that had all originally been used with a different installation of Backup Exec which meant an inventory job run on 10th April had added them by date/time to the database in slot order and as members of the "Backup Exec and NT Backup" media set.

Today (again in slot order) I moved each tape to scratch one at a time. The Allocated Date/time did not change from April 10th which means your media allocated dates may not have been in slot order (unless you can show us a before screenshot as you seem to have posted after screenshots)

I then erased the 3rd tape (chosen by date order but was also 3rd Slot)

This did change the allocated date to today's date.

I then ran 5 back to back overwrite jobs to the library

- 1st Job used tape in 1st slot

- 2nd Job used tape in 2nd slot

- 3rd Job used tape in 4th slot (expected if we are using Allocated Date)

- 4th Job used tape in 5th slot (again expected if we are using Allocated Date)

- 5th Job used tape in 3rd slot (only remaining overwritable tape so again expected)

The above sequence does seem to show us using allocated date.

As such how did you move your tapes to Scratch?

Did you look at the allocated dates immediately after you moved them all to Scratch to see if they had changed?

Did you confirm that the allocated dates were in the expected order to match the slot order?

Note the main reason I decided to test this is that inside the Backup Exec database we do have a creation date specified against each tape and this date is usually the first time a tape is identified on a media server (and in my case did match the slot order even after the erase). This creation date could, in theory, also have been used to decide an order but the above tests did prove that we do not use that data for the decision.

[Inspiration]

I labelled the tapes after scratching. Without labelling it won't change the allocation date.

Let's see how it is tonight. But usually it does not recur immediately. Maybe once in a month or so and I can't figure out why.

[Colin_Weaver]

OK a label does an erase so that should change the allocation date.

BTW if you sort out your overwrite protection and append settings you should not have to move to scratch or re-label media. PKH has written some informative documents on the subject which I believe he has already referenced in this thread.

The problem with it being intermittent and not reproduced by us is that we would need to capture the exact state of the media prior to the job running and the state of the media the next day, every day until it happens again. However as you are scratching media then a simple way to achieve what you want, is scartch the tapes daily instead of weekly and only scratch the tape(s) you want that night's job to use. You may need to slightly increase your overwrite protection with this workaround so that the other tapes won't become overwritable at the same time. Please note that this is not a recommendation it is just an option that would force your jobs to specific tapes (again like library partitioning will potentially cause issues)

[Inspiration]

Just to update, last night's backup took Tuesday's tape, as it should since that was the oldest. Still no idea why Tuesday night's backup took Wednesday's tape but nevermind.

These are a set of brand new tapes I put in, so by the next round of backup, the overwrite protection won't allow wrong tapes to be used. Ofcourse I'll have to swap the Tuesday and Wednesday tapes due the the mixup.

I'll have to monitor this issue, but it rarely happens so I can live with it.