A question that frequently come up by TSM Admins that “how to move Nodes to a new Domain?” This is usually the case when you had grouped several nodes under one domain then you needed to change the backup policies for few of them, so you find out the need to move these few nodes to a new policy Domain. Below is a high view of the steps to Move Nodes to a new TSM Domain:
1. Define the following… New Policy domain, policy set, related sequential and copy stgpools, management class(es), copy group(s)
2. Assign new management class as default management class
3. Validate and activate new policy set
4. Update node to reflect domain change
5. Update associated client backup jobs by copying the old schedule(s) to new domain, update new schedule(s) accordingly, associate copied schedule(s) to updated nodes, delete old schedule(s) from old domain.
6. Run a move nodedata specifying from=old_sequential_stgpool to=the_new_one
7. Run a backup stgpool from the new seq. stgpool to the new copy stgpool.
8. Take into account the new stgpool in any admin schedules or scripts you have set up.
9. Recall copy stgpool tapes for old domain, or let the data expire off. You can, if you so desire, after recalling the tapes, move nodedata to scratch tape and delete the volume when complete with discard=yes.
Please leave me a comment if you had a success or a failure following these steps :).
One of the server already decommission and have to retain one year. Instead of creating new management class for 1 year, I copied the existing policy domain that the nodes tie to and changed all the vere=nol, ver=nol, rete=365,reto=365, activate and assign the nodes to this policy domain.I’m not sure whether this is working which the data will retain 1 year and can the data be restored using this new policy domain. No final backup taken suing the new policy domain.
Hi,
I am not clear about your scenario, its not exactly clear to me what you are trying to do.
But I would say always be very careful when removing a node from a policy domain, as all the backup data for that node will regarded being expired. Its almost like telling TSM that server is removed from the environment for ever and that data its keeping is useless.
I hope that help. If you can provide a bit more collaberation about what you exactly trying to do, I might be able to help you better.
Hello Guru,
I am in the process of reorganizing our TSM data storage strategy. Ideally I would like to move about 15 nodes out of our old policy domain to a couple of new policy domains. All of these nodes have archives of varying lengths. If I create an archive management class with the same name will the archives be retained for the same period of time in the new domains?
The scenario is the servers were decommissioned before I have chance to assign those nodes to management class that retain data for 1 year. Since those nodes were tied with default management class, I assume the data for this node will expire in 60 days time. Since the customer would like to retain data for 1 year, I’m taking my creativity in solving this problem by copied the current policy domain that the nodes bind to and change the copygroup retain data to 1 year and assign this node to the new copied policy domain. So I’m not sure this going to work IF someday they need to restore the data in this 1 year time.
Hi Anyerazs,
I am sorry for the bit late reply, but I was busy with my dad being hospitalized. I am worried that your planned method won’t work. If you are to move the nodes to a new policy domain, I would highly recommend you follow the method I explained above. In simple word the order of doing so is:
1- Create a new policy domain with all the needed configuration and the expiry required. Make sure you activate it and you set the expiry information correctly before you move the node to it. Else you can hit a disaster, if the expiry in the new policy was too soon when the node is moved to it.
2- Change the configuration of the client to point to the new Policy domain.
3- Run a move nodedata specifying from=old_sequential_stgpool to=the_new_one <== Please note this is a very important step. As most people forget this, and their data does not get moved or pointed to the new storage pool, and does not get managed by the new policy. So make sure you handle this correctly.
Please read the post carefully, and follow all the instructions in doing your move, don’t take any short cuts with your data, as that can lead to disaster when you try to restore later.
I hope that help, and let me know if you need any further help.
Thanks for your suggestion and I will keep that in mind. Speedy recovery to your dad.
What happens if you dont do the move data. So the node starts backing up and it’s copydata starts building up in new domain. But what happens to the old domain’s data and it’s copypool? Since your not adding or purging data, i assume it justs stays around? Can you access it (i.e. flip node back and pull up restore gui)? Can you still see it’s filespaces under node data summary? What if you wanted to delete the old data later?
You really should not think of doing this period. I mean you are risking to lose your old data as soon a lovely expiration process run in your environment. Not to mention that might be the next morning if you are automating that task!! For the old policy you are taking off the old node out of your environment and all the data on it will be inactive and most of the versions will expire so fast depending on your expiration settings.
I would not put my company or my customer data into that situation, would you? I would recommend you follow up the move data procedure stated š .
Enjoy,
TSMGuru
Hi, just one doubt.
Whic command and parameter do I have to use to move my node to the new domain.
Thanks.
That was step 6:
6. Run a move nodedata specifying from=old_sequential_stgpool to=the_new_one
You will have basically to use the move command as shown above. Please though make sure you follow the other steps in the article to make sure you don’t miss any step. Furthermore, I would recommend you practice this move on a test environment before carrying it out on your production.
I hope that help.
Hello Guru,
I think, I just express myself wrong. My doubt was regarding step 4.
In this step 4, which command and parameter do I have to use to move my node to the new domain.
Thanks.
Hi Sae,
Sorry, I guess I miss understood your original question as it was not obvious.
Though as step 3 said “update node” is the command it self. You can use “help update node” to find out all the options of that command, though below is the command with the basic parameters to change your node to a new domain.
update node nodename -domain=domainname
I hope that answer your question, & good luck.
Thanks Guru for the help.
I have another question (sorry for asking too much).
In my scenery, I received a TSM solution (that has many different clients) where for some strange reason they created too many Policies domain for one same client. I’m trying to arrange this consolidating one client by one policy domain.
In the case of this particular client (called it ABC) we have the following:
* We have one TSM instance
* ABC has like 5 policies domain
* Some nodes of ABC in different domains use the same stgpool
* Others domains of ABC have exclusive stgpool
So here are my doubts:
1) Just like Jonathan asked you, it is possible to just define the all the MC of the different policies domain with the same retentions and version they have and then move the nodes in one ABC policy domain, OR
2) I have to create a no limit MC, make it default and then move the nodes.
3) And regarding the issue of the move nodedata, it is necessary even though my stgpool are going to we define in the new MC and belong to the same DEVCLASS
I hope, Iām not asking too many questions.
Thanks in advanced,
SAE.
Hi Guru,
I don’t know where i should ask this question in this blog. Hope u can reply me on this. My question is, what is the tricks to get how many drive being used by a backup? In other words, I would like to check on past successful backup, using how many drives. Is that possible to check?