Moving nodes to new Domain

melfaro

ADSM.ORG Member
Joined
Dec 21, 2004
Messages
21
Reaction score
0
Points
0
Hi all,



Due to new biz requirements, I need to change the retention period of 4 nodes:



Monthly - 365 to 60 days

Weekly - 60 to 30 days



I can't just change the settings on the current Management class as there are other nodes assigned to it. I think creating a new Domain then move these nodes in. Does anyone now the steps involved to do the move including the data backed up?



Thanks.
 
I've had to do this on numerous occasions, and this is what I did.



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.





Hope this is helpful. If you a question on any of the commands, just shoot me an email.
 
Thanks Cbell for this..



I forgot to mention that the nodes are going to the same stgpools and for the weekly and monthly backups its required that a selective backup is to be performed.



I am considering creating 3 nodes for each server like:



SERVER_DAILY - Incr

SERVER_WKLY - Sel

SERVER_MTHLY -Sel



Should I put them all in the same domain and just create a mgmt class for each? What parameters should I add in the options file or configure the schedule for the Selective backups?



Also, since they are going to the same stgpool, do I still need to move the data?

Thanks.
 
Uhmm...let's see...



Creating the three separate is a judgment call, I probably would not. The only times I create seaprate nodes that actually will all reside on the same client is if there are directory or file-specific backup schedules requested by a user.



And I may be wrong, but I would not create extra management classes and disperse them because of the extra selective backups. The way that expiration will handle the inactive files for you, it won't be necessary, I wouldn't think.



Also, if only the tapes you will be moving data from contain only data for the nodes you want to move, you could run a move data, as opposed to move nodedata. However, if the data needing to be moved is mixed with data you wish to stay on the other domain, you will need to run a move nodedata for each node.



Someone else want to jump in? I don't want to steer melfaro wrong. ;)
 
What version are your clients? If I'm not wrong, in 5.3 clients you can specify in the dsm.opt the management class you want to use in the incl/excl list. If your clients are 5.3, you don´t need to create another policy domain, just create another management class with the settings needed, and tell in the dsm.opt to use this class.



<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font class="pn-sub">Quote:</font><HR></TD></TR><TR><TD><FONT class="pn-sub"><BLOCKQUOTE>Hi all,



Due to new biz requirements, I need to change the retention period of 4 nodes:



Monthly - 365 to 60 days

Weekly - 60 to 30 days



I can't just change the settings on the current Management class as there are other nodes assigned to it. I think creating a new Domain then move these nodes in. Does anyone now the steps involved to do the move including the data backed up?



Thanks.</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR></TD></TR></TABLE>
 
Hi,



I eventually created a new Domain, and updated the nodes to move to this domain. I did not have to do a move nodedata as they were going to the same stgpools.



As for the wkly and mthly backups, I created an admin script to update the backup copy group from modified to absolute every Sunday to do the "full backup", and back to modifed on Monday for the incremental. I also scheduled mthly archives.



I know this defeats the purpose of TSM but I have to keep everyone happy. :)
 
I'm going through this exact same procedure. My set will only retain 2 days and I am switching from 6 days. My question is what happens to the data past 2 days when the policy domain is switched. Does the information expire now or does it have to be manually expired in order for the data to expire now, or is it better to let the time limit pass and have TSM expire the data itself?

Sorry if this is an old thread, I was googling this problem and this forum came up. Since I've found quite a few answers to my problems here I figured it'd be the perfect place to post.

Thanks in advance for any input.
 
I'm going through this exact same procedure. My set will only retain 2 days and I am switching from 6 days. My question is what happens to the data past 2 days when the policy domain is switched. Does the information expire now or does it have to be manually expired in order for the data to expire now, or is it better to let the time limit pass and have TSM expire the data itself?

Sorry if this is an old thread, I was googling this problem and this forum came up. Since I've found quite a few answers to my problems here I figured it'd be the perfect place to post.

Thanks in advance for any input.

When you switch the node to from the 6 day to the 2 day policy domain, data will be deleted the next time expiration is run. If you switch the other way, from the 2 day to the 6 day nothing will happen - but when you switch back to 2 days again you'll lose the extra 4 days. Be very careful here...........

The last poster did not end up using the domain switch method. He used archives for the longer retention instead.
 
Actually we are backing up 260GB per night for a DB backup, and a retention period of more than a few days is really not an option for us. I would like to keep files for 4 or even 6 days but only have 2 files out there ie dbBackupForToday and dbBackupForYesterday. I don't want to keep the backup for 3 days ago, but with how TSM works I don't think this can be done without some kind of manual intervention. But if you have any ideas I'd be more than willing to explore the option.
 
You can definitely do this automatically? Put the node in a domain with default retention of 2 days and you're done. Or add a new MC to your existing domain with a retention of 2 days, and then use include options on the particular node that is an issue to bind to that MC, eg include /dbbackup/* MC_2DAYS
 
What I meant to say was I would like to keep the files for 4 or 5 days but only the last 2 files that were backed up. What is happening is the db is being backed up daily with the date as the filename, the admin for the system only keeps todays and yesterdays backups in the folder. So what I would like to do is keep the 2 most current files for up to 5 days but if the file changes I want anything past 2 revisions old to be removed. Kind of a convoluted process but if the files don't change b/c the db crashed for some reason and the admin tries to fix the problem for 3 days then chooses to restore the files wouldn't be out there but at the same time we can't handle the volume of storing too many copies of the db.
I think the best solution would be to have the admin do a backup / rename to 2 files called today and rename the today file to yesterday, that way the retention can be 5 days and only the 2 recent copies are kept.
 
Just set your copygroup settings accordingly to do this.

vde=2 (multiple versions kept 2 days)
vdd=2 (multiple versions of deleted files kept 2 days)
rete=5 (retain extra copies files for 5 days)
reto=5 (retain deleted files for 5 days)

Files will expire when any of the above are met so you will get what you want.
 
Back
Top