Yeah, there is a way but it is hokie as far as I am concerned. You have to export the file spaces for the node, delete the file spaces, and import them back to a new policy domain.
-----Original Message----- From: Lisa Cabanas [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 27, 2001 8:54 AM To: [EMAIL PROTECTED] Subject: Re: Domains Question Paul, after the change of the policy domains to the new one, the first backup will bind all the active files to the new mgmt class and related storage pool, and you will have to migrate your inactive data by migrating the entire old storage pool to the new stg pool? Is there a more precise way to move the inactive data, as an improperly set up old storage pool might (probably) contains other data you don't want into the new storage pool. We are in a similar situation-- the mgmt classes/stg pools were originally set up by hardware, OS and type of data. We are getting two new 6M1s to host our TSM servers, and I would really like to make the changeover to a more business-oriented- retention needs model-- but I am afraid that I will either strand inactive data in a mgmt class that I will have to copy over just let expire, or by just letting inactive data default to the default mgmt class when I don't move the yecchy old mgmt class scheme. Either way isn't really a good compromise in my mind. Or have I missed the point entirely? lisa |--------+------------------------> | | "Seay, Paul" | | | <seay_pd@NAPTH| | | EON.COM> | | | | | | 11/26/2001 | | | 10:40 PM | | | Please respond| | | to "ADSM: Dist| | | Stor Manager" | | | | |--------+------------------------> >--------------------------------------------------------------------------- -| | | | To: [EMAIL PROTECTED] | | cc: (bcc: Lisa Cabanas/SC/MODOT) | | Subject: Re: Domains Question | >--------------------------------------------------------------------------- -| Actually, a domain has nothing specifically to do with a storage pool. The deal is the clients are using a default policy domain management class. This management class has a backup group associated with it which can only go to one primary storage pool, maybe a next pool, etc. Multiple management classes could be put under the current policy domain with a new management class (at least in V4 you can do this). But, this requires the dsm.opt file on each client to specify management classes, which is probably not what you want. If you change the policy domain of the clients to new ones with different storage pools you can move the data to the new storage pools and a rebind to the new management class will occur on the first backup. I recommend you setup a little test server to test out everything before you try this on a production server. Now for your real question. How many policy domains? Policy domains relate to your business objectives and need to separate data into default management classes easily. Some of the TDPs (Oracle, Exchange, SQL Server, DB2, etc) require/recommend separate policy domains from the client backup which you probably do not have implemented. I will give you an example. Say you have three areas of business: Office Automation Manufacturing Engineering These could have the same or different server platforms but are distinct business entities. It would probably be prudent to separate them into separate policy domains and storage pools for recovery purposes. You may want to break them down further. As technicians we think in server OS terms AIX, IRIX, Windows, Netware, Solaris, etc., but that is not necessarily the right business model because many times an environment crosses many platforms. The other example that may seem dumb is we use AIX/Windows TSM servers. We send them to their own storage pools just to isolate the restore tapes easily for disaster recovery reasons. Which ultimately, is how your policy organization may come out for your business. The technical reason for several policy domains is TSM administration security. You can segment who can touch what and do to what by policy domain. The TSM Administrator's guide makes a real good book to put you to sleep at night. You should use it for about a week. It will really help you get a handle on the reasons for policy domains and storage pools. In the end, your real question has to do with how many storage pools do you need. That is where you categorize your data by whether collocation makes sense, reclamation makes sense, etc. This is a balancing act. The more storage pools you have the more you have to manage. Pick the proper granularity. In my case I have about 5 primary disk pools, 15 primary tape pools, and 15 copy tape pools, but I have a 40TB, 250+ many platform server environment, with requirements to segregate customer data and all sorts of requirements. Some of my tape pools are the primary and there are no disk pools in the middle. We use a lot of SAN managed tape. -----Original Message----- From: Bill Robb [mailto:[EMAIL PROTECTED]] Sent: Monday, November 26, 2001 10:11 PM To: [EMAIL PROTECTED] Subject: Domains Question Folks... ADSM 3.1 was implemented in my shop about 5 years ago (on a mainframe server). At the time, we had 5 Netware Clients, and about 7 AIX Clients, so it made sense to create two domains - one for each platform. As in most shops, we've experienced an Open Systems growth explosion, to the point where I now have approx 30 Netware clients, and 60 UNIX clients, still defined to the original two domains. My server is TSM 4.1, running on S/390. My storage pools for the two domains - from disk to copy pool to offsite tape storage have all grown huge. My feeling is that maintaining the entire environment within two domains is inefficient - backups, migrations, etc take far too long, and I don't dream of turning on collocation. My questions are: 1) Do most people run their servers with fewer, large domains, or is it prevalent to operate with many smaller domains defined with less client nodes attached? 2) If a new domain is defined, how do you move a node, and all it's backed up files, from one domain to different new domain ? Thank you, Bill Robb
