Proxy Node

[caldwem01]

Has anyone used proxy node? We are doing a flash copy of a DS4800 from site A to site B. In site B we want to be able to restore a clients data from the flash copy that was created by a Client in site A.



Is proxy node the right way to approach this problem?

If so how does this work?



Thanks

Michelle

 

[heada]

Michelle,



It depends on what you are flashing. If you are flashing the TSM DB/LOG/Pool(s) then you could use a virtualnode to have a client at site B act like the original client at site A. If you flashing the client data then I fail to see why you would need to perform a restore at site B as you have all the current data.



See: http://people.bu.edu/rbs/ADSM.QuickFacts (search for virtualnode)



-Aaron

 

[caldwem01]

Thank you for the response on virtalnode. Can you help clarify, can a client from site B be given access to restore a filespace that was backed up from a client at site A? The flash copy is a copy of all volumes from site A to site B. the filespace resides on the flash copy.

Am I missing something?

Thank you!



<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>Michelle,





It depends on what you are flashing. If you are flashing the TSM DB/LOG/Pool(s) then you could use a virtualnode to have a client at site B act like the original client at site A. If you flashing the client data then I fail to see why you would need to perform a restore at site B as you have all the current data.



See: http://people.bu.edu/rbs/ADSM.QuickFacts (search for virtualnode)



-Aaron</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR></TD></TR></TABLE>

 

[heada]

If the two sites share a common TSM server (or site B has access to the TSM server at site A) then this is very easily done. Simply configure the client at site B to see the TSM server that the client at site A backed up to and use the virtualnod option to make it appear that the client at site B is the client at site A



-or-



If the two clients share a common TSM server, then you can grant access between the two clients so that the client at site B has the correct rights to restore data from the client at site A.



I am still unclear as to what you are flashing between the sites. Are you flashing the client filesystems, the TSM filesystems or both? If you are flashing the client filesystems, then I don't know why you would need to access the TSM backups for that filesystem (unless you want to go back in time vs data loss)



-Aaron

 

[caldwem01]

Thank you for your responses. The nuts and bolts of this is that we are trying to backup an application without bringing down that application for any longer than it takes to run a flashcopy. The thing we are trying to resolve is how do we restore the flashcopy data that was backed up to TSM by another client. Since we don't have an API to do the online backup of the applications data. we are trying this as a work around.



we are going to flash copy an applications data volume (appserver A volume A) on a DS4800 to another volume (volume B) within the same DS4800. We then will use TSM to backup the volume B to another server (ClientServerB). From our understanding ClientServerB owns the backup. So what is the best way to actually restore the TSM data to AppServerA using Volume B which was backedup by ClientServerB. This is where we think Proxy Node might be the answer but can't quite put our finger on it.

Thank you!

 

[heada]

I think I understand what you are trying to do now. You are correct in that any data backed up on appserverB would be owned within TSM by appserverB. In order to restore the data owned by appserverB onto appserverA, you can do either of 2 options.



1) grant appserverA access rights within TSM to appserverB's data(either through the client GUI or making appserverA an admin of appserverB). It will now be able to restore anything that was backed up on appserverB



2) on appserverA, use "virtualnode=appserverB" This will require appserverA to have the password to appserverB.



3) manually change the nodename within the dsm.opt/dsm.sys so that TSM thinks appserverA really is appserverB (not recommended for a daily restore)



(yes, I said 2 options, option 3 is more a one-time deal)



-Aaron

 

[caldwem01]

I am going to give that a try.....Thank you very much!