I can't speak to the "sign on to server failed" message. Try an EXPORT <node> TOSERVER=<target-server> PREVIEWIMPORT=YES command.
You should see activity log on both source and target server, also processes visible on both via Q PRO. That should let you know if the comm path is working. I recently used export to migrate several large nodes to a new server. Took a few days to get through the data for each node, so I used multiple EXPORT commands with various FROMDATE=mm/dd/yyyy MERGE=YES options to gradually migrate the data. Consider adding SUSPEND EXPORT and RESTART EXPORT in your admin scripts. The node continued to backup to the original server during the days the exports were being managed. In the end, the last EXPORT dealt only with "last nights' backup" data and finished quickly. Then, had the node manager edit the DSM.OPT to spec the new TSM box. They should open the GUI to make sure it gets connected. Thanks to Wanda.... she helped me get the export method streamlined. ------------------------------------------------ Harold Vandeventer Systems Programmer State of Kansas - Office of Information Technology Services [email protected] (785) 296-0631 -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[email protected]] On Behalf Of Dury, John C. Sent: Thursday, October 04, 2012 9:51 AM To: [email protected] Subject: [ADSM-L] move nodes from one server to a different server via export Please ignore my previous post about trying to def a target server to source server and it failing. It looks like it works even though I still can't ping the target server from the source server. The replication works correctly though. A brief description of our environment. We have 2 datacenters. Let's call them Site A and site B. Both sites have TSM nodes which are all now currently backing up to the TSM server at site A. We would like to have a tsm server at both sites and have the clients at each respective site backup to their local site, and then replicate that data to the other site. I was hoping to be able to replicate node data from site A to site B and then convert that node to a regular node so the node at that site could then backup to site B. It doesn't look like there is any way to do that so the next choice is to export the node from server A to server B and then change the node so it backs up to server B instead of server A. Once that is done, I can enable replication between sites for that node so it will replicate from site B to site A and thus we have a DR solution for all of our nodes. Because this is tremendous amount of data I'd like to only have to send the data once from site A to site B via the export, and then use replication to replicate daily changes from site B back to site A which should be minimal data changes since the node data already exists at site A. Is this possible? I have both servers defined to each other and when I try to export a node's data from site A to site B I get: ANR0561E EXPORT NODE: Process aborted - sign on to server,<site B> failed. (SESSION: 118112, PROCESS: 318) Both servers have my admin id defined with the same password and both servers have the same password (although I don't think that matters). Site B was defined to site A via: def server siteB pass=server hladdress=*.*.*.* lladdress=1500 I also tried the other syntax: Def server siteB serverpass=password hladdress=*.*.*.* lladdress=1500 I also tried defining a node on siteB with the name of the server at siteA and type=server Force sync also didn't help. No matter what, I get the "sign on to server failed" message. Is it me, is "def server" extremely buggy?! [Confidentiality notice:] *********************************************************************** This e-mail message, including attachments, if any, is intended for the person or entity to which it is addressed and may contain confidential or privileged information. Any unauthorized review, use, or disclosure is prohibited. If you are not the intended recipient, please contact the sender and destroy the original message, including all copies, Thank you. ***********************************************************************
