Roger,

if we have to talk about the safest way it has to be export/import node.
With full backup you ensure only the latest copies of the files are on the
server. And what can we do if after node's data deletion on serverA we
realize nodeXYZ was struck by a virus and we have to restore from PIT
backup?
And with careful planning the move is not so dangerous as you think. Our
careers are in our hands and performing this task for 3-4 months using
export/import instead of 1 week might also be not so beneficiary to the
careeer.
There is always better way to do it, we just have to find it.

Zlatko Krastev
IT Consultant




Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
Sent by:        "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To:     ADSM-L AT VM.MARIST DOT EDU
cc:

Subject:        Re: Server partitioning using TSM library sharing

Oooh! This gives me the heebie-jeebies! I think you really need to sit
down and think about whether you want to pursue this strategy at all. It
just sounds very dangerous, with a downside risk that you might not even
be warned when data is destroyed. These are too many risks to take with
other people's data.

I'm planning this kind of split as well, for database performance
reasons. However, I'm going to start with an empty database on Server B,
switch each node that I want to move so its dsm.opt points at Server B,
let it make a new full backup, and then delete it from Server A after
the expiration of the inactive retention period. This removes all doubt
about the integrity of the scratch pool and whether or not collocation
actually worked. It's a much longer process, and a fair amount more
work, but I'll be able to sleep at night.

And, starting with an empty database will have the side benefit of
better server performance for Server B, compared to a full database from
which half the stuff has been deleted. (Which will be the condition of
Server A's database under any plan.)

Take this seriously - an avoidable blunder that wipes out a bunch of
people's data at once would not be a good career move.

Roger Deschner      University of Illinois at Chicago     rogerd AT uic DOT edu


On Mon, 22 Jul 2002, Cook, Dwight E wrote:

>Whew, being mighty bold but you ~might~ be able to get it to work...
>I'd do everything with the library NOT available to the system, this
MIGHT
>allow you to clean out references to volumes not used on each system
without
>causing them to roll scratch.
>Even if you do this you will still need to go in and alter the category
of
>the tapes bind private volumes to the new private category of which ever
>server you set new categories for (be it the new one or the old one)
>That is, say your existing server is using 300 & 301 for private and
scratch
>categories... your new/other server, you will need to alter the private &
>scratch categories to somethings new like 400 & 401
>for that you can use something like
>        mtlib -l/dev/lmcp# -C -VABC123 -s012C -t0190
>AND remember, just because you have collocation on doesn't mean the data
is
>fully isolated ! ! !
>You still might have data from one node out on a tape with data from
another
>node.
>
>About the only way you could test this would be to restore the DB to a
test
>server, delete all the data from one of your sets of nodes, then note all
>remaining private volumes (make sure this box doesn't have access to the
>library, and to be safe, I'd take it off the network while testing
things).
>Then restore the data base again and delete all the data from the other
set
>of nodes, then note all remaining private volumes.
>If those two sets were totally unique, then your process (I believe)
would
>work.
>If you had ANY overlap in your sets of private volumes, you couldn't
perform
>your task...
>        you would have to do a move data against that volume to try to
split
>out the data on it and start over with your check.
>Logically, your process ~should~ work IF all data is really collocated
but
>you will have to be very careful...
>
>Dwight
>
>
>
>-----Original Message-----
>From: Scott McCambly [mailto:mccambly AT ATTCANADA DOT CA]
>Sent: Friday, July 19, 2002 3:27 PM
>To: ADSM-L AT VM.MARIST DOT EDU
>Subject: Server partitioning using TSM library sharing
>
>
>Hello fellow TSMers,
>
>We have a fairly large TSM server that we are planning to partition into
2
>servers. In other words, add a second server and split the client nodes
>across the two.
>
>The hardware environment is two AIX TSM servers, both fibre attached to a
>10 drive 3494 ATL.
>
>What I am proposing to do (and looking for input) is as follows:
>
>1) Restore a copy of TSM server-A's database to the new TSM server-B
>2) Reconfigure the library and drive configuration on TSM server-B to be
a
>library client to the shared library manager server-A.
>3) Identify the nodes that are to be associated with each server.
>4) Identify the volumes associated with the nodes for each server
(Storage
>pools are currently fully collocated by node).
>5) Run update libvol to change the owner on the appropriate tapes to be
>owned by server-B.
>6) Delete the filespace and node definitions for the nodes NOT associated
>with each server.
>7) Reconfigure half the nodes to point to the new server-B.
>8) Pat myself on the back and take the rest of the day off :-)
>
>It seems too simple....  Has anyone done this before? (hard to type with
my
>fingers crossed)
>
>The big question of course is: what happens to volume ABC123 on server-A
>when the filespaces are deleted and the volume empties, gets deleted from
>the storage pool, and returned to scratch? Server-B still thinks there is
>data on that tape and this proposed solution would only work if he was
>allowed to request a mount and read that volume.
>
>Any and all feedback is appreciated!
>
>Scott
>Scott McCambly
>AIX/NetView/ADSM Specialist - Unopsys Inc.  Ottawa, Ontario, Canada
>(613)799-9269
>