Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

Random Partitioning possible? (Due to media sets not restrain BE's media access)

Created: 28 Aug 2013 • Updated: 28 Aug 2013 | 3 comments
This issue has been solved. See solution.

Dear BE users and supporters,

after learning that BE's tape allocation in a tape robot/ autoloader will not be restrained by having different media sets but only by partitions, I tried to do it that way.

However the implementation of the partitioning is "very basical" and not like the nice way media sets are assigned (create a media set, give em a nice name, select some tapes RANDOMLY and assign them to the media set). In a media set, You can afterwards add and remove tapes at random within seconds. Very nice!

The partitioning is "less intuitive", frankly speeking.

- 1. Is there any way to RANDOMLY adding tapes to a partition? (E.g. slot 10-20 and 50-60). Until now I am only able to add one consecutive sequence to a partition (that shall later restrain BE's wild tape allocation scheme).

- 2. Is there a way to give the partition a name

If 1. is not possible: This is a problem, if You already accessed tapes via the "wild" media set way. E.g. within the attached image BE2010 grabbed a new tape (#087) from the scratch media set (even though there were other free tapes available within its own target media set #040 - #069) and added it ITSELF to the target media set.

/connect/sites/default/files/users/user-2713741/20130828_BEAllocatesAtRandom_PartitioningDoesNot.png

Now I have a problem creating the partition for the job targetting the partition, since I don't know how to tell BE, that my desired partition shall include tapes #040 - #069 and tape #087 (that BE itself grabbed). Since a backup job IMHO can access only one partition, I don't know what to do here.

- Is there a way to "move" tape #087's content by hand to e.g. #069 without messing up the catalog?

Please help me, since I am not the only one that want's to restrain BE's excessive tape usage from other media sets...

GuenTech 07 Jul 2012 :

I would rather the job FAIL and wake me up, then have to go chasing down tapes that BE decided to "steal" to make another job run with sucess

Give that man a beer!

Operating Systems:

Comments 3 CommentsJump to latest comment

Larry Fine's picture

1. no

2. no

I think you need to export your tapes, then setup your partitions, then re-import your tapes into the desired partitions.  there should be no need to re-catalog anything.  Simply run a scan job (assuming you are using bar code labels, otherwise run an inventory job) and BE will know where everything is now.

BE doesn't allow you to move a tape from slot to slot, but your library interface may offer than feature.  If so, you can use that as often as needed, then just run a scan or inventory job when you are done.

If you find this is a solution for the thread, please mark it as such.

SOLUTION
dl2rcf's picture

Thanks Larry,

even though I afeared the answers. But thanks for the idee that I can move tapes manually from slot to slot in the robot and then run an inventory within the robot (perhaps even in BE) afterwards.

Will do that with tapes "stolen" by BE's Media Set policy and avoid this in the future using those "rudimental" partitions

Thanks!

CraigV's picture

...there is already a discussion around this where your questions are answered.

But again, yes, partitions will prevent jobs from pulling media from another media set or partition. Effectively each job is "ring-fenced" to see what it is allowed to see (ie. partition containing tapes which are allocated to a specific media set).

Also...exporting/importing tapes is very long-winded, as is getting the library to move tapes around in the library's interface. Simply unlock the library within BE, unlock the magazine/s, and then move the tapes around manually before running an Inventory job within BE...much faster, less constant interaction on your part.

Thanks!

Alternative ways to access Backup Exec Technical Support:

https://www-secure.symantec.com/connect/blogs/alte...