Re: Export node to new server
Since you said these are not trivial-size nodes, here are some tricks I've used: a) Don't lock the node, let it continue backing up to the old server. b) Do your export in chunks. Exports that run a gazillion hours seems to always cause problems and end up failing. I cut down the size of each export by using fromdate/todate on the export, like fromdate = 01/01/2010 todate=12/31/2010. When that's finished, do it again, pick up another later date range, then another and another until you get current. c) Then every morning do: export node filedata=all fromtime=now-24 totime=now merge=yes (always use merge=yes). You can even put this in as an admin schedule that keeps your V6 server up to date and in sync, until you can coordinate with the client owner to switch it over to point to the V6 server for backup. This way you don't have to fight scheduling issues, or worry about it for a day when you get distracted by that pesky pager. You just get the 2 servers in sync for that client a bit at a time, then cut it over when convenient. Wanda -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Vandeventer, Harold [BS] Sent: Monday, August 27, 2012 5:13 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Export node to new server Thanks Wanda,... I owe you sumthin! I'll confirm the domains/mgmt classes/retention rules first. Thanks again. Harold Vandeventer Systems Programmer State of Kansas - Office of Information Technology Services harold.vandeven...@ks.gov (785) 296-0631 -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Prather, Wanda Sent: Monday, August 27, 2012 3:58 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Export node to new server Do I follow the virtual volumes setup process? No, use the enterprise configuration form. You won't be creating any virtual volumes. When you export client data, it will land in the appropriate domain/mgmt. class, and get put into the storage hierarchy of the target server. Woe be unto you if you have domains/mgmt. classes with the same names, but different retention rules, when you start the export/import. Then, define the node manually on the target; Not necessary, it will get created with the import. Then: 1: Lock the node. Not really necessary. 2: EXPORT NODE nodename TOSERVER=target FILEDATA=BACKUP EXPORTIDENTIFIER=a value Suggest adding MERGE =YES as standard practice. Wanda [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. ***
Re: Export node to new server
Great help, Wanda... you've been down a lot of TSM paths. Thanks again. Harold Vandeventer Systems Programmer State of Kansas - Office of Information Technology Services harold.vandeven...@ks.gov (785) 296-0631 -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Prather, Wanda Sent: Wednesday, August 29, 2012 3:51 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Export node to new server Since you said these are not trivial-size nodes, here are some tricks I've used: a) Don't lock the node, let it continue backing up to the old server. b) Do your export in chunks. Exports that run a gazillion hours seems to always cause problems and end up failing. I cut down the size of each export by using fromdate/todate on the export, like fromdate = 01/01/2010 todate=12/31/2010. When that's finished, do it again, pick up another later date range, then another and another until you get current. c) Then every morning do: export node filedata=all fromtime=now-24 totime=now merge=yes (always use merge=yes). You can even put this in as an admin schedule that keeps your V6 server up to date and in sync, until you can coordinate with the client owner to switch it over to point to the V6 server for backup. This way you don't have to fight scheduling issues, or worry about it for a day when you get distracted by that pesky pager. You just get the 2 servers in sync for that client a bit at a time, then cut it over when convenient. Wanda -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Vandeventer, Harold [BS] Sent: Monday, August 27, 2012 5:13 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Export node to new server Thanks Wanda,... I owe you sumthin! I'll confirm the domains/mgmt classes/retention rules first. Thanks again. Harold Vandeventer Systems Programmer State of Kansas - Office of Information Technology Services harold.vandeven...@ks.gov (785) 296-0631 -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Prather, Wanda Sent: Monday, August 27, 2012 3:58 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Export node to new server Do I follow the virtual volumes setup process? No, use the enterprise configuration form. You won't be creating any virtual volumes. When you export client data, it will land in the appropriate domain/mgmt. class, and get put into the storage hierarchy of the target server. Woe be unto you if you have domains/mgmt. classes with the same names, but different retention rules, when you start the export/import. Then, define the node manually on the target; Not necessary, it will get created with the import. Then: 1: Lock the node. Not really necessary. 2: EXPORT NODE nodename TOSERVER=target FILEDATA=BACKUP EXPORTIDENTIFIER=a value Suggest adding MERGE =YES as standard practice. Wanda [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. ***
Re: Export node to new server
Do I follow the virtual volumes setup process? No, use the enterprise configuration form. You won't be creating any virtual volumes. When you export client data, it will land in the appropriate domain/mgmt. class, and get put into the storage hierarchy of the target server. Woe be unto you if you have domains/mgmt. classes with the same names, but different retention rules, when you start the export/import. Then, define the node manually on the target; Not necessary, it will get created with the import. Then: 1: Lock the node. Not really necessary. 2: EXPORT NODE nodename TOSERVER=target FILEDATA=BACKUP EXPORTIDENTIFIER=a value Suggest adding MERGE =YES as standard practice. Wanda
Re: Export node to new server
Thanks Wanda,... I owe you sumthin! I'll confirm the domains/mgmt classes/retention rules first. Thanks again. Harold Vandeventer Systems Programmer State of Kansas - Office of Information Technology Services harold.vandeven...@ks.gov (785) 296-0631 -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Prather, Wanda Sent: Monday, August 27, 2012 3:58 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Export node to new server Do I follow the virtual volumes setup process? No, use the enterprise configuration form. You won't be creating any virtual volumes. When you export client data, it will land in the appropriate domain/mgmt. class, and get put into the storage hierarchy of the target server. Woe be unto you if you have domains/mgmt. classes with the same names, but different retention rules, when you start the export/import. Then, define the node manually on the target; Not necessary, it will get created with the import. Then: 1: Lock the node. Not really necessary. 2: EXPORT NODE nodename TOSERVER=target FILEDATA=BACKUP EXPORTIDENTIFIER=a value Suggest adding MERGE =YES as standard practice. Wanda [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. ***
Re: Export node to new server
Thanks Wanda... the nodes are not trivial, unfortunately. We've never had a need for server-server comms; a lot can be done there it appears. I see a description in the Admin Guide for Preparing to export to another server for immediate import. That includes a DEFINE SERVER to establish the name of the target server or the originating server. I'm confused by the two syntax's of DEFINE SERVER. Do I follow the virtual volumes setup process? Then, define the node manually on the target; some changes in contact, Policy Domain names and other items easy to define manually, but don't need to be exported/imported. Then: 1: Lock the node. 2: EXPORT NODE nodename TOSERVER=target FILEDATA=BACKUP EXPORTIDENTIFIER=a value. 3: monitor that, but have the node manager edit the DSM.OPT. 4: unlock node when done. 5: delete filespaces/node on source after everyone is comfortable it all worked. Again, thanks for helping out, I'm jumping into server-server for the first time. Harold Vandeventer Systems Programmer State of Kansas - Office of Information Technology Services harold.vandeven...@ks.gov (785) 296-0631 -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Prather, Wanda Sent: Thursday, August 23, 2012 6:32 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Export node to new server Better if you do that in reverse order, unless the clients are trivial in size. If you let the client scheduled backup run, it will do a full, which for many clients can be painful. If you get the export done first, all the existing data will be represented in the new server DB, and the client's scheduled backup to the new server will be incremental. If there is a time lag between the time you do the first export and the time you get the clients dsm.opt file pointing to the new server, you can do an incremental export to catch up - add the FROMDATE=today-blah fromtime=xx:yy:zz to the EXPORT command. Also IMHO it's easier to do what you suggest using server-to-server export than using media. Then it's just one step. Wanda -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Vandeventer, Harold [BS] Sent: Thursday, August 23, 2012 4:19 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Export node to new server My goal is to relocate all backup data for a node currently on a TSM 5.5.2 server to a TSM 6.2.4 server. There are no archive or space managed data in the system. First time I've had to try this, so looking to the experts for comment. Looks like a fairly simple process: Define the node on the target server with appropriate schedules, policy, etc. Have the node manager modify the DSM.OPT file to specify the new server. Let scheduled backups run. On source TSM: EXPORT NODE nodename FILEDATA=BACKUP DEVCLASS=classname On target TSM: IMPORT NODE nodename FILEDATA=BACKUP DEVCLASS=classname DATES=ABSOLUTE MERGEFILESPACES=YES VOL=volnames An important parameter MERGEFILESPACES=YES to bring in the old data into the identical filespaces. Harold Vandeventer Systems Programmer State of Kansas - Office of Information Technology Services harold.vandeven...@ks.gov (785) 296-0631 [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. ***
Re: Export node to new server
Hi Harold, I would recommend you check of server-to-server communication between server is supported configuration in terms of TSM version. because if you have an issue during the migration and it is not supported config, IBM will refuse support ... Regards Chavdar On Fri, Aug 24, 2012 at 7:03 PM, Vandeventer, Harold [BS] harold.vandeven...@ks.gov wrote: Thanks Wanda... the nodes are not trivial, unfortunately. We've never had a need for server-server comms; a lot can be done there it appears. I see a description in the Admin Guide for Preparing to export to another server for immediate import. That includes a DEFINE SERVER to establish the name of the target server or the originating server. I'm confused by the two syntax's of DEFINE SERVER. Do I follow the virtual volumes setup process? Then, define the node manually on the target; some changes in contact, Policy Domain names and other items easy to define manually, but don't need to be exported/imported. Then: 1: Lock the node. 2: EXPORT NODE nodename TOSERVER=target FILEDATA=BACKUP EXPORTIDENTIFIER=a value. 3: monitor that, but have the node manager edit the DSM.OPT. 4: unlock node when done. 5: delete filespaces/node on source after everyone is comfortable it all worked. Again, thanks for helping out, I'm jumping into server-server for the first time. Harold Vandeventer Systems Programmer State of Kansas - Office of Information Technology Services harold.vandeven...@ks.gov (785) 296-0631 -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Prather, Wanda Sent: Thursday, August 23, 2012 6:32 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Export node to new server Better if you do that in reverse order, unless the clients are trivial in size. If you let the client scheduled backup run, it will do a full, which for many clients can be painful. If you get the export done first, all the existing data will be represented in the new server DB, and the client's scheduled backup to the new server will be incremental. If there is a time lag between the time you do the first export and the time you get the clients dsm.opt file pointing to the new server, you can do an incremental export to catch up - add the FROMDATE=today-blah fromtime=xx:yy:zz to the EXPORT command. Also IMHO it's easier to do what you suggest using server-to-server export than using media. Then it's just one step. Wanda -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Vandeventer, Harold [BS] Sent: Thursday, August 23, 2012 4:19 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Export node to new server My goal is to relocate all backup data for a node currently on a TSM 5.5.2 server to a TSM 6.2.4 server. There are no archive or space managed data in the system. First time I've had to try this, so looking to the experts for comment. Looks like a fairly simple process: Define the node on the target server with appropriate schedules, policy, etc. Have the node manager modify the DSM.OPT file to specify the new server. Let scheduled backups run. On source TSM: EXPORT NODE nodename FILEDATA=BACKUP DEVCLASS=classname On target TSM: IMPORT NODE nodename FILEDATA=BACKUP DEVCLASS=classname DATES=ABSOLUTE MERGEFILESPACES=YES VOL=volnames An important parameter MERGEFILESPACES=YES to bring in the old data into the identical filespaces. Harold Vandeventer Systems Programmer State of Kansas - Office of Information Technology Services harold.vandeven...@ks.gov (785) 296-0631 [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. ***
Re: Export node to new server
Better if you do that in reverse order, unless the clients are trivial in size. If you let the client scheduled backup run, it will do a full, which for many clients can be painful. If you get the export done first, all the existing data will be represented in the new server DB, and the client's scheduled backup to the new server will be incremental. If there is a time lag between the time you do the first export and the time you get the clients dsm.opt file pointing to the new server, you can do an incremental export to catch up - add the FROMDATE=today-blah fromtime=xx:yy:zz to the EXPORT command. Also IMHO it's easier to do what you suggest using server-to-server export than using media. Then it's just one step. Wanda -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Vandeventer, Harold [BS] Sent: Thursday, August 23, 2012 4:19 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Export node to new server My goal is to relocate all backup data for a node currently on a TSM 5.5.2 server to a TSM 6.2.4 server. There are no archive or space managed data in the system. First time I've had to try this, so looking to the experts for comment. Looks like a fairly simple process: Define the node on the target server with appropriate schedules, policy, etc. Have the node manager modify the DSM.OPT file to specify the new server. Let scheduled backups run. On source TSM: EXPORT NODE nodename FILEDATA=BACKUP DEVCLASS=classname On target TSM: IMPORT NODE nodename FILEDATA=BACKUP DEVCLASS=classname DATES=ABSOLUTE MERGEFILESPACES=YES VOL=volnames An important parameter MERGEFILESPACES=YES to bring in the old data into the identical filespaces. Harold Vandeventer Systems Programmer State of Kansas - Office of Information Technology Services harold.vandeven...@ks.gov (785) 296-0631 [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. ***
Re: Export node to new server
Do you have any information on doing server-to-server export? Is there a TSM name for it? Thanks Grant On 24/08/12 09:31, Prather, Wanda wrote: Better if you do that in reverse order, unless the clients are trivial in size. If you let the client scheduled backup run, it will do a full, which for many clients can be painful. If you get the export done first, all the existing data will be represented in the new server DB, and the client's scheduled backup to the new server will be incremental. If there is a time lag between the time you do the first export and the time you get the clients dsm.opt file pointing to the new server, you can do an incremental export to catch up - add the FROMDATE=today-blah fromtime=xx:yy:zz to the EXPORT command. Also IMHO it's easier to do what you suggest using server-to-server export than using media. Then it's just one step. Wanda -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Vandeventer, Harold [BS] Sent: Thursday, August 23, 2012 4:19 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Export node to new server My goal is to relocate all backup data for a node currently on a TSM 5.5.2 server to a TSM 6.2.4 server. There are no archive or space managed data in the system. First time I've had to try this, so looking to the experts for comment. Looks like a fairly simple process: Define the node on the target server with appropriate schedules, policy, etc. Have the node manager modify the DSM.OPT file to specify the new server. Let scheduled backups run. On source TSM: EXPORT NODEnodename FILEDATA=BACKUP DEVCLASS=classname On target TSM: IMPORT NODEnodename FILEDATA=BACKUP DEVCLASS=classname DATES=ABSOLUTE MERGEFILESPACES=YES VOL=volnames An important parameter MERGEFILESPACES=YES to bring in the old data into the identical filespaces. Harold Vandeventer Systems Programmer State of Kansas - Office of Information Technology Services harold.vandeven...@ks.gov (785) 296-0631 [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. ***
