Indeed you are correct. Though isn't that collocation going to go out of
the window on the 2nd days migrations? The daily chunks of data will be
together, but all node data would be on the same tape until it gets
filled.
I cannot agree more on you last sentence! :)
Steven
Steven Langdale
G
On Dec 17, 2009, at 5:31 PM, Steven Langdale wrote:
In that case you must be using collocation (albeit by accident).
Not really... Remember that, within Migpr, migration operates
serially by node, and thus you get a certain amount of same-node data
clumped together on sequential media. It's
In that case you must be using collocation (albeit by accident).
You may want to look at group collocation as it sounds like your tapes are
probably underutilised. Unless that is you have manly fewer, bigger
clients.
Steven Langdale
Global Information Services
EAME SAN/Storage Planning and Im
I understand how offsite pool reclamation works, but it is not going to
reclaim the entire storage pool unless you set your threshold shockingly
low. Otherwise, it is only going to skim off the few highly reclaimable
tapes. I have a lot of high quality tape drives, but not enough to
re-collocate
>>I am not sure if collocating a copy pool is beneficial. It seems like the
copy pool as a disaster recovery pool would be ideal to collocate, but
if you send off tapes every day you end up with a fragmented set of
tapes for each collocation unit anyway. To clean that up would require
bringing of
Gardenia?
Collocation directs TSM to store the data for a particular group of
nodes, node, or filespace on as few volumes as possible. As Medhi
Salehi noted, it keeps tape mounts to a minimum for restores, but it
opens many more tapes.
In primary pools if you collocate by Node, each Client will o
The benefit of collocation is in restore time, because tape mounts will be
reduces for restoring each client. If there are not enough tape drives
defined in TSM server, more tape mount during backup is natural.
