Just thinking out loud.
Do the first two steps you've mentioned.
- Disable client access on the TSM server in question
- Disable expiration scheduling on the TSM server in question
Migrate/copy disk storage pools.
Free disk storage pool volumes for use by new instance below.
Move the existing server instance to an unused set of port values, and
change its name. (Would this hurt volhist?)
Notes which tapes are private, scratch, etc. Checkout all tapes, but leave
them in the library.
Open library, and set write protect tabs on tapes.
Create a new server instance at the old port numbers, and export old server
info to it.
Setup server to server communicaitons between instances.
Setup new instance as library manager. Checkin tapes in library as private,
scratch etc, to match above. Update owner of private tapes to new name of
old instance.
Update private tapes to readonly.
Update tape pools on new instance with scratch counts. Add disk from old
instance to new instance for disk storage pools.
Setup old instance as library client. Consider adding disablescheds to old
instance dsmserv config file.
Checkin new scratch tapes as necessary.
Make sure "dsmc q sched" works on client. If not, make sure passwords are
recached on clients.
Prepare to buy server memory and library frames and/or more tape as
necessary.
Oops: Do a bunch of exports with merge from the old instance to the new
instance.
[RC]
"Allen S. Rout"
<[EMAIL PROTECTED]>
Sent by: "ADSM: To
Dist Stor ADSM-L@VM.MARIST.EDU
Manager" cc
<[EMAIL PROTECTED]
.EDU> Subject
Re: [ADSM-L] Retention Request
Problem
07/15/2005 11:11
AM
Please respond to
"ADSM: Dist Stor
Manager"
<[EMAIL PROTECTED]
.EDU>
==> On Fri, 15 Jul 2005 09:06:42 PDT, Sam Sheppard <[EMAIL PROTECTED]>
said:
> Our main customer is having some potential legal problems and has made
the
> following request:
> "I am requesting that all File Server Backups taken prior to June 15,
2005
> be preserved pending further instructions."
Well, when you get extreme requests...
I've thought about just such a request, and I came up with:
- Disable client access on the TSM server in question
- Disable expiration scheduling on the TSM server in question
- Start generating N backupsets at a time, where N is your count of beefy
tape
drives, divided by 2. :) You are collocated, right?
Huge disruption of ongoing backup work, yes. But it's a hugely disruptive
request. Then send complainers to the legal folks.
Luckily, while 4-5 TB of data is still rather a lot, with current tech it
ought to be doable in one or two 24-hour days.
Unless you're non-collocated. Shudder.
- Allen S. Rout
