Re: Move NodeData
The stgpool parameter on Move Data is only valid for primary storage pool volumes. You cannot use the Move Data command to move copypool data from one storagepool to a different one. -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of George Huebschman Sent: Friday, March 30, 2012 2:30 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Move NodeData I think I have misunderstood how the command move nodedata works in regard to offsite media. I had believed that it functioned in the same way that reclamation and move data operations worked, utilizing onsite media to write new offsite media. This quote relates to the move data command: You can use this command to move files from an offsite volume in a copy storage pool or active-data pool. Because the offsite volume cannot be mounted, the server obtains the files that are on the offsite volume from either a primary storage pool, another copy storage pool, or another active-data pool. These files are then written to the destination volumes in the original copy storage pool or active-data pool. I see nothing like that in the description of the move nodedata command. It looks like I made a false assumption. Is that so? -- George Huebschman Cell 301 875-1227 When you have a choice, spend money where you would prefer to work if you had NO choice.
Re: Move NodeData
Hi George; I use the 'move data' command to have TSM clear off an Offsite tape volume by, as you mentioned, finding the files that TSM knows to be on that tape, and either using an existing Offsite tape (that has yet to be moved Offsite) or opening a new volume. It finds the files on the Onsite tapes and moves them to an Offsite volume, so that the Offsite volume you did the 'move data' on is now devoid of real data and can be trashed if necessary. I run monthly backupsets on some nodes and, over time, the data for a specific client node gets spread across perhaps 30 Onsite volumes. For these, I do a 'move nodedata' and it goes out there and finds these files spread over all there tapes and consolidates it onto just a few volumes. The short story - 'move data' to get files off a specific tape volume 'move nodedata' to consolidate files for a node to fewer volumes -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of George Huebschman Sent: Friday, March 30, 2012 1:30 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Move NodeData I think I have misunderstood how the command move nodedata works in regard to offsite media. I had believed that it functioned in the same way that reclamation and move data operations worked, utilizing onsite media to write new offsite media. This quote relates to the move data command: You can use this command to move files from an offsite volume in a copy storage pool or active-data pool. Because the offsite volume cannot be mounted, the server obtains the files that are on the offsite volume from either a primary storage pool, another copy storage pool, or another active-data pool. These files are then written to the destination volumes in the original copy storage pool or active-data pool. I see nothing like that in the description of the move nodedata command. It looks like I made a false assumption. Is that so? -- George Huebschman Cell 301 875-1227 When you have a choice, spend money where you would prefer to work if you had NO choice.
Re: Move NodeData
David, TSM says you can use it for copy pool data: 3.35.5 MOVE NODEDATA (Move data by node in a sequential access storage pool) Use this command to move data located in a sequential-access storage pool. You can move data for one or more nodes or for a group of collocated nodes. You can also move selected file spaces for a single node. The data can be located in a primary storage pool, a copy storage pool, or an active-data pool. On Mon, Apr 2, 2012 at 9:12 AM, Ehresman,David E. deehr...@louisville.eduwrote: The stgpool parameter on Move Data is only valid for primary storage pool volumes. You cannot use the Move Data command to move copypool data from one storagepool to a different one. -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of George Huebschman Sent: Friday, March 30, 2012 2:30 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Move NodeData I think I have misunderstood how the command move nodedata works in regard to offsite media. I had believed that it functioned in the same way that reclamation and move data operations worked, utilizing onsite media to write new offsite media. This quote relates to the move data command: You can use this command to move files from an offsite volume in a copy storage pool or active-data pool. Because the offsite volume cannot be mounted, the server obtains the files that are on the offsite volume from either a primary storage pool, another copy storage pool, or another active-data pool. These files are then written to the destination volumes in the original copy storage pool or active-data pool. I see nothing like that in the description of the move nodedata command. It looks like I made a false assumption. Is that so? -- George Huebschman Cell 301 875-1227 When you have a choice, spend money where you would prefer to work if you had NO choice. -- George Huebschman Cell 410 522-8581 When you have a choice, spend money where you would prefer to work if you had NO choice.
Re: Move NodeData
Gene, I know what they do, how they are similar and different. Move Data moves data from a tape. Move Node Data moves the data for a node on whatever tape it resides on to another tape in another (or the same) storage pool. (Achieving something similar to a node collocation.) - My question is, does the mechanism of moving the objects work the same as reclamation and move data (or not, as the documentation hints at). - Do the source volumes have to be onsite? - Does it work more like Restore Volume run for a primary pool volume, where TSM generates a listing of CopyPool media that is required to perform the restore? On Mon, Apr 2, 2012 at 10:03 AM, Shaffer, Gene gene.shaf...@aurora.orgwrote: Hi George; The short story - 'move data' to get files off a specific tape volume 'move nodedata' to consolidate files for a node to fewer volumes -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of George Huebschman Sent: Friday, March 30, 2012 1:30 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Move NodeData I think I have misunderstood how the command move nodedata works in regard to offsite media. I had believed that it functioned in the same way that reclamation and move data operations worked, utilizing onsite media to write new offsite media.
Re: Move NodeData
George, I'm still at 5.5, but I don't believe the requirement that the copypool volumes needed for a move nodedata job be mountable has changed in newer releases. If you run it without the volumes onsite, you will get a message for each needed volume: MOVE NODEDATA nodename FROMSTGPOOL=offsitepoolname 04/02/2012 09:44:06 ANR1258W Files on volume xx needed for move data cannot be accessed - access mode is unavailable, offsite, or destroyed. (SESSION: 17678) Bob. -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of George Huebschman Sent: Monday, April 02, 2012 9:33 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Move NodeData Gene, I know what they do, how they are similar and different. Move Data moves data from a tape. Move Node Data moves the data for a node on whatever tape it resides on to another tape in another (or the same) storage pool. (Achieving something similar to a node collocation.) - My question is, does the mechanism of moving the objects work the same as reclamation and move data (or not, as the documentation hints at). - Do the source volumes have to be onsite? - Does it work more like Restore Volume run for a primary pool volume, where TSM generates a listing of CopyPool media that is required to perform the restore? On Mon, Apr 2, 2012 at 10:03 AM, Shaffer, Gene gene.shaf...@aurora.orgwrote: Hi George; The short story - 'move data' to get files off a specific tape volume 'move nodedata' to consolidate files for a node to fewer volumes -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of George Huebschman Sent: Friday, March 30, 2012 1:30 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Move NodeData I think I have misunderstood how the command move nodedata works in regard to offsite media. I had believed that it functioned in the same way that reclamation and move data operations worked, utilizing onsite media to write new offsite media. This electronic transmission and any documents accompanying this electronic transmission contain confidential information belonging to the sender. This information may be legally privileged. The information is intended only for the use of the individual or entity named above. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or the taking of any action in reliance on or regarding the contents of this electronically transmitted information is strictly prohibited.
Re: Move NodeData
You CAN use Move Data on copy storagepools but only to move to other volumes in the SAME storagepool. You cannot Move Data copy storagepool data to a different storagepool. -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of George Huebschman Sent: Monday, April 02, 2012 10:20 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Move NodeData David, TSM says you can use it for copy pool data: 3.35.5 MOVE NODEDATA (Move data by node in a sequential access storage pool) Use this command to move data located in a sequential-access storage pool. You can move data for one or more nodes or for a group of collocated nodes. You can also move selected file spaces for a single node. The data can be located in a primary storage pool, a copy storage pool, or an active-data pool. On Mon, Apr 2, 2012 at 9:12 AM, Ehresman,David E. deehr...@louisville.eduwrote: The stgpool parameter on Move Data is only valid for primary storage pool volumes. You cannot use the Move Data command to move copypool data from one storagepool to a different one. -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of George Huebschman Sent: Friday, March 30, 2012 2:30 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Move NodeData I think I have misunderstood how the command move nodedata works in regard to offsite media. I had believed that it functioned in the same way that reclamation and move data operations worked, utilizing onsite media to write new offsite media. This quote relates to the move data command: You can use this command to move files from an offsite volume in a copy storage pool or active-data pool. Because the offsite volume cannot be mounted, the server obtains the files that are on the offsite volume from either a primary storage pool, another copy storage pool, or another active-data pool. These files are then written to the destination volumes in the original copy storage pool or active-data pool. I see nothing like that in the description of the move nodedata command. It looks like I made a false assumption. Is that so? -- George Huebschman Cell 301 875-1227 When you have a choice, spend money where you would prefer to work if you had NO choice. -- George Huebschman Cell 410 522-8581 When you have a choice, spend money where you would prefer to work if you had NO choice.
Re: Move NodeData
I see that you are correct. I also see the answer to my question...a few lines from where I quoted. I should have read more attentively: This operation will not move data on volumes with access modes of offsite, unavailable, or destroyed. On Mon, Apr 2, 2012 at 10:49 AM, Ehresman,David E. deehr...@louisville.eduwrote: You CAN use Move Data on copy storagepools but only to move to other volumes in the SAME storagepool. You cannot Move Data copy storagepool data to a different storagepool. -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of George Huebschman Sent: Monday, April 02, 2012 10:20 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Move NodeData David, TSM says you can use it for copy pool data: 3.35.5 MOVE NODEDATA (Move data by node in a sequential access storage pool) Use this command to move data located in a sequential-access storage pool. You can move data for one or more nodes or for a group of collocated nodes. You can also move selected file spaces for a single node. The data can be located in a primary storage pool, a copy storage pool, or an active-data pool. On Mon, Apr 2, 2012 at 9:12 AM, Ehresman,David E. deehr...@louisville.eduwrote: The stgpool parameter on Move Data is only valid for primary storage pool volumes. You cannot use the Move Data command to move copypool data from one storagepool to a different one. -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of George Huebschman Sent: Friday, March 30, 2012 2:30 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Move NodeData I think I have misunderstood how the command move nodedata works in regard to offsite media. I had believed that it functioned in the same way that reclamation and move data operations worked, utilizing onsite media to write new offsite media. This quote relates to the move data command: You can use this command to move files from an offsite volume in a copy storage pool or active-data pool. Because the offsite volume cannot be mounted, the server obtains the files that are on the offsite volume from either a primary storage pool, another copy storage pool, or another active-data pool. These files are then written to the destination volumes in the original copy storage pool or active-data pool. I see nothing like that in the description of the move nodedata command. It looks like I made a false assumption. Is that so? -- George Huebschman Cell 301 875-1227 When you have a choice, spend money where you would prefer to work if you had NO choice. -- George Huebschman Cell 410 522-8581 When you have a choice, spend money where you would prefer to work if you had NO choice. -- George Huebschman Cell (301) 875-1227 When you have a choice, spend money where you would prefer to work if you had NO choice.
Move NodeData
I think I have misunderstood how the command move nodedata works in regard to offsite media. I had believed that it functioned in the same way that reclamation and move data operations worked, utilizing onsite media to write new offsite media. This quote relates to the move data command: You can use this command to move files from an offsite volume in a copy storage pool or active-data pool. Because the offsite volume cannot be mounted, the server obtains the files that are on the offsite volume from either a primary storage pool, another copy storage pool, or another active-data pool. These files are then written to the destination volumes in the original copy storage pool or active-data pool. I see nothing like that in the description of the move nodedata command. It looks like I made a false assumption. Is that so? -- George Huebschman Cell 301 875-1227 When you have a choice, spend money where you would prefer to work if you had NO choice.
Weird move nodedata with maxproc?
Hi everybody, after a long absence from this mailing list, I'm back (of course) because I have a question about some TSM behavior. We're currently running a TSM 6.2.1.0 on RedHat with (currently) 4 LTO drives, of which DRIVE1 and 2 are LTO3, DRIVE3 and 4 are LTO4. I have a BIGNODE for which I'd like to move the data from an LTO3 pool to a LTO4 pool. So I'll do a move nodedata BIGNODE FROMSTG=TP.POOLA tostg=TP.POOLB maxproc=2 I would now expect that TSM now mounts 2 LTO3 cartridges R/O in the first 2 drives and 2 LTO4 cartrigdes in the LTO4 drives and moves the data for this node with 2 processes. But that does not happen. TSM mounts one LTO3 and one LTO4 cartridge, starts moving the data and waits for Mountpoints although there are two drives doing nothing. Why that? Thanks in advance, Sascha
Re: Weird move nodedata with maxproc?
The TSM documentation fails to say just how Maxprocess is honored in the Move Nodedata context. In other commands, such as Backup Stgpool, it is known that operation is by clusters - a non-grouped node or a collocation group of nodes. Whereas your task involves a single node, it looks like you are getting a single thread. Richard Sims, at Boston University
Re: Weird move nodedata with maxproc?
Am 11.10.2011 13:31, schrieb Richard Sims: The TSM documentation fails to say just how Maxprocess is honored in the Move Nodedata context. In other commands, such as Backup Stgpool, it is known that operation is by clusters - a non-grouped node or a collocation group of nodes. Whereas your task involves a single node, it looks like you are getting a single thread. Richard Sims, at Boston University Richard, thanks for your reply. I also got a mail from a fellow listmember suggesting that the problem could also arise from the node only having one (1) filespace. Best, Sascha
Re: Weird move nodedata with maxproc?
That would've been me ;) Since this: Specifies the maximum number of parallel processes to use for moving data. This parameter is optional. You can specify a value from 1–999, inclusive. The default value is 1. Increasing the number of parallel processes should improve throughput is mentioned under Move Node Data - Moving selected filespaces for one node I would assume that the process handles 1 filespace per process, not like migration backup storagepool, 1 node per process. Regards Daniel Daniel Sparrman Exist i Stockholm AB Växel: 08-754 98 00 Fax: 08-754 97 30 daniel.sparr...@exist.se http://www.existgruppen.se Posthusgatan 1 761 30 NORRTÄLJE -ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU skrev: - Till: ADSM-L@VM.MARIST.EDU Från: Sascha Askani Sänt av: ADSM: Dist Stor Manager Datum: 10/11/2011 13:39 Ärende: Re: [ADSM-L] Weird move nodedata with maxproc? Am 11.10.2011 13:31, schrieb Richard Sims: The TSM documentation fails to say just how Maxprocess is honored in the Move Nodedata context. In other commands, such as Backup Stgpool, it is known that operation is by clusters - a non-grouped node or a collocation group of nodes. Whereas your task involves a single node, it looks like you are getting a single thread. Richard Sims, at Boston University Richard, thanks for your reply. I also got a mail from a fellow listmember suggesting that the problem could also arise from the node only having one (1) filespace. Best, Sascha
move nodedata functionality
Thanks for your help!! I am preparing for a DR test and I am trying to do some move nodedata commands on a couple of nodes. When I try to do a move nodedata from a secondary storage pool (copypool) it complains that the volumes are offsite. Well of course! I guess I though that TSM would pull the data from a it original primary storage pool to create the data set. Wrong! My question is: If I do the move nodedata from a primary storage pool to a secondary storage pool(copypool), will TSM expire the nodes data on the 85 secondary storage pool volumes as it aggregates the data onto new secondary storage pool volumes? If it doesn't it will not be of much help since the secondary storage pool volumes will go offsite for the DR exercise. This seems like the logical path to me but the doc is not clear on this point and I don't want to assume here. -MOVe NODEdata--+---node_name-+--+ '-COLLOCGroup--=--group_name-' --FROMstgpool--=--source_pool_name- --+-+-- '-TOstgpool--=--destination_pool_name-' .-Type--=--ANY--. --+---+ '-Type--=--+-ANY--+-' +-Backup---+ +-ARchive--+ '-SPacemanaged-' .-MAXPRocess--=--1-. .-Wait--=--No--. --+--+--+--+--- '-MAXPRocess--=--num_processes-' '-Wait--=--+-No--+-' '-Yes-' --++-- '-RECONStruct--=--+-No--+' '-Yes-' IMPORTANT NOTICE: This message and any included attachments are from East Jefferson General Hospital, and is intended only for the addressee(s), and may include Protected Health (PHI) or other confidential information. If you are the intended recipient, you are obligated to maintain it in a secure and confidential manner and re-disclosure without additional consent or as permitted by law is prohibited. If you are not the intended recipient, use of this information is strictly prohibited and may be unlawful. Please promptly reply to the sender by email and delete this message from your computer. East Jefferson General Hospital greatly appreciates your cooperation.
Re: move nodedata functionality
You cannot move nodedata from a primary stgpool to a copy stgpool; you use backup stgpool for that. You can only specify a tostgpool on move nodedata if from is a primary stgpool. You can not use move nodedata to move from one copy stgpool to another copy stgpool. And the tapes in question have to be either READO or READW; OFFSITE will not work. That said, what are you really trying to test in your DR test? If you want to know anything about how you might recover in a DISASTER RECOVERY situation, you need to take your copy stgpool the way it is. We don't get forewarning of disaster that allow us to make our copy pools better! If your copy stgpools are not in sufficient condition to do a DR, prove it to your management so that you can make the argument that they need to allocate enough resource to copy stgpool to make it a viable DR restore pool. David Ehresman Nicholas Rodolfich [EMAIL PROTECTED] 4/30/2008 11:21 AM Thanks for your help!! I am preparing for a DR test and I am trying to do some move nodedata commands on a couple of nodes. When I try to do a move nodedata from a secondary storage pool (copypool) it complains that the volumes are offsite. Well of course! I guess I though that TSM would pull the data from a it original primary storage pool to create the data set. Wrong! My question is: If I do the move nodedata from a primary storage pool to a secondary storage pool(copypool), will TSM expire the nodes data on the 85 secondary storage pool volumes as it aggregates the data onto new secondary storage pool volumes? If it doesn't it will not be of much help since the secondary storage pool volumes will go offsite for the DR exercise. This seems like the logical path to me but the doc is not clear on this point and I don't want to assume here. -MOVe NODEdata--+---node_name-+--+ '-COLLOCGroup--=--group_name-' --FROMstgpool--=--source_pool_name- --+-+-- '-TOstgpool--=--destination_pool_name-' .-Type--=--ANY--. --+---+ '-Type--=--+-ANY--+-' +-Backup---+ +-ARchive--+ '-SPacemanaged-' .-MAXPRocess--=--1-. .-Wait--=--No--. --+--+--+--+--- '-MAXPRocess--=--num_processes-' '-Wait--=--+-No--+-' '-Yes-' --++-- '-RECONStruct--=--+-No--+' '-Yes-' IMPORTANT NOTICE: This message and any included attachments are from East Jefferson General Hospital, and is intended only for the addressee(s), and may include Protected Health (PHI) or other confidential information. If you are the intended recipient, you are obligated to maintain it in a secure and confidential manner and re-disclosure without additional consent or as permitted by law is prohibited. If you are not the intended recipient, use of this information is strictly prohibited and may be unlawful. Please promptly reply to the sender by email and delete this message from your computer. East Jefferson General Hospital greatly appreciates your cooperation.
Re: move nodedata functionality
Well it seems that you cannot do a 'move nodedata' from a copypool to the same copypool either no matter what state the volumes are in unless you bring the volumes back onsite and check them into the library. I can only get it to work on a primary pool which seems sorta useless to me. Well maybe not useless! I thought the purpose was to enhance DR abilities but it only seems useful for increasuing the eficiency of restores from onsite volumes. [EMAIL PROTECTED] 4/30/2008 1:55 PM You cannot move nodedata from a primary stgpool to a copy stgpool; you use backup stgpool for that. You can only specify a tostgpool on move nodedata if from is a primary stgpool. You can not use move nodedata to move from one copy stgpool to another copy stgpool. And the tapes in question have to be either READO or READW; OFFSITE will not work. That said, what are you really trying to test in your DR test? If you want to know anything about how you might recover in a DISASTER RECOVERY situation, you need to take your copy stgpool the way it is. We don't get forewarning of disaster that allow us to make our copy pools better! If your copy stgpools are not in sufficient condition to do a DR, prove it to your management so that you can make the argument that they need to allocate enough resource to copy stgpool to make it a viable DR restore pool. David Ehresman Nicholas Rodolfich [EMAIL PROTECTED] 4/30/2008 11:21 AM Thanks for your help!! I am preparing for a DR test and I am trying to do some move nodedata commands on a couple of nodes. When I try to do a move nodedata from a secondary storage pool (copypool) it complains that the volumes are offsite. Well of course! I guess I though that TSM would pull the data from a it original primary storage pool to create the data set. Wrong! My question is: If I do the move nodedata from a primary storage pool to a secondary storage pool(copypool), will TSM expire the nodes data on the 85 secondary storage pool volumes as it aggregates the data onto new secondary storage pool volumes? If it doesn't it will not be of much help since the secondary storage pool volumes will go offsite for the DR exercise. This seems like the logical path to me but the doc is not clear on this point and I don't want to assume here. -MOVe NODEdata--+---node_name-+--+ '-COLLOCGroup--=--group_name-' --FROMstgpool--=--source_pool_name- --+-+-- '-TOstgpool--=--destination_pool_name-' .-Type--=--ANY--. --+---+ '-Type--=--+-ANY--+-' +-Backup---+ +-ARchive--+ '-SPacemanaged-' .-MAXPRocess--=--1-. .-Wait--=--No--. --+--+--+--+--- '-MAXPRocess--=--num_processes-' '-Wait--=--+-No--+-' '-Yes-' --++-- '-RECONStruct--=--+-No--+' '-Yes-' IMPORTANT NOTICE: This message and any included attachments are from East Jefferson General Hospital, and is intended only for the addressee(s), and may include Protected Health (PHI) or other confidential information. If you are the intended recipient, you are obligated to maintain it in a secure and confidential manner and re-disclosure without additional consent or as permitted by law is prohibited. If you are not the intended recipient, use of this information is strictly prohibited and may be unlawful. Please promptly reply to the sender by email and delete this message from your computer. East Jefferson General Hospital greatly appreciates your cooperation. IMPORTANT NOTICE: This message and any included attachments are from East Jefferson General Hospital, and is intended only for the addressee(s), and may include Protected Health (PHI) or other confidential information. If you are the intended recipient, you are obligated to maintain it in a secure and confidential manner and re-disclosure without additional consent or as permitted by law is prohibited. If you are not the intended recipient, use of this information is strictly prohibited and may be unlawful. Please promptly reply to the sender by email and delete this message from your computer. East Jefferson General Hospital greatly appreciates your cooperation.
Re: move nodedata functionality
Well, you have to stop and consider the logic. You don't want to be doing any more with the tapes that are offsite than is necessary, as you want them as they were as of the last DB backup you also sent offsite, right? I mean if you don't have the same tapes offsite that go with the db backup you will not be able to recover. The whole layout improves recoverability, in a DR situation, by not allowing anyone to do much monkeying with the volumes. From what I know here are your options: If you have a bad copypool volume, just delete it and re-run the backup stg command. This will re-copy the data to a new volume to send off site. Or, if you have a volume that is more than your desired level of reclamation, run the reclaim stg command (or change the reclamation level on the stg. Pool if in 5.2 or older). If you need the tapes from offsite for a planned DR test, just tell your Vaulting vendor to bring them home in plenty of time to not incur additional charges. Normally a DR test would include how long does it take for me to get my tapes to the DR location, and get up and running anyway. Our local vendor allows for 2 of these wholesale tests a year, if I'm not mistaken). If you want the data for a particular node in another offsite pool, that's a different animal that I have never worked over. I have always moved entire pools to new tape formats, or just allowed retention and attrition to take over after starting their backups to a new copypool. See Ya' Howard -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Nicholas Rodolfich Sent: Wednesday, April 30, 2008 2:43 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] move nodedata functionality Well it seems that you cannot do a 'move nodedata' from a copypool to the same copypool either no matter what state the volumes are in unless you bring the volumes back onsite and check them into the library. I can only get it to work on a primary pool which seems sorta useless to me. Well maybe not useless! I thought the purpose was to enhance DR abilities but it only seems useful for increasuing the eficiency of restores from onsite volumes. [EMAIL PROTECTED] 4/30/2008 1:55 PM You cannot move nodedata from a primary stgpool to a copy stgpool; you use backup stgpool for that. You can only specify a tostgpool on move nodedata if from is a primary stgpool. You can not use move nodedata to move from one copy stgpool to another copy stgpool. And the tapes in question have to be either READO or READW; OFFSITE will not work. That said, what are you really trying to test in your DR test? If you want to know anything about how you might recover in a DISASTER RECOVERY situation, you need to take your copy stgpool the way it is. We don't get forewarning of disaster that allow us to make our copy pools better! If your copy stgpools are not in sufficient condition to do a DR, prove it to your management so that you can make the argument that they need to allocate enough resource to copy stgpool to make it a viable DR restore pool. David Ehresman Nicholas Rodolfich [EMAIL PROTECTED] 4/30/2008 11:21 AM Thanks for your help!! I am preparing for a DR test and I am trying to do some move nodedata commands on a couple of nodes. When I try to do a move nodedata from a secondary storage pool (copypool) it complains that the volumes are offsite. Well of course! I guess I though that TSM would pull the data from a it original primary storage pool to create the data set. Wrong! My question is: If I do the move nodedata from a primary storage pool to a secondary storage pool(copypool), will TSM expire the nodes data on the 85 secondary storage pool volumes as it aggregates the data onto new secondary storage pool volumes? If it doesn't it will not be of much help since the secondary storage pool volumes will go offsite for the DR exercise. This seems like the logical path to me but the doc is not clear on this point and I don't want to assume here. -MOVe NODEdata--+---node_name-+--+ '-COLLOCGroup--=--group_name-' --FROMstgpool--=--source_pool_name- --+-+-- '-TOstgpool--=--destination_pool_name-' .-Type--=--ANY--. --+---+ '-Type--=--+-ANY--+-' +-Backup---+ +-ARchive--+ '-SPacemanaged-' .-MAXPRocess--=--1-. .-Wait--=--No--. --+--+--+--+--- '-MAXPRocess--=--num_processes-' '-Wait--=--+-No--+-' '-Yes-' --++-- '-RECONStruct
Re: Move NodeData CollocGroup=
I wrote: If I use MOVE NODEDATA COLLOCGROUP= how clever is TSM in how it copies data from the current tapes? Will it take all the data from a tape in one pass, or will it make one pass per tape per node? I'm relieved to report that based on a small test involving two nodes with data on some tapes in common, TSM does indeed make just one pass at each tape. Let loose the dogs of large moves Nick
Move NodeData CollocGroup=
We're moving data from un-collocated storage groups to storage groups that will be collocated by group (OK, so we're not quite leading edge!). We had a system before of small storage pools that mimicked collocation by groups, so any particular group's data is grouped tightly. If I use MOVE NODEDATA COLLOCGROUP= how clever is TSM in how it copies data from the current tapes? Will it take all the data from a tape in one pass, or will it make one pass per tape per node? Thanks, Nick
Re: move nodedata
I apologize.
You'd think I'd read the whole thread before replying.
One option would be:
Create a file class (for speed. Tape would work)
GENERATE BACKUPSET to this fileclass
This would pull only the active files for that node,
and you could specify to restore from that backupset.
Another would be to find the specific tapes used by this node, then find
the last access times of those volumes, and move those specific volumes.
Script found online to show volumes used for a node:
/* ---*/
/* Example: run vols-node myUnixBox */
/* !!! WARNING !!! RESOURCE INTENSIVE !!! */
/* ---*/
select volumes.volume_name as Volume,-
volumes.stgpool_name as StgPool,-
volumes.est_capacity_mb as Cap.(MB),-
volumes.pct_utilized as Utlzd(%),-
volumes.status as Status,-
volumeusage.filespace_name as Filespace -
from volumes,volumeusage -
where volumes.volume_name=volumeusage.volume_name and -
volumeusage.node_name=upper('$1')
From there, you could Q VOL for last access time to narrow things down.
Another, option would be to use EXPORT NODE to get just active
versions of only certain filespaces, then import it again, making sure
that the copygroup destinations pointed to a disk pool.
-Josh
On 06.03.03 at 23:02 [EMAIL PROTECTED] wrote:
Date: Fri, 3 Mar 2006 23:02:02 -0600 (CST)
From: Josh-Daniel Davis [EMAIL PROTECTED]
To: ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU
Subject: Re: move nodedata
If you don't know the tape the most current data is on,
and don't feel like pulling the list of tapes (or can't per the length of
query)...
You could also use MOVE NODEDATA, but it would be more than just the last
version.
-Josh
On 06.03.03 at 16:53 [EMAIL PROTECTED] wrote:
Date: Fri, 3 Mar 2006 16:53:45 -0600
From: Andy Huebner [EMAIL PROTECTED]
Reply-To: ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU
To: ADSM-L@VM.MARIST.EDU
Subject: Re: move nodedata
If you know what tape it is on you could move that tape back to disk.
This of course has it's own problems.
Andy Huebner
-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
David Tyree
Sent: Friday, March 03, 2006 3:18 PM
To: ADSM-L@VM.MARIST.EDU
Subject: [ADSM-L] move nodedata
Long story but essentally our exchange server just died.
While the hardware guys are putting together a new server I would like
to
prestage the last exchange backup from tape to our diskpool.
Getting the new server up and runnng is going to take awhile so I figure
I
can save some time by having the restore exchange data sitting on
the diskpool waiting on the hardware guys.
It's alot quicker restoring 90+ gig from the diskpool than from tape.
I looked over the 'move nodedata' command but it looks like it will give
me
ALL of my exchange backups. I don't want 14 days worth of exchange
backups,
just the one from last night. I don't see a way to pull just the last
exchange backup.
Any idea on how to go about doing that?
Thanks
This e-mail (including any attachments) is confidential and may be legally
privileged. If you are not an intended recipient or an authorized
representative of an intended recipient, you are prohibited from using,
copying or distributing the information in this e-mail or its attachments.
If you have received this e-mail in error, please notify the sender
immediately by return e-mail and delete all copies of this message and any
attachments.
Thank you.
Re: move nodedata
If you don't know the tape the most current data is on, and don't feel like pulling the list of tapes (or can't per the length of query)... You could also use MOVE NODEDATA, but it would be more than just the last version. -Josh On 06.03.03 at 16:53 [EMAIL PROTECTED] wrote: Date: Fri, 3 Mar 2006 16:53:45 -0600 From: Andy Huebner [EMAIL PROTECTED] Reply-To: ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU To: ADSM-L@VM.MARIST.EDU Subject: Re: move nodedata If you know what tape it is on you could move that tape back to disk. This of course has it's own problems. Andy Huebner -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of David Tyree Sent: Friday, March 03, 2006 3:18 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] move nodedata Long story but essentally our exchange server just died. While the hardware guys are putting together a new server I would like to prestage the last exchange backup from tape to our diskpool. Getting the new server up and runnng is going to take awhile so I figure I can save some time by having the restore exchange data sitting on the diskpool waiting on the hardware guys. It's alot quicker restoring 90+ gig from the diskpool than from tape. I looked over the 'move nodedata' command but it looks like it will give me ALL of my exchange backups. I don't want 14 days worth of exchange backups, just the one from last night. I don't see a way to pull just the last exchange backup. Any idea on how to go about doing that? Thanks This e-mail (including any attachments) is confidential and may be legally privileged. If you are not an intended recipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the information in this e-mail or its attachments. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete all copies of this message and any attachments. Thank you.
move nodedata
Long story but essentally our exchange server just died. While the hardware guys are putting together a new server I would like to prestage the last exchange backup from tape to our diskpool. Getting the new server up and runnng is going to take awhile so I figure I can save some time by having the restore exchange data sitting on the diskpool waiting on the hardware guys. It's alot quicker restoring 90+ gig from the diskpool than from tape. I looked over the 'move nodedata' command but it looks like it will give me ALL of my exchange backups. I don't want 14 days worth of exchange backups, just the one from last night. I don't see a way to pull just the last exchange backup. Any idea on how to go about doing that? Thanks
Re: move nodedata
If you know what tape it is on you could move that tape back to disk. This of course has it's own problems. Andy Huebner -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of David Tyree Sent: Friday, March 03, 2006 3:18 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] move nodedata Long story but essentally our exchange server just died. While the hardware guys are putting together a new server I would like to prestage the last exchange backup from tape to our diskpool. Getting the new server up and runnng is going to take awhile so I figure I can save some time by having the restore exchange data sitting on the diskpool waiting on the hardware guys. It's alot quicker restoring 90+ gig from the diskpool than from tape. I looked over the 'move nodedata' command but it looks like it will give me ALL of my exchange backups. I don't want 14 days worth of exchange backups, just the one from last night. I don't see a way to pull just the last exchange backup. Any idea on how to go about doing that? Thanks This e-mail (including any attachments) is confidential and may be legally privileged. If you are not an intended recipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the information in this e-mail or its attachments. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete all copies of this message and any attachments. Thank you.
move nodedata between pools losing compression
We have set up a new primary storage pool, using lto2 in a 3584 library, with collocation by group. TSM5.3.2.1 on w2k3. We are moving nodedata by collocation group from the original pool to the new one in order to collocate our existing data. In the original pool we see estimated tape capacities of up to 700GB. The tapes being filled in the new pool are 280GB when 100% full. Has anyone else experienced this apparent loss of compression when moving data between pools, and what can we do to address it? Adam Crosskey The information in this e-mail, together with any attachments, is confidential. If you have received this message in error you must not print off, copy, use or disclose the contents. The information may be covered by legal and/or professional privilege. Please delete from your system and inform the sender of the error. As an e-mail can be an informal method of communication, the views expressed may be personal to the sender and should not be taken as necessarily representing the views of the Oxfordshire County Council. As e-mails are transmitted over a public network the Oxfordshire County Council cannot accept any responsibility for the accuracy or completeness of this message. It is your responsibility to carry out all necessary virus checks. www.oxfordshire.gov.uk
Re: move nodedata between pools losing compression
Adam, This is only a guess, but maybe the move nodedata command is transferring compressed data. If the data isn't being decompressed upon read and re-compressed upon write then that would explain what appears to be lower tape utilization. See what the query nodedata command shows before and after the next move. Are you seeing an increase in the number of tapes needed in the new pool compared to the old pool? It seems to me that if you were losing compression then you would see at least a doubling of the number of tapes being used in the new pool. If the number of tapes is about the same then I wouldn't worry about it. If, on the other hand tape usage is higher I'd give TSM support a call. Rick Saylor At 07:53 AM 2/22/2006, you wrote: We have set up a new primary storage pool, using lto2 in a 3584 library, with collocation by group. TSM5.3.2.1 on w2k3. We are moving nodedata by collocation group from the original pool to the new one in order to collocate our existing data. In the original pool we see estimated tape capacities of up to 700GB. The tapes being filled in the new pool are 280GB when 100% full. Has anyone else experienced this apparent loss of compression when moving data between pools, and what can we do to address it? Adam Crosskey The information in this e-mail, together with any attachments, is confidential. If you have received this message in error you must not print off, copy, use or disclose the contents. The information may be covered by legal and/or professional privilege. Please delete from your system and inform the sender of the error. As an e-mail can be an informal method of communication, the views expressed may be personal to the sender and should not be taken as necessarily representing the views of the Oxfordshire County Council. As e-mails are transmitted over a public network the Oxfordshire County Council cannot accept any responsibility for the accuracy or completeness of this message. It is your responsibility to carry out all necessary virus checks. www.oxfordshire.gov.uk
Fw: Odd error using move nodedata
I bet there's a restartable restore hanging out - do a q restore to see if there is one, and cancel it if there is one. Nick Cassimatis - Forwarded by Nicholas Cassimatis/Raleigh/IBM on 12/01/2005 04:13 PM - ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU wrote on 12/01/2005 04:07:38 PM: I'm attempting to run a MOVE NODEDATA to coalesce a node's data onto as few tapes as possible. However, the command fails: 12/01/2005 15:04:49 ANR1171W Unable to move files associated with node WASHINGTON, filespace \\washington\d$ fsId 3 on volume A5L2 due to restore in progress. (SESSION: 1, PROCESS: 12) No restore is in process. TSM 5.3.2 on Windows 2003. Kelly
Re: Odd error using move nodedata
ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU wrote on 12/01/2005 03:07:38 PM: I'm attempting to run a MOVE NODEDATA to coalesce a node's data onto as few tapes as possible. However, the command fails: 12/01/2005 15:04:49 ANR1171W Unable to move files associated with node WASHINGTON, filespace \\washington\d$ fsId 3 on volume A5L2 due to restore in progress. (SESSION: 1, PROCESS: 12) No restore is in process. TSM 5.3.2 on Windows 2003. Run QUERY RESTORE. You'll probably get a list of restartable restores. Run CANCEL RESTORE RESTORE# and then retry your MOVE NODEDATA. -- Mark Stapleton ([EMAIL PROTECTED]) -- Electronic Privacy Notice. This e-mail, and any attachments, contains information that is, or may be, covered by electronic communications privacy laws, and is also confidential and proprietary in nature. If you are not the intended recipient, please be advised that you are legally prohibited from retaining, using, copying, distributing, or otherwise disclosing this information in any manner. Instead, please reply to the sender that you have received this communication in error, and then immediately delete it. Thank you in advance for your cooperation. ==
Re: Odd error using move nodedata
You might have a restartable restore session sitting out there issue q restore and see if there is a restartabel restore sessing (The session number will be negative) -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] Behalf Of Kelly Martin Sent: Thursday, December 01, 2005 1:08 PM To: ADSM-L@VM.MARIST.EDU Subject: Odd error using move nodedata I'm attempting to run a MOVE NODEDATA to coalesce a node's data onto as few tapes as possible. However, the command fails: 12/01/2005 15:04:49 ANR1171W Unable to move files associated with node WASHINGTON, filespace \\washington\d$ fsId 3 on volume A5L2 due to restore in progress. (SESSION: 1, PROCESS: 12) No restore is in process. TSM 5.3.2 on Windows 2003. Kelly
Re: Odd error using move nodedata
Thank you, I didn't think about the possibility of a restartable restore. That fixed it. Kelly On 12/1/05, Thorneycroft, Doug [EMAIL PROTECTED] wrote: You might have a restartable restore session sitting out there issue q restore and see if there is a restartabel restore sessing (The session number will be negative) -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] Behalf Of Kelly Martin Sent: Thursday, December 01, 2005 1:08 PM To: ADSM-L@VM.MARIST.EDU Subject: Odd error using move nodedata I'm attempting to run a MOVE NODEDATA to coalesce a node's data onto as few tapes as possible. However, the command fails: 12/01/2005 15:04:49 ANR1171W Unable to move files associated with node WASHINGTON, filespace \\washington\d$ fsId 3 on volume A5L2 due to restore in progress. (SESSION: 1, PROCESS: 12) No restore is in process. TSM 5.3.2 on Windows 2003. Kelly
Move NodeData and copypools
I have 2 copypools, one for high priority DR required nodes, and the other for everything else. The DR copypool is collocated. Every month or so, I get a request to move a node into the DR pools. I can use the move nodedata command to move things between the non-copypools, but I need to find a way to move data between the two copypools. If I can't get the data moved for a node from the regular copypool into the dr copypool then I have to take about 500 extra tapes when we do our dr testing, and the multitude of tape mounts required for recovery really slows the process down. Does anyone have any idea how this could be accomplished? Thanks in advance! cory *E-Mail Confidentiality Notice* This message (including any attachments) contains information intended for a specific individual(s) and purpose that may be privileged, confidential or otherwise protected from disclosure pursuant to applicable law. Any inappropriate use, distribution or copying of the message is strictly prohibited and may subject you to criminal or civil penalty. If you have received this transmission in error, please reply to the sender indicating this error and delete the transmission from your system immediately.
Re: Move NodeData and copypools
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Cory Heikel I have 2 copypools, one for high priority DR required nodes, and the other for everything else. The DR copypool is collocated. Every month or so, I get a request to move a node into the DR pools. I can use the move nodedata command to move things between the non-copypools, but I need to find a way to move data between the two copypools. If I can't get the data moved for a node from the regular copypool into the dr copypool then I have to take about 500 extra tapes when we do our dr testing, and the multitude of tape mounts required for recovery really slows the process down. Does anyone have any idea how this could be accomplished? Data cannot be moved from one copy pool to another; this is a design feature of TSM. However, there is a workaround. MOVED_NODE= node to be moved to DR_TAPEPOOL NORM_TAPEPOOL = normal primary pool DR_TAPEPOOL = DR primary pool NORM_COPYPOOL = normal copy pool DR_COPYPOOL = DR copy pool 1. Move MOVED_NODE's data from NORM_TAPEPOOL to DR_TAPEPOOL by running MOVE NODEDATA MOVED_NODE FROMSTG=NORM_TAPEPOOL TOSTG=DR_TAPEPOOL 2. Run BACKUP STG DR_TAPEPOOL DR_COPYPOOL This will copy all data in DR_TAPEPOOL to DR_COPYPOOL, including MOVED_NODE. MOVED_NODE's data in NORM_COPYPOOL will then be collected onto a single tape. 3. Deny access to all volumes belonging to NORM_COPYPOOL and residing in the tape library by running UPDATE VOLUME * ACCESS=READONLY WHERESTG=NORM_COPYPOOL WHEREACC=READW This will force step #4's action onto a new empty tape volume. 4. Run MOVE NODEDATA MOVED_NODE FROMSTG=NORM_COPYPOOL When finished, all of MOVED_NODE's data in NORM_COPYPOOL will reside on their own tape volume. Make a note of this new volume's number (tape 000324, for example). 5. Correct the access statuses changed in step #3 command above by running UPDATE VOLUME * ACCESS=READWRITE WHERESTG=NORM_COPYPOOL WHEREACC=READONLY 6. Now delete MOVED_NODE's data from NORM_COPYPOOL by running DEL VOLUME 000324 DISCARDDATA=YES You now have all of MOVED_NODE's data in DR_TAPEPOOL and DR_COPYPOOL. If you're naturally paranoid (like myself) you won't perform step #6 until all tapes belonging to DR_COPYPOOL are residing in your vault. -- Mark Stapleton ([EMAIL PROTECTED]) Office 262.521.5627
Move nodedata question
Hello Everyone, I am in the process of changing the management class structure in TSM. I have some servers with archive data that we need to keep. I need to bounce my thoughts on this off anyone who has had experience with this to make sure I am thinking correctly here. Scenario: I am moving server A to a new Policy Domain which points to a new storage. Server A has backup and Archive data under the old domain. When I issue an incremental backup the backup data will be rebound but not moved. I manually move all the node data for Server A to the new Storage Pool (move nodedata .). If I keep the old Domain and do not delete it will the Archive data hold the old management class and just be on the new storage? I am thinking it will but again I want to make sure here Any help you can give on this would be great. Thanks, Andrew This message is intended only for the use of the Addressee and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please erase all copies of the message and its attachments and notify us immediately. Thank you.
Re: Backupsets and move nodedata
== In article [EMAIL PROTECTED], Steve Harris [EMAIL PROTECTED] writes: I'd also like to optimize for restore, but without the overheads of collocation. So, I'm considering running a move nodedata on every node periodically - maybe once a month for production, once every three months for non-production. You run a reasonable chance of saving some resources here, but you're going to have to 'cook' the process pretty carefully. For example, if you faux-collocate your library on (say) day 100, but write indiscriminately from days 100-130, you will probably have to empty all of your written tapes on day 131; many or most of them will have been filled with random-owned data written above the faux-collocated area. One thing you can do is define an extra, collocated stgpool, and move data to it as you deem fit: So: DISKPOOL - TAPEPOOL (non-collocated) CTAPEPOOL (collocated) And when you get a full volume in TAPEPOOL, you MOVE DATA it over to CTAPEPOOL. ... The critical thing to evaluate here is exactly which overheads of collocation you think you're going to dodge. You'll still have the reclamation overhead: nearly all of your data is in fact collocated. You'll still have the tape inefficiency, for the same reason. You'll avoid some tape-mount overhead: instead of mounting most tapes in your tape pool every day, you'll only mount a few for migration. However, what you pay for this is the expectation of mounting every tape in TAPEPOOL for any given restore. If you keep that low (i.e. only one filling tape) that could be reasonable. But if you move data out of TAPEPOOL only once a month or so, you'll probably accumulate 10 or 20 tapes in there before you clean house. That will make the MOVE DATA process long and re-mount-iferous, and it will mean most restores will go from one or two mounts to 10s. And if you fill tapes every day (and thus in my scheme MOVE DATA every day) you've in fact lost ground, because you move data one additional time. In any case I'd -strongly- advocate against moving data around in a -non- collocated stgpool and thinking you've improved matters much. - Allen S. Rout
Backupsets and move nodedata
Hi all, I'm considering running backupsets every month, which is something that I've not done before. I'd also like to optimize for restore, but without the overheads of collocation. So, I'm considering running a move nodedata on every node periodically - maybe once a month for production, once every three months for non-production. Has anyone tried this sort of optimisation? Does it give reasonable results? any issues? Thanks Steve Steve Harris AIX and TSM Admin *** This email, including any attachments sent with it, is confidential and for the sole use of the intended recipient(s). This confidentiality is not waived or lost, if you receive it and you are not the intended recipient(s), or if it is transmitted/received in error. Any unauthorised use, alteration, disclosure, distribution or review of this email is prohibited. It may be subject to a statutory duty of confidentiality if it relates to health service matters. If you are not the intended recipient(s), or if you have received this email in error, you are asked to immediately notify the sender by telephone or by return email. You should also delete this email and destroy any hard copies produced. ***
Question about the Move NODEDATA Command
Hi All, Hopefully a quick question, if I perform a move node data command for a client in the primary storage pool, and it moves all the data onto one tape in that storage pool, will this change be written out to the copy storage pools? i.e will the copy storage pools, after doing a backup of the primary, have all the data for that client on one tape as well, or do I have to issue the move node data command for the copy storage pools as well? TSM Server 5.1.8.0 Thanks in advance Steve Copper __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re: Question about the Move NODEDATA Command
On Wed, Jun 09, 2004 at 08:43:19AM +0100, Copper, Steve wrote: pools? i.e will the copy storage pools, after doing a backup of the primary, have all the data for that client on one tape as well, No, the copypool will not be affected. or do I have to issue the move node data command for the copy storage pools as well? Yes. Keep in mind that MOVE NODEDATA is not very useful for offsite copypools, since it requires the copypool-volumes to be onsite and available. (It doesn't work like e.g. MOVE DATA does, which gets the files from the primary pool) -- Jurjen Oskam Avoid putting a paging file on a fault-tolerant drive, such as a mirrored volume or a RAID-5 volume. Paging files do not need fault-tolerance.-MS Q308417
Re: Another question on Move nodedata
One very common question about move nodedata Your CopypoolA data will expire as data in PoolB expires. You have two copies of your data, CopypoolA and B. Some weeks ago I posted a note about how you can get rid of you copy in Copypool A, search the archives. (As mentioned, it assumes that you are allowed to retrive your offsite tapes..) //Henrik Redell, Greg S. To: [EMAIL PROTECTED] greg.redell@cc: (bcc: Henrik Wahlstedt) GWL.COM Subject: Another question on Move nodedata Sent by: ADSM: Dist Stor Manager [EMAIL PROTECTED] RIST.EDU 2004-03-10 22:41 Please respond to ADSM: Dist Stor Manager If I do a move nodedata on for a node from one pool to another is the copy information from the old pool deleted also or does it remain out there forever? Storage pool backups defined as such Backup stgpool PoolA to copypoolA Backup Stgpool PoolB to copypoolB Move nodedata from PoolA to PoolB. What happens to the copy data in copypoolA Greg Redell Great-West Life Annuity Insurance Co. Phone: 314-543-7009 Email: [EMAIL PROTECTED] --- The information contained in this message may be CONFIDENTIAL and is intended for the addressee only. Any unauthorised use, dissemination of the information or copying of this message is prohibited. If you are not the addressee, please notify the sender immediately by return e-mail and delete this message. Thank you.
Another question on Move nodedata
If I do a move nodedata on for a node from one pool to another is the copy information from the old pool deleted also or does it remain out there forever? Storage pool backups defined as such Backup stgpool PoolA to copypoolA Backup Stgpool PoolB to copypoolB Move nodedata from PoolA to PoolB. What happens to the copy data in copypoolA Greg Redell Great-West Life Annuity Insurance Co. Phone: 314-543-7009 Email: [EMAIL PROTECTED]
Re: Move Nodedata starts and ends without doing anything
On Tue, Nov 11, 2003 at 01:06:31PM -0500, Lee, Gary D. wrote: Don't think you can do a move nodedata for a copy pool. Must be done on a primary pool. From: Jurjen Oskam [mailto:[EMAIL PROTECTED] That's not true. MOVE NODEDATA works on any storagepool, *if* the needed volumes are onsite and readable. Ahem. From HELP MOVE NODEDATA from TSM server version 5.1.6.2: ...if the source storage pool is a copy storage pool the destination must be the same copy storage pool. However, this may all really be moot. If the old copy pool was up-to-date, and the new copy pool is up-to-date, the data in the old copy pool is redundant. In *that* case, there's no need to run a MOVE NODEDATA, since all data is already in the new pool. You can safely run DEL VOLUME VOLUME DISCARDDATA=YES for each volume in the old copy pool, and if those volumes were all listed as ACCESS=OFFSITE, you must follow up with UPD VOL * WHERESTGPOOL=OLDCOPYPOOL ACCESS=READWRITE at which time all the volumes in the old copy pool will disappear. -- Mark Stapleton ([EMAIL PROTECTED])
Re: Move Nodedata starts and ends without doing anything
On Tue, Nov 11, 2003 at 02:01:33PM -0500, Richard Sims wrote: That obviously precludes Access=Offsite. And wouldn't it be nice if the programmers put out some kind of message when the function ends up copying none of the data that the customer requested? (Come on, IBM - that's not enterprise level programming.) You wouldn't believe how much effort it took to get APAR IC36499 opened (which addresses this issue). How it finally got opened: I nailed them with the fact that even a MOVE NODEDATA on a *non-existant* filespace reported success with 0 bytes moved. At first support even classified this as works as designed: Since there wasn't any data to be moved, moving 0 bytes is success. After I asked them to fix the DELETE FILESPACE command (which *does* give an error on a non-existant filespace), support instead finally opened the APAR for MOVE NODEDATA. Once the APAR was opened, a programmer apparently took advantage of it to also include the reporting of off-site volumes. -- Jurjen Oskam PGP Key available at http://www.stupendous.org/
Antwort: Re: Move Nodedata starts and ends without doing anything
I agree, a move data works on offsite tapes, the primary stgpool volumes are used, just as space reclamaition. I had a call open with TSM support were space reclamation always failed on several volumes with a database error. The funny thing was when you did a move data on the offsite pool it was successfull, but the next time a backup storagepool was run on the primary storagepool, TSM wanted to backup that file to the copypool. The problem only dissapeared after the files on these volumes expired, so what went wrong could not be traced back by 2nd level TSM support Mit freundlichen Grüßen / Best Regards Markus Veit An: [EMAIL PROTECTED] Kopie: Thema: Re: Move Nodedata starts and ends without doing anything [EMAIL PROTECTED] Received : 11.11.2003 21:17 Bitte antworten an ADSM: Dist Stor Manager I concur. I have done MOVE DATA on copypool tapes. TSM simply recopies the original onto new copypool tapes since it knows the real copy pool tapes are offsite ! Richard Sims [EMAIL PROTECTED] Sent by: ADSM: Dist Stor Manager [EMAIL PROTECTED] 11/11/2003 02:05 PM Please respond to ADSM: Dist Stor Manager To: [EMAIL PROTECTED] cc: Subject:Re: Move Nodedata starts and ends without doing anything Don't think you can do a move nodedata for a copy pool. Must be done on = a primary pool. Says the reference manual: The data can be located in either a primary or copy storage pool. The problem with the attempted operation was Offsitedness and TSM documentation and programming shortcomings. Richard Sims, BU
Move Nodedata starts and ends without doing anything
Recently, I moved data for several nodes from one Primary storage pool to another. That new primary storage pool is backing up to a different copy storage pool. Data for those servers in the original copy storage pool (stgpool_name='OFFSITE') is no longer needed. So, I was going to perform a move nodedata for those servers with FROMstgpool=OFFSITE (TOstgpool=OFFSITE is assumed since this is a copy storage pool) and then delete the new OFFSITE storage pool volumes with discarddata=yes to remove them from the old copy storage pool. But nothing moved. What is wrong? Thanks in advance, Todd + TSM Server 5.1.7.1 running on AIX 4.3.3. relevant storage pool info: Storage Pool Name: OFFSITE Storage Pool Type: Copy Device Class Name: LTO Reclamation Threshold: 100 Maximum Scratch Volumes Allowed: 100 Storage Pool Data Format: Native Total volumes used in stgpool currently: 71, all access=offsite That leaves 29 volumes available to be added to the storage pool. There are 19 scratch volumes in the library. Q OCC NT-DCO-EPRISE1 STG=OFFSITE (sorry if this ends up wrapping) Node Name Type Filespace Storage Number of PhysicalLogical NamePool Name Files Space Space Occupied Occupied (MB) (MB) -- -- -- - - - NT-DCO-EP- Bkup \\nt-dco-- OFFSITE39,645 3,990.87 3,950.56 RISE1 eprise1\- g$ NT-DCO-EP- Bkup \\nt-dco-- OFFSITE 9,567 493.96 475.78 RISE1 eprise1\- c$ 11/11/03 09:51:56 ANR2017I Administrator TLUNDSTE issued command: MOVE NODEDATA NT-DCO-EPRISE1 from=offsite maxprocess=1 reconstr=yes 11/11/03 09:51:56 ANR1643I MOVE NODEDATA: All file spaces for node NT-DCO-EPRISE1, will be moved. 11/11/03 09:51:56 ANR0984I Process 2579 for MOVE NODE DATA started in the BACKGROUND at 09:51:56. 11/11/03 09:51:56 ANR1284I Move node data started as process 2579. 11/11/03 09:51:56 ANR2110I MOVE NODEDATA started as process 2579. 11/11/03 09:51:56 ANR0609I MOVE NODEDATA started as process 2579. 11/11/03 09:51:56 ANR1288I Move node data process 2579 ended for storage pool OFFSITE. 11/11/03 09:51:56 ANR0985I Process 2579 for MOVE NODE DATA running in the BACKGROUND completed with completion state SUCCESS at 09:51:56. 11/11/03 09:51:56 ANR1290I Move node data from storage pool OFFSITE to storage pool OFFSITE has ended. Files Moved: 0, Bytes Moved: 0, Unreadable Files: 0, Unreadable Bytes: 0. +
Re: Move Nodedata starts and ends without doing anything
But nothing moved. What is wrong? The tapes are offsite and thus the data can't be moved?
Re: Move Nodedata starts and ends without doing anything
The only way I know of to get rid of the obsolete data in the original offsite storage pool is to delete vol discarddata=yes on the volumes involved in the offsite pool and then do a backup stg of the original primary storagepool to recopy the data remaining in that pool. David [EMAIL PROTECTED] 11/11/2003 11:08:02 AM Recently, I moved data for several nodes from one Primary storage pool to another. That new primary storage pool is backing up to a different copy storage pool. Data for those servers in the original copy storage pool (stgpool_name='OFFSITE') is no longer needed. So, I was going to perform a move nodedata for those servers with FROMstgpool=OFFSITE (TOstgpool=OFFSITE is assumed since this is a copy storage pool) and then delete the new OFFSITE storage pool volumes with discarddata=yes to remove them from the old copy storage pool. But nothing moved. What is wrong? Thanks in advance, Todd + TSM Server 5.1.7.1 running on AIX 4.3.3. relevant storage pool info: Storage Pool Name: OFFSITE Storage Pool Type: Copy Device Class Name: LTO Reclamation Threshold: 100 Maximum Scratch Volumes Allowed: 100 Storage Pool Data Format: Native Total volumes used in stgpool currently: 71, all access=offsite That leaves 29 volumes available to be added to the storage pool. There are 19 scratch volumes in the library. Q OCC NT-DCO-EPRISE1 STG=OFFSITE (sorry if this ends up wrapping) Node Name Type Filespace Storage Number of Physical Logical NamePool Name Files Space Space Occupied Occupied (MB) (MB) -- -- -- - - - NT-DCO-EP- Bkup \\nt-dco-- OFFSITE39,645 3,990.87 3,950.56 RISE1 eprise1\- g$ NT-DCO-EP- Bkup \\nt-dco-- OFFSITE 9,567 493.96 475.78 RISE1 eprise1\- c$ 11/11/03 09:51:56 ANR2017I Administrator TLUNDSTE issued command: MOVE NODEDATA NT-DCO-EPRISE1 from=offsite maxprocess=1 reconstr=yes 11/11/03 09:51:56 ANR1643I MOVE NODEDATA: All file spaces for node NT-DCO-EPRISE1, will be moved. 11/11/03 09:51:56 ANR0984I Process 2579 for MOVE NODE DATA started in the BACKGROUND at 09:51:56. 11/11/03 09:51:56 ANR1284I Move node data started as process 2579. 11/11/03 09:51:56 ANR2110I MOVE NODEDATA started as process 2579. 11/11/03 09:51:56 ANR0609I MOVE NODEDATA started as process 2579. 11/11/03 09:51:56 ANR1288I Move node data process 2579 ended for storage pool OFFSITE. 11/11/03 09:51:56 ANR0985I Process 2579 for MOVE NODE DATA running in the BACKGROUND completed with completion state SUCCESS at 09:51:56. 11/11/03 09:51:56 ANR1290I Move node data from storage pool OFFSITE to storage pool OFFSITE has ended. Files Moved: 0, Bytes Moved: 0, Unreadable Files: 0, Unreadable Bytes: 0. +
Re: Move Nodedata starts and ends without doing anything
Shouldn't it use primary storage volumes to get the data, just like a reclamation or a move data for acc=offsite volumes? But nothing moved. What is wrong? The tapes are offsite and thus the data can't be moved?
Re: Move Nodedata starts and ends without doing anything
The Admin Ref says for Move Data: You can use this command to move files from an offsite volume in a copy storage pool. Because the offsite volume cannot be mounted, the server obtains the files that are on the offsite volume from either a primary storage pool or another copy storage pool. These files are then written to the destination volumes in the original copy storage pool. There is no similar statement in the documentation for Move Nodedata. David [EMAIL PROTECTED] 11/11/2003 12:01:40 PM Shouldn't it use primary storage volumes to get the data, just like a reclamation or a move data for acc=offsite volumes? But nothing moved. What is wrong? The tapes are offsite and thus the data can't be moved?
Re: Move Nodedata starts and ends without doing anything
Don't think you can do a move nodedata for a copy pool. Must be done on a primary pool.
Re: Move Nodedata starts and ends without doing anything
Shouldn't it use primary storage volumes to get the data, just like a reclamation or a move data for acc=offsite volumes? Again, I urge reading the Technical Guide redbook to fully understand TSM functions before trying to use them. It's particularly important to do so because the command reference manual ends up getting just a fraction of the information presented in the TG - often omitting important facts, such as: The volumes added to this list have to have an access of READWRITE or READONLY. That obviously precludes Access=Offsite. And wouldn't it be nice if the programmers put out some kind of message when the function ends up copying none of the data that the customer requested? (Come on, IBM - that's not enterprise level programming.) Richard Sims, BU
Re: Move Nodedata starts and ends without doing anything
Don't think you can do a move nodedata for a copy pool. Must be done on = a primary pool. Says the reference manual: The data can be located in either a primary or copy storage pool. The problem with the attempted operation was Offsitedness and TSM documentation and programming shortcomings. Richard Sims, BU
Re: Move Nodedata starts and ends without doing anything
Well, there it is then. We'll see if TSM support comes back with this bit of information on their next attempt to resolve this issue. Their first attempt was to tell me that I couldn't move nodedata from a copy storage pool to another storage pool. I guess they didn't read the entire ESR. Anyway, I agree... a note about volume access being readwrite or readonly most certainly could be added to the help move nodedata text, as well. Thanks, Richard. ps. The Technical Guide redbook now has a direct link on my desktop. Thanks. Shouldn't it use primary storage volumes to get the data, just like a reclamation or a move data for acc=offsite volumes? Again, I urge reading the Technical Guide redbook to fully understand TSM functions before trying to use them. It's particularly important to do so because the command reference manual ends up getting just a fraction of the information presented in the TG - often omitting important facts, such as: The volumes added to this list have to have an access of READWRITE or READONLY. That obviously precludes Access=Offsite. And wouldn't it be nice if the programmers put out some kind of message when the function ends up copying none of the data that the customer requested? (Come on, IBM - that's not enterprise level programming.) Richard Sims, BU
Re: Move Nodedata starts and ends without doing anything
I concur. I have done MOVE DATA on copypool tapes. TSM simply recopies the original onto new copypool tapes since it knows the real copy pool tapes are offsite ! Richard Sims [EMAIL PROTECTED] Sent by: ADSM: Dist Stor Manager [EMAIL PROTECTED] 11/11/2003 02:05 PM Please respond to ADSM: Dist Stor Manager To: [EMAIL PROTECTED] cc: Subject:Re: Move Nodedata starts and ends without doing anything Don't think you can do a move nodedata for a copy pool. Must be done on = a primary pool. Says the reference manual: The data can be located in either a primary or copy storage pool. The problem with the attempted operation was Offsitedness and TSM documentation and programming shortcomings. Richard Sims, BU
Re: Move Nodedata starts and ends without doing anything
On Tue, Nov 11, 2003 at 10:08:02AM -0600, Todd Lundstedt wrote: them from the old copy storage pool. But nothing moved. What is wrong? The implementation of MOVE NODEDATA (especially early versions) is a bit wobbly. For your particular problem, see APAR IC36499. -- Jurjen Oskam PGP Key available at http://www.stupendous.org/
Re: Move Nodedata starts and ends without doing anything
On Tue, Nov 11, 2003 at 01:06:31PM -0500, Lee, Gary D. wrote: Don't think you can do a move nodedata for a copy pool. Must be done on a primary pool. That's not true. MOVE NODEDATA works on any storagepool, *if* the needed volumes are onsite and readable. Early MOVE NODEDATA versions just moved the data that was available onsite and readable, and always reported success. If no volumes were onsite, it would report success with 0 bytes moved. If *some* volumes were onsite and readable, it would report success with the amount of bytes moved. In the latter case, there is no practical way to see if all the data was indeed moved. -- Jurjen Oskam PGP Key available at http://www.stupendous.org/
Re: Move nodedata - what is moved first
Marc, Part of our routine to send tapes offsite includes BACKUP STGPOOL DISKDIRPOOL COPYPOOL which send the DIRMC storage pool offsite. Part of the restoration procedure includes RESTORE STGPOOL DISKDIRPOOL Milton Johnson Voice: 210-677-6728 Email: [EMAIL PROTECTED] -Original Message- From: Marc Levitan [mailto:[EMAIL PROTECTED] Sent: Friday, October 24, 2003 8:13 AM To: [EMAIL PROTECTED] Subject: Re: Move nodedata - what is moved first What would happen if there was a site disaster and the data was only on the disk which is no longer available to perform restores? I guess what I am asking is, without sending DIRMC off-site, can you recover from a site disaster? |-+--- | | Deon George | | | [EMAIL PROTECTED]| | | .COM | | | Sent by: ADSM: | | | Dist Stor | | | Manager| | | [EMAIL PROTECTED]| | | T.EDU | | | | | | | | | 10/23/2003 08:07| | | PM | | | Please respond | | | to ADSM: Dist | | | Stor Manager | | | | |-+--- --- | | | |To: [EMAIL PROTECTED] | |cc: | |Subject: Re: Move nodedata - what is moved first | --- | Peter, servers . Currently, our main file server has data on over 200 3590 tapes therefore a directory restore can potentially have hours added to the process directly related to tape mounts. Is the directory information you referring about related to Windows systems? You should use the DIRMC client option to store all your directory information in a DISK based storage pool (DISK or FILE), so that it remains on faster quicker access media for restore purposes. (Dont let that stuff go to tape for the reasons you have outlined below.) The DIRMC client option is not really required for Unix based systems, as the database has enough space to store that information. ...deon --- Have you looked at the A/NZ Tivoli User Group website? http://www.tuganz.org Deon George, IBM Tivoli Software Engineer, IBM Australia Office: +61 3 9626 6058, Fax: +61 3 9626 6622, Mobile: +61 412 366 816, IVPN +70 66058 mailto:[EMAIL PROTECTED], http://www.ibm.com/tivoli
Re: Move nodedata - what is moved first
You should backup your storage pool with directory information (its a primary pool), to a secondary storage pool and send that offsite for your disaster recovery! (But its not absolutely required for DR - you can restore your files without the DIRMC information). If the primary ever gets destroyed, then you can restore that storage pool - at a convenient time. If you are in a disaster, then that storage pool would be one of the first things that get restored to facilitate the restore of your other servers that you would have to do. (Thus try and reduce the number of offsite tapes that information might be spread across). ...deon --- Have you looked at the A/NZ Tivoli User Group website? http://www.tuganz.org Deon George, IBM Tivoli Software Engineer, IBM Australia Office: +61 3 9626 6058, Fax: +61 3 9626 6622, Mobile: +61 412 366 816, IVPN +70 66058 mailto:[EMAIL PROTECTED], http://www.ibm.com/tivoli ADSM: Dist Stor Manager [EMAIL PROTECTED] wrote on 24/10/2003 11:12:34 PM: What would happen if there was a site disaster and the data was only on the disk which is no longer available to perform restores? I guess what I am asking is, without sending DIRMC off-site, can you recover from a site disaster?
Re: Move nodedata - what is moved first
If the data was only on the disk, I would say your disaster recovery preparation needs serious fix! The idea is that you backup the whole storage pool *hierarchy* to a copy pool. For example hierarchy DISKPOOL - TAPEPOOL must be backed up with 1. ba stg diskpool copypool 2. ba stg tapepool copypool 3. ba db t=dbs Without backing up the diskpool to a onsite copy pool you are exposed to data loss in case of disk storage failure (even if there is no site-wide disaster). Zlatko Krastev IT Consultant Marc Levitan [EMAIL PROTECTED] Sent by: ADSM: Dist Stor Manager [EMAIL PROTECTED] 24.10.2003 16:12 Please respond to ADSM: Dist Stor Manager To: [EMAIL PROTECTED] cc: Subject:Re: Move nodedata - what is moved first What would happen if there was a site disaster and the data was only on the disk which is no longer available to perform restores? I guess what I am asking is, without sending DIRMC off-site, can you recover from a site disaster? |-+--- | | Deon George | | | [EMAIL PROTECTED]| | | .COM | | | Sent by: ADSM: | | | Dist Stor | | | Manager| | | [EMAIL PROTECTED]| | | T.EDU | | | | | | | | | 10/23/2003 08:07| | | PM | | | Please respond | | | to ADSM: Dist | | | Stor Manager | | | | |-+--- ---| || |To: [EMAIL PROTECTED] | |cc:| |Subject: Re: Move nodedata - what is moved first | ---| Peter, servers . Currently, our main file server has data on over 200 3590 tapes therefore a directory restore can potentially have hours added to the process directly related to tape mounts. Is the directory information you referring about related to Windows systems? You should use the DIRMC client option to store all your directory information in a DISK based storage pool (DISK or FILE), so that it remains on faster quicker access media for restore purposes. (Dont let that stuff go to tape for the reasons you have outlined below.) The DIRMC client option is not really required for Unix based systems, as the database has enough space to store that information. ...deon --- Have you looked at the A/NZ Tivoli User Group website? http://www.tuganz.org Deon George, IBM Tivoli Software Engineer, IBM Australia Office: +61 3 9626 6058, Fax: +61 3 9626 6622, Mobile: +61 412 366 816, IVPN +70 66058 mailto:[EMAIL PROTECTED], http://www.ibm.com/tivoli
Re: Move nodedata - what is moved first
What would happen if there was a site disaster and the data was only on the disk which is no longer available to perform restores? I guess what I am asking is, without sending DIRMC off-site, can you recover from a site disaster? |-+--- | | Deon George | | | [EMAIL PROTECTED]| | | .COM | | | Sent by: ADSM: | | | Dist Stor | | | Manager| | | [EMAIL PROTECTED]| | | T.EDU | | | | | | | | | 10/23/2003 08:07| | | PM | | | Please respond | | | to ADSM: Dist | | | Stor Manager | | | | |-+--- ---| | | |To: [EMAIL PROTECTED] | |cc: | |Subject: Re: Move nodedata - what is moved first | ---| Peter, servers . Currently, our main file server has data on over 200 3590 tapes therefore a directory restore can potentially have hours added to the process directly related to tape mounts. Is the directory information you referring about related to Windows systems? You should use the DIRMC client option to store all your directory information in a DISK based storage pool (DISK or FILE), so that it remains on faster quicker access media for restore purposes. (Dont let that stuff go to tape for the reasons you have outlined below.) The DIRMC client option is not really required for Unix based systems, as the database has enough space to store that information. ...deon --- Have you looked at the A/NZ Tivoli User Group website? http://www.tuganz.org Deon George, IBM Tivoli Software Engineer, IBM Australia Office: +61 3 9626 6058, Fax: +61 3 9626 6622, Mobile: +61 412 366 816, IVPN +70 66058 mailto:[EMAIL PROTECTED], http://www.ibm.com/tivoli
Re: Move nodedata - what is moved first
What would happen if there was a site disaster and the data was only on the disk which is no longer available to perform restores? I guess what I am asking is, without sending DIRMC off-site, can you recover from a site disaster? Marc - That would be the moral equivalent of a -FILESOnly restoral, wherein TSM creates default directories and attributes...not necessarily the best thing, but usually workable. Note that TSM typically performs restorals via this paradigm, restoring file system objects in the order that it finds them on tapes, to avoid reprocessing tapes, creating surrogate directories until the actual directory info may be found later in the current or subsequent tape. See topic Restore Order in http://people.bu.edu/rbs/ADSM.QuickFacts . Richard Sims, BU
Re: Move nodedata - what is moved first
On Fri, 24 Oct 2003 09:12:34 -0400 Marc Levitan [EMAIL PROTECTED] wrote: What would happen if there was a site disaster and the data was only on the disk which is no longer available to perform restores? I guess what I am asking is, without sending DIRMC off-site, can you recover from a site disaster? Even better, directories are never stored in storagepools, just in the database, so in case of a disaster, you will never loose any data as long as you have off-site db backups. -- Met vriendelijke groeten, Remco Post SARA - Reken- en Netwerkdiensten http://www.sara.nl High Performance Computing Tel. +31 20 592 8008Fax. +31 20 668 3167 I really didn't foresee the Internet. But then, neither did the computer industry. Not that that tells us very much of course - the computer industry didn't even foresee that the century was going to end. -- Douglas Adams
Re: Move nodedata - what is moved first
Even better, directories are never stored in storagepools, just in the database, so in case of a disaster, you will never loose any data as long as you have off-site db backups. True for simple directories, as found in Unix...same as empty files. But the more complex ones (Unix ACLs, Windows) have more attributes than can be accommodated in a TSM database entry so they have to be treated like non-empty files, and thus are stored in storage pools. This naturally extends the length of backup and restore sessions for such systems. Watching a substantial Unix restoral is beautiful, as all the directories come back right away, reconstructing the framework of the file system area long before any tape is mounted to restore data files. Richard Sims, BU
Re: Move nodedata - what is moved first
Not entirely true, I believe. If the directory tree for a particular node exceeds a certain size, it DOES get stored in a storage pool...although I'm a little foggy as to what that size is. That's the whole idea behind the DIRMC parameter...sot that you can control where the directory info winds up in the event that it does go to a storage pool. -Lloyd On Fri, 24 Oct 2003 18:02:07 +0200 Remco Post [EMAIL PROTECTED] wrote thusly: On Fri, 24 Oct 2003 09:12:34 -0400 Marc Levitan [EMAIL PROTECTED] wrote: What would happen if there was a site disaster and the data was only on the disk which is no longer available to perform restores? I guess what I am asking is, without sending DIRMC off-site, can you recover from a site disaster? Even better, directories are never stored in storagepools, just in the database, so in case of a disaster, you will never loose any data as long as you have off-site db backups. -- Met vriendelijke groeten, Remco Post SARA - Reken- en Netwerkdiensten http://www.sara.nl High Performance Computing Tel. +31 20 592 8008Fax. +31 20 668 3167 I really didn't foresee the Internet. But then, neither did the computer industry. Not that that tells us very much of course - the computer industry didn't even foresee that the century was going to end. -- Douglas Adams
Re: Move nodedata - what is moved first
Hi Peter, Actually I do not know the perfect answer for you. Anyway, for sure the move nodedata does not depend on what the oldest/newest data is. I believe the first thing what TSM does is to build a list of volumes were the node data is located and then processes each volume sequentally untill all data has been moved (copyed). How TSM picks the order of volumes I don't know (the volume holding the most data first or perhaps in alfabetical order). One volume can hold the oldest and newest data, imagine if oldest data is reclaimed to new volume and the same day, new data is migrated or backed up to that volume. You can start the move nodedata process and when the disk pool is full, the process probably ends with failure, but that is ok. After you have migrated the data from diskpool, you can start the move again and TSM goes on where it stopped. Best regards, Kolbeinn Josepsson · Systems Engineer Tivoli Certified Consultant - IBM Tivoli Storage Manager V5.1 www.nyherji.is StorageGroupAdmin StorageGroupAdmin [EMAIL PROTECTED] Sent by: ADSM: Dist Stor Manager [EMAIL PROTECTED] 23.10.2003 04:07 Please respond to ADSM: Dist Stor Manager [EMAIL PROTECTED] To [EMAIL PROTECTED] cc Subject Move nodedata - what is moved first --- This email is to be read subject to the disclaimer below. --- In an attempt to negate the mount time issue in the restore process I am currenlty using move nodedata to co-locate data for some of our servers . Currently, our main file server has data on over 200 3590 tapes therefore a directroy restore can potentially have hours added to the process directly related to tape mounts. back to the point.. Does any know the what method is used in determining which media within a storage pool is mounted first. For example, is it; - tape last write date, ie oldest tape first - newest data first (active files) and all other data on that media is moved - biggest file then all other data on the media is moved. Why do I want to know? To experdite the process, where possible, I read from multiple tapes onto our disk pool and then drain the pool to a single tape. The problem is the disk storage is not large enough or I have to cancel the process prior the night process being impacted. Therefore, I need to know what is being moved next time I run the process. Am I moving the same data again or will a subsequent execution of the command basically start where I left off Peter Griffin Sydney Water --- Mandatory water restrictions now apply in Sydney, Blue Mountains and the Illawarra. Fines of $220 apply from 1 November 2003. No sprinklers or watering systems at any time. No hosing of hard surfaces including vehicles at any time. For more information visit www.sydneywater.com.au --- NOTICE: This email is confidential. If you are not the nominated recipient, please immediately delete this email, destroy all copies, and inform the sender. Sydney Water Corporation (Sydney Water) prohibits the unauthorised copying or distribution of this email. This email does not necessarily express the views of Sydney Water. Sydney Water does not warrant nor guarantee that this email communication is free from errors, virus, interception or interference. --- ForwardSourceID:NT0003F952
Re: Move nodedata - what is moved first
Peter, servers . Currently, our main file server has data on over 200 3590 tapes therefore a directory restore can potentially have hours added to the process directly related to tape mounts. Is the directory information you referring about related to Windows systems? You should use the DIRMC client option to store all your directory information in a DISK based storage pool (DISK or FILE), so that it remains on faster quicker access media for restore purposes. (Dont let that stuff go to tape for the reasons you have outlined below.) The DIRMC client option is not really required for Unix based systems, as the database has enough space to store that information. ...deon --- Have you looked at the A/NZ Tivoli User Group website? http://www.tuganz.org Deon George, IBM Tivoli Software Engineer, IBM Australia Office: +61 3 9626 6058, Fax: +61 3 9626 6622, Mobile: +61 412 366 816, IVPN +70 66058 mailto:[EMAIL PROTECTED], http://www.ibm.com/tivoli
Move nodedata - what is moved first
--- This email is to be read subject to the disclaimer below. --- In an attempt to negate the mount time issue in the restore process I am currenlty using move nodedata to co-locate data for some of our servers . Currently, our main file server has data on over 200 3590 tapes therefore a directroy restore can potentially have hours added to the process directly related to tape mounts. back to the point.. Does any know the what method is used in determining which media within a storage pool is mounted first. For example, is it; - tape last write date, ie oldest tape first - newest data first (active files) and all other data on that media is moved - biggest file then all other data on the media is moved. Why do I want to know? To experdite the process, where possible, I read from multiple tapes onto our disk pool and then drain the pool to a single tape. The problem is the disk storage is not large enough or I have to cancel the process prior the night process being impacted. Therefore, I need to know what is being moved next time I run the process. Am I moving the same data again or will a subsequent execution of the command basically start where I left off Peter Griffin Sydney Water --- Mandatory water restrictions now apply in Sydney, Blue Mountains and the Illawarra. Fines of $220 apply from 1 November 2003. No sprinklers or watering systems at any time. No hosing of hard surfaces including vehicles at any time. For more information visit www.sydneywater.com.au --- NOTICE: This email is confidential. If you are not the nominated recipient, please immediately delete this email, destroy all copies, and inform the sender. Sydney Water Corporation (Sydney Water) prohibits the unauthorised copying or distribution of this email. This email does not necessarily express the views of Sydney Water. Sydney Water does not warrant nor guarantee that this email communication is free from errors, virus, interception or interference. ---
Re: Move NodeData, and copy storage pools
On Tue, Sep 16, 2003 at 11:33:36AM -0500, Todd Lundstedt wrote: Am I stuck with doing a move nodedata within the OrigCopyStg, then deleting the volumes? Only if you are prepared to retrieve your off-site copypool volumes onsite again; if you are not (as you should be :-) ) you have two options: * Wait until all data on the old copypool is expired * Delete volumes of the old copypool containing data of the affected node and issue BACKUP STGPOOL for each primary pool that is backed up to the old copypool. MOVE NODEDATA *has* to have to volumes onsite, even if you're moving data in a copypool. It's not smart enough to take the data from the primary pools. Yes, this s*cks, and yes, DELETE NODEDATA would be handy. :-) -- Jurjen Oskam PGP Key available at http://www.stupendous.org/
Move NodeData, and copy storage pools
TSM 5.1.7.1 on AIX 4.3.3 I have moved data for several nodes from one primary storage pool to another primary storage pool. Each of these primaries has a different copy storage pool defined. OrigPrimaryStg -- OrigCopyStg NewPrimaryStg -- NewCopyStg move nodedata node1,node2 from=OrigPrimaryStg to=NewPrimaryStg After the move, the backup of the NewPrimaryStg copied the data to NewCopyStg, but how do I remove the data from OrigCopyStg? Per the documentation, one cannot move data from one copy storage pool to another. Am I stuck with doing a move nodedata within the OrigCopyStg, then deleting the volumes? I am assuming after the move nodedata, I could delete vol xx discarddata=yes for the OrigCopyStg volumes that contain ONLY data from node1 and node2, and it will NOT delete the data in the primary storage pool (NewPrimaryStg) and it's copy storage pool (NewCopyStg). Is that a correct assumption, too? Help on Delete Volume indicates copies will be deleted when primaries volumes are deleted, but it doesn't specify if primaries are deleted when copy volumes are deleted. Thanks in advance Todd
Re: Move NodeData, and copy storage pools
You are stuck doing del vol xxx discarddata=yes' for volumes left in OrigCopyStg. This will not delete data from NewCopyStg. If you have nodes left in OrigPrimaryStg then a subsequent backup stg OrigPrimaryStg OrigCopyStg will recreate the copy pool backup for the nodes that remain in OrigCopyStg. David Ehresman
Re: Move NodeData, and copy storage pools
If you move data from one primary pool to another primary pool wouldn't the next backup stg mark the moved data on the orig primary pool as deleted and back-up up the data from the newprimary pool to the defined copypool? Regard, Karel -Oorspronkelijk bericht- Van: Todd Lundstedt [mailto:[EMAIL PROTECTED] Verzonden: dinsdag 16 september 2003 18:34 Aan: [EMAIL PROTECTED] Onderwerp: Move NodeData, and copy storage pools TSM 5.1.7.1 on AIX 4.3.3 I have moved data for several nodes from one primary storage pool to another primary storage pool. Each of these primaries has a different copy storage pool defined. OrigPrimaryStg -- OrigCopyStg NewPrimaryStg -- NewCopyStg move nodedata node1,node2 from=OrigPrimaryStg to=NewPrimaryStg After the move, the backup of the NewPrimaryStg copied the data to NewCopyStg, but how do I remove the data from OrigCopyStg? Per the documentation, one cannot move data from one copy storage pool to another. Am I stuck with doing a move nodedata within the OrigCopyStg, then deleting the volumes? I am assuming after the move nodedata, I could delete vol xx discarddata=yes for the OrigCopyStg volumes that contain ONLY data from node1 and node2, and it will NOT delete the data in the primary storage pool (NewPrimaryStg) and it's copy storage pool (NewCopyStg). Is that a correct assumption, too? Help on Delete Volume indicates copies will be deleted when primaries volumes are deleted, but it doesn't specify if primaries are deleted when copy volumes are deleted. Thanks in advance Todd
Re: move nodedata
Andy, I was trying to say that that your tweaking will expire/delete *all* copies of an object simultaneously, be they in a primary pool or first or second copypool. As result it will be *equivalent* to `del fi` command. I am not saying you can accomplish what you are looking for with the `del fi` command. Also you should distinguish between different stages in file lifecycle within TSM: 0. File is in a node's filesystem 1. During node backup a copy of the file is created and stored in TSM server as an *object*!!! The object is bound to a mgmtclass according to include/exclude list and copygroup settings are honored. 2. During stgpool backup additional objects are created from the original one and are linked to it. Copypool objects have no direct link to mgmtclass/copygroup 3a. Deletion of volume in a copypool discards only some of the objects created in step 2 and their corresponding links 3b. Exipration mandated by copygroup settings discards *primary* objects created in step 1. Relational consistency links delete *all* objects linked to those primary objects, i.e. all copies in all copypools! 3c. Move of an object from a storage pool to another *does not* play any role in the expiration process. That is the beauty of TSM - you have not to care where your data is, the TSM server can be thought as a black box managed by policies. Whether you will create new domain with tweaked settings and move the node to it or modify production policy domain settings does not make difference for that node's data - it will be discarded simultaneously from all stgpools. But tweaking of production domain will throw away the data of all nodes in that domain and the only way back will be TSM database restore!!! So be careful. Example: daily backups go to stgpoolA before sunday weekly backups are taken the copygroup is updated to point stgpoolB weekly backup goes to stgpoolB monday morning copygroup is set back to stgpoolA stgpoolA is backed up daily to stgcopyA stgpoolB is backed up weekly to both stgcopyA and stgcopyB Now if in a weekday you set copygroup retention settings to expire all but one versions, which files will survive? From your posts I am under impression you think only copies in stgcopyA will expire and copies in stgcopyB will be kept as the policy domain does not refer to that pool at all. In the TSM universe the rules are that all those primary versions will expire and their copies from both stgcopyA and stgcopyB will dismiss. The things would not change at all if we modify the scenario to use `move data` somehow. Zlatko Krastev IT Consultant Wilcox, Andy [EMAIL PROTECTED] Sent by: ADSM: Dist Stor Manager [EMAIL PROTECTED] 03.09.2003 10:42 Please respond to ADSM: Dist Stor Manager To: [EMAIL PROTECTED] cc: Subject:Re: move nodedata Zlatko, I do agree with what you are saying but my point was if you have moved node data from one stgpool to another, but at the same time changed the domain of the node, what would happen to the data in the old copypool??? Does it maintain the same copy group/domain definitions for node which would now be in a new domain??? If not then surely it would be feasible to tweak the old copygroup params (subject to having no nodes being in the old domain using the to-be-tweaked copygroup definitions) to reduce expire the data on the storagepool. On the otherhand if updating the nodes domain, does also apply to data in the old copypool, you are indeed correct and you would have to be incredibly crazy to do such a thing. After writing my response above I think I have may have blurred and complicated what I was trying to say, for which I do apologise. On a different note I wasn't aware that you could delete a filespace from a specific storage/copy pool which is partly why this problem exists for me. I am running TSM 5.1.6.2 has this capability been included in a later release? Cheers Andy Wilcox Midrange Services Aquila Networks Services Ltd -Original Message- From: Zlatko Krastev [SMTP:[EMAIL PROTECTED] Sent: 02 September 2003 18:07 To: [EMAIL PROTECTED] Subject: Re: move nodedata -- Has anyone tried eliminating the old copypool data by tweaking the copygroup parameters down to pretty much nothing ... Andy, you are suggesting something useless but VERY VERY dangerous! Tweaking copygroup parameters will force expiration of *primary* pool copies and only as a consequence expiration of copies in *both* copypools!!! There is no need to bother with tweaking, `delete filespace` command will give you nearly the same results but I doubt you are willing to use it. -- ... although I could be wrong ... You are, indeed! Zlatko Krastev IT Consultant Wilcox, Andy [EMAIL PROTECTED] Sent by: ADSM: Dist Stor Manager [EMAIL PROTECTED] 02.09.2003 14:21 Please respond to ADSM: Dist Stor Manager To: [EMAIL PROTECTED] cc: Subject:Re: move nodedata Hiya Henrik
Re: move nodedata
Zlatko, I do agree with what you are saying but my point was if you have moved node data from one stgpool to another, but at the same time changed the domain of the node, what would happen to the data in the old copypool??? Does it maintain the same copy group/domain definitions for node which would now be in a new domain??? If not then surely it would be feasible to tweak the old copygroup params (subject to having no nodes being in the old domain using the to-be-tweaked copygroup definitions) to reduce expire the data on the storagepool. On the otherhand if updating the nodes domain, does also apply to data in the old copypool, you are indeed correct and you would have to be incredibly crazy to do such a thing. After writing my response above I think I have may have blurred and complicated what I was trying to say, for which I do apologise. On a different note I wasn't aware that you could delete a filespace from a specific storage/copy pool which is partly why this problem exists for me. I am running TSM 5.1.6.2 has this capability been included in a later release? Cheers Andy Wilcox Midrange Services Aquila Networks Services Ltd -Original Message- From: Zlatko Krastev [SMTP:[EMAIL PROTECTED] Sent: 02 September 2003 18:07 To: [EMAIL PROTECTED] Subject: Re: move nodedata -- Has anyone tried eliminating the old copypool data by tweaking the copygroup parameters down to pretty much nothing ... Andy, you are suggesting something useless but VERY VERY dangerous! Tweaking copygroup parameters will force expiration of *primary* pool copies and only as a consequence expiration of copies in *both* copypools!!! There is no need to bother with tweaking, `delete filespace` command will give you nearly the same results but I doubt you are willing to use it. -- ... although I could be wrong ... You are, indeed! Zlatko Krastev IT Consultant Wilcox, Andy [EMAIL PROTECTED] Sent by: ADSM: Dist Stor Manager [EMAIL PROTECTED] 02.09.2003 14:21 Please respond to ADSM: Dist Stor Manager To: [EMAIL PROTECTED] cc: Subject:Re: move nodedata Hiya Henrik, I have recently been doing pretty much what you are trying to achieve. The problem you have is the biggest issue with the move nodedata command. From reading across the many articles on here, it appears that the only way to get rid of the old copypool data is to delete the volumes containing the data. Luckily for me I am doing a massive tidyup and plan to remove our old copypools for this very reason. Food for thought though... Has anyone tried eliminating the old copypool data by tweaking the copygroup parameters down to pretty much nothing, and letting expiration clear most of it down? Would this even work, as I get the impression that the data in the old copypool maintains its original retention settings, although I could be wrong (I also assume that you would need to move the node into a new domain as well as tweaking the copygroup params would otherwise affect the live data)??? Any ideas? Cheers Andy Wilcox Midrange Services Aquila Networks Services Ltd -Original Message- From: Henrik Wahlstedt [SMTP:[EMAIL PROTECTED] Sent: 02 September 2003 09:51 To: [EMAIL PROTECTED] Subject: move nodedata Hello, I wanted and tried to move a nodes data to a different storagepool, non-collocated to collocated. From dlt-standard with copypool to dlt-monthly with copypool-monthly. (move nodedata xxx from=dlt-standard to=dlt-monthly) Move within primarypools went ok and I thought that admin schedules (ba stg, expire inventory) would take care of my copypool. I was wrong. Now I have my nodes data on both copypools but only on dlt-monthly priamaypool. (q occ xxx) I havn4t tried to move nodedata xxx from=copypool to=copypool-monthly... 1. What would I have done instead of move nodedata to get a better result? 2. How do I get rid of the extra copy in copypool? 3. Works as designed? tia //Henrik tsm: STO-W03h move nodedata MOVE NODEDATA MOVE NODEDATA (Move Data by Node in a Sequential Access Storage Pool) Use this command to move data located in a sequential-access storage pool. You can move data for one or more nodes, or a single node with selected filespaces. The data can be located in either a primary or copy storage pool. This command is helpful for reducing the number of volume mounts during client restore or retrieve operations by consolidating data for a specific node within a storage pool, or to move data to another storage pool. For example, you can use this command for moving data to a random-access storage pool in preparation for client restore processing. --- The information contained in this message may
move nodedata
Hello, I wanted and tried to move a nodes data to a different storagepool, non-collocated to collocated. From dlt-standard with copypool to dlt-monthly with copypool-monthly. (move nodedata xxx from=dlt-standard to=dlt-monthly) Move within primarypools went ok and I thought that admin schedules (ba stg, expire inventory) would take care of my copypool. I was wrong. Now I have my nodes data on both copypools but only on dlt-monthly priamaypool. (q occ xxx) I havn´t tried to move nodedata xxx from=copypool to=copypool-monthly... 1. What would I have done instead of move nodedata to get a better result? 2. How do I get rid of the extra copy in copypool? 3. Works as designed? tia //Henrik tsm: STO-W03h move nodedata MOVE NODEDATA MOVE NODEDATA (Move Data by Node in a Sequential Access Storage Pool) Use this command to move data located in a sequential-access storage pool. You can move data for one or more nodes, or a single node with selected filespaces. The data can be located in either a primary or copy storage pool. This command is helpful for reducing the number of volume mounts during client restore or retrieve operations by consolidating data for a specific node within a storage pool, or to move data to another storage pool. For example, you can use this command for moving data to a random-access storage pool in preparation for client restore processing. --- The information contained in this message may be CONFIDENTIAL and is intended for the addressee only. Any unauthorised use, dissemination of the information or copying of this message is prohibited. If you are not the addressee, please notify the sender immediately by return e-mail and delete this message. Thank you.
Re: move nodedata
Hiya Henrik, I have recently been doing pretty much what you are trying to achieve. The problem you have is the biggest issue with the move nodedata command. From reading across the many articles on here, it appears that the only way to get rid of the old copypool data is to delete the volumes containing the data. Luckily for me I am doing a massive tidyup and plan to remove our old copypools for this very reason. Food for thought though... Has anyone tried eliminating the old copypool data by tweaking the copygroup parameters down to pretty much nothing, and letting expiration clear most of it down? Would this even work, as I get the impression that the data in the old copypool maintains its original retention settings, although I could be wrong (I also assume that you would need to move the node into a new domain as well as tweaking the copygroup params would otherwise affect the live data)??? Any ideas? Cheers Andy Wilcox Midrange Services Aquila Networks Services Ltd -Original Message- From: Henrik Wahlstedt [SMTP:[EMAIL PROTECTED] Sent: 02 September 2003 09:51 To: [EMAIL PROTECTED] Subject: move nodedata Hello, I wanted and tried to move a nodes data to a different storagepool, non-collocated to collocated. From dlt-standard with copypool to dlt-monthly with copypool-monthly. (move nodedata xxx from=dlt-standard to=dlt-monthly) Move within primarypools went ok and I thought that admin schedules (ba stg, expire inventory) would take care of my copypool. I was wrong. Now I have my nodes data on both copypools but only on dlt-monthly priamaypool. (q occ xxx) I havn´t tried to move nodedata xxx from=copypool to=copypool-monthly... 1. What would I have done instead of move nodedata to get a better result? 2. How do I get rid of the extra copy in copypool? 3. Works as designed? tia //Henrik tsm: STO-W03h move nodedata MOVE NODEDATA MOVE NODEDATA (Move Data by Node in a Sequential Access Storage Pool) Use this command to move data located in a sequential-access storage pool. You can move data for one or more nodes, or a single node with selected filespaces. The data can be located in either a primary or copy storage pool. This command is helpful for reducing the number of volume mounts during client restore or retrieve operations by consolidating data for a specific node within a storage pool, or to move data to another storage pool. For example, you can use this command for moving data to a random-access storage pool in preparation for client restore processing. --- The information contained in this message may be CONFIDENTIAL and is intended for the addressee only. Any unauthorised use, dissemination of the information or copying of this message is prohibited. If you are not the addressee, please notify the sender immediately by return e-mail and delete this message. Thank you. ** ** Confidentiality: This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error, use of this information (including disclosure, copying or distribution) may be unlawful. Please notify [EMAIL PROTECTED] and delete the message immediately. Security: Internet e-mail is not a 100% secure communications medium. Viruses: This e-mail (and any attachments) has been checked (using Sophos Sweep 3.68 + patches) and found to be clean from any virus infection before leaving. Therefore neither Aquila Networks Services Ltd nor Midlands Electricity plc or any of their group undertakings (as defined by the Companies Act 1989) (together referred to as the Companies) accept legal responsibility for this message or liability for the consequences of any computer viruses which may have been transmitted by this e-mail. Monitoring: All electronic communications with the Companies may be monitored in accordance with the UK Regulation of Investigatory Powers Act, Lawful Business Practice Regulations, 2000. If you do not consent to such monitoring, you should contact the sender of this e-mail. Aquila Networks Services Limited, Registered office: Whittington Hall, Whittington, Worcester, WR5 2RB Registered in England and Wales number 3600545 This e-mail may be sent on behalf of any of the Companies. ** **
Re: move nodedata
-- Has anyone tried eliminating the old copypool data by tweaking the copygroup parameters down to pretty much nothing ... Andy, you are suggesting something useless but VERY VERY dangerous! Tweaking copygroup parameters will force expiration of *primary* pool copies and only as a consequence expiration of copies in *both* copypools!!! There is no need to bother with tweaking, `delete filespace` command will give you nearly the same results but I doubt you are willing to use it. -- ... although I could be wrong ... You are, indeed! Zlatko Krastev IT Consultant Wilcox, Andy [EMAIL PROTECTED] Sent by: ADSM: Dist Stor Manager [EMAIL PROTECTED] 02.09.2003 14:21 Please respond to ADSM: Dist Stor Manager To: [EMAIL PROTECTED] cc: Subject:Re: move nodedata Hiya Henrik, I have recently been doing pretty much what you are trying to achieve. The problem you have is the biggest issue with the move nodedata command. From reading across the many articles on here, it appears that the only way to get rid of the old copypool data is to delete the volumes containing the data. Luckily for me I am doing a massive tidyup and plan to remove our old copypools for this very reason. Food for thought though... Has anyone tried eliminating the old copypool data by tweaking the copygroup parameters down to pretty much nothing, and letting expiration clear most of it down? Would this even work, as I get the impression that the data in the old copypool maintains its original retention settings, although I could be wrong (I also assume that you would need to move the node into a new domain as well as tweaking the copygroup params would otherwise affect the live data)??? Any ideas? Cheers Andy Wilcox Midrange Services Aquila Networks Services Ltd -Original Message- From: Henrik Wahlstedt [SMTP:[EMAIL PROTECTED] Sent: 02 September 2003 09:51 To: [EMAIL PROTECTED] Subject: move nodedata Hello, I wanted and tried to move a nodes data to a different storagepool, non-collocated to collocated. From dlt-standard with copypool to dlt-monthly with copypool-monthly. (move nodedata xxx from=dlt-standard to=dlt-monthly) Move within primarypools went ok and I thought that admin schedules (ba stg, expire inventory) would take care of my copypool. I was wrong. Now I have my nodes data on both copypools but only on dlt-monthly priamaypool. (q occ xxx) I havn´t tried to move nodedata xxx from=copypool to=copypool-monthly... 1. What would I have done instead of move nodedata to get a better result? 2. How do I get rid of the extra copy in copypool? 3. Works as designed? tia //Henrik tsm: STO-W03h move nodedata MOVE NODEDATA MOVE NODEDATA (Move Data by Node in a Sequential Access Storage Pool) Use this command to move data located in a sequential-access storage pool. You can move data for one or more nodes, or a single node with selected filespaces. The data can be located in either a primary or copy storage pool. This command is helpful for reducing the number of volume mounts during client restore or retrieve operations by consolidating data for a specific node within a storage pool, or to move data to another storage pool. For example, you can use this command for moving data to a random-access storage pool in preparation for client restore processing. --- The information contained in this message may be CONFIDENTIAL and is intended for the addressee only. Any unauthorised use, dissemination of the information or copying of this message is prohibited. If you are not the addressee, please notify the sender immediately by return e-mail and delete this message. Thank you. ** ** Confidentiality: This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error, use of this information (including disclosure, copying or distribution) may be unlawful. Please notify [EMAIL PROTECTED] and delete the message immediately. Security: Internet e-mail is not a 100% secure communications medium. Viruses: This e-mail (and any attachments) has been checked (using Sophos Sweep 3.68 + patches) and found to be clean from any virus infection before leaving. Therefore neither Aquila Networks Services Ltd nor Midlands Electricity plc or any of their group undertakings (as defined by the Companies Act 1989) (together referred to as the Companies) accept legal responsibility for this message or liability for the consequences of any computer viruses which may have been transmitted by this e-mail. Monitoring: All electronic
Re: move nodedata
On Mon, 21 Jul 2003 22:59:28 -0400 bizzorg [EMAIL PROTECTED] wrote: What happened to the move Nodedata function? We're running on z/OS 1.2 TSM server at 5.1.6.4. I read that there would be a move nodedata funtion startingat V5.1.5. It's there tsm: BASKEThelp move nodedata MOVE NODEDATA MOVE NODEDATA (Move Data by Node in a Sequential Access Storage Pool) Use this command to move data located in a sequential-access storage pool. snip (at least on aix it is...) -- Met vriendelijke groeten, Remco Post SARA - Stichting Academisch Rekencentrum Amsterdamhttp://www.sara.nl High Performance Computing Tel. +31 20 592 8008Fax. +31 20 668 3167 I really didn't foresee the Internet. But then, neither did the computer industry. Not that that tells us very much of course - the computer industry didn't even foresee that the century was going to end. -- Douglas Adams
move nodedata
What happened to the move Nodedata function? We're running on z/OS 1.2 TSM server at 5.1.6.4. I read that there would be a move nodedata funtion startingat V5.1.5.
Re: MOVE NODEDATA on a copypool doesn't process anything
On Mon, Jun 02, 2003 at 01:36:12PM +0100, Wilcox, Andy wrote: I found that you can't do a move nodedata against a copypool. You can, but you can't move files out of one copypool into another. This is documented. You have to move the data from the onsite pool to another onsite pool and copy this to a different copypool. The data in the old copypool is then inconveniently left around (although existing copy group expiration value will apply). You are describing a different phenomenon, but it would be nice if there were a way to address this. Even a DELETE NODEDATA would be handy. :-) Although... what would happen in the following scenario: - NODE_A is backed up to primary pool PRIM01. - PRIM01 gets backed up to COPY01. - The TSM admin does a MOVE NODEDATA NODE_A FROM=PRIM01 TO=PRIM02 - After that, PRIM02 gets backed up to COPY02. - All copypool-volumes are taken offsite - A disaster strikes and the DR procedure is started. - In a new TSM server, NODE_A is being restored directly from copypool-volumes. Which volumes will the server choose? This could be relevant, since COPY01 might be noncollocated while COPY02 is collocated. This can make a large difference during DR. -- Jurjen Oskam PGP Key available at http://www.stupendous.org/
Re: MOVE NODEDATA on a copypool doesn't process anything
From: Jurjen Oskam [mailto:[EMAIL PROTECTED] You are describing a different phenomenon, but it would be nice if there were a way to address this. Even a DELETE NODEDATA would be handy. :-) There is. It's called DELETE FILESPACE. :o) -- Mark Stapleton ([EMAIL PROTECTED]) Berbee Information Networks Office 262.521.5627
Re: MOVE NODEDATA on a copypool doesn't process anything
On Mon, Jun 02, 2003 at 11:16:44AM -0500, Stapleton, Mark wrote: You are describing a different phenomenon, but it would be nice if there were a way to address this. Even a DELETE NODEDATA would be handy. :-) There is. It's called DELETE FILESPACE. :o) Well, yes, but DELETE FILESPACE isn't able to delete things from only a certain storagepool, which would be the point of that fictional DELETE NODEDATA command. Although, granted, an option such as FROMSTG=storagepool to DELETE FILESPACE would work too. :-) -- Jurjen Oskam PGP Key available at http://www.stupendous.org/
Re: MOVE NODEDATA on a copypool doesn't process anything
Over two years ago I asked for the following enhancements: add the node= parameter to move data command add the stgpool= parameter to delete filespace command I still believe these would provide a great enhancement to storage management. Al Jurjen Oskam [EMAIL PROTECTED] Sent by: ADSM: Dist Stor Manager [EMAIL PROTECTED] 06/02/03 12:01 PM Please respond to ADSM: Dist Stor Manager To: [EMAIL PROTECTED] cc: Subject:Re: MOVE NODEDATA on a copypool doesn't process anything On Mon, Jun 02, 2003 at 11:16:44AM -0500, Stapleton, Mark wrote: You are describing a different phenomenon, but it would be nice if there were a way to address this. Even a DELETE NODEDATA would be handy. :-) There is. It's called DELETE FILESPACE. :o) Well, yes, but DELETE FILESPACE isn't able to delete things from only a certain storagepool, which would be the point of that fictional DELETE NODEDATA command. Although, granted, an option such as FROMSTG=storagepool to DELETE FILESPACE would work too. :-) -- Jurjen Oskam PGP Key available at http://www.stupendous.org/
Re: MOVE NODEDATA on a copypool doesn't process anything
-- ... from storage pool COPY01 to storage pool COPY01 ... TSM is smart enough. Try using TOstgpool=another copypool parameter of MOVe NODEdata command. Zlatko Krastev IT Consultant Jurjen Oskam [EMAIL PROTECTED] Sent by: ADSM: Dist Stor Manager [EMAIL PROTECTED] 19.05.2003 14:17 Please respond to ADSM: Dist Stor Manager To: [EMAIL PROTECTED] cc: Subject:MOVE NODEDATA on a copypool doesn't process anything Hi everybody, I have a non-collocated copy storage pool. I want to issue a MOVE NODEDATA for a filespace in that pool, to get that filespace on one tape. However, the MOVE NODEDATA command doesn't appear to do anything. tsm: SERVER1q occ triprod1 /oracle Node Name TypeFilespace FSIDStorage Number of Physical Logical Name Pool Name Files SpaceSpace Occupied Occupied (MB) (MB) -------- -- TRIPROD1 Bkup/oracle 3COPY01 70,126 6,810.71 6,641.33 TRIPROD1 Bkup/oracle 3DISK01 51 139.50 139.50 TRIPROD1 Bkup/oracle 3PRIM01 70,075 6,868.68 6,501.86 tsm: SERVER1move nodedata triprod1 from=copy01 filespace='/oracle' wait=yes ANR1648W MOVE NODEDATA:This command will move data for nodes stored in volumes in storage pool COPY01 to other volumes within the same storage pool; the data will be inaccessible to users until the operation completes. Do you wish to proceed? (Yes (Y)/No (N)) y ANR0984I Process 11 for MOVE NODE DATA started in the FOREGROUND at 13:12:29. ANR1284I Move node data started as process 11. ANR1288I Move node data process 11 ended for storage pool COPY01. ANR0985I Process 11 for MOVE NODE DATA running in the FOREGROUND completed with completion state SUCCESS at 13:12:29. ANR1290I Move node data from storage pool COPY01 to storage pool COPY01 has ended. Files Moved: 0, Bytes Moved: 0, Unreadable Files: 0, Unreadable Bytes: 0. The TSM server is at level 5.1.6.5 on AIX 4.3.3 ML10. It is interesting that this command also successfully returns if I specify an unexistant filespace. Does anybody know what I'm doing wrong? Thanks, -- Jurjen Oskam PGP Key available at http://www.stupendous.org/
Re: MOVE NODEDATA on a copypool doesn't process anything
On Sun, Jun 01, 2003 at 02:33:22PM +0300, Zlatko Krastev/ACIT wrote: -- ... from storage pool COPY01 to storage pool COPY01 ... TSM is smart enough. Try using TOstgpool=another copypool parameter of MOVe NODEdata command. This is not possible (emphasis mine): TOstgpool Specifies the name of a storage pool to which data will be moved. This storage pool must be in the NATIVE or NONBLOCK data format. **This parameter is optional and does not apply when the source storage pool is a copy storage pool.** That is, if the source storage pool is a copy storage pool the destination must be the same copy storage pool. If a value is not specified, data is moved to other volumes within the source pool. Note: If you are moving data within the same storage pool, there must be volumes available that do not contain the node data you are moving. That is, the server cannot use volumes that contain the data to be moved as destination volumes. If MOVE NODEDATA would work the same way as MOVE DATA does for an offsite volume beloning to a copypool (i.e.: retrieve the files from an onsite primary pool), this would provide for a very easy and cheap way to make sure that certain filespaces are quickly restored in a DR scenario. By way of the MOVE NODEDATA command, you would only need one or two volume mounts (in a noncollocated copypool) instead of many more when restoring during DR. Unfortunately, MOVE NODEDATA only works this way when the volumes that contain the data to be moved are onsite and available. This make MOVE NODEDATA almost useless in this scenario, since copypool volumes are offsite for a reason. :-) I opened a PMR with IBM support for this behaviour. Initially, I was told that this 'works as designed'. However, MOVE NODEDATA does things that are not right in my (very humble) opinion: * MOVE NODEDATA reports success, even when a non-existant filespace was specified. * If, for a random filespace, some copypool volumes are onsite and some are offsite, MOVE NODEDATA only moves the files in the filespace that are contained on the onsite part of the filespace. However, MOVE NODEDATA still reports success in this case, and no mention whatsoever is made that part of the filespace has not been moved at all (not even in the 'Failed files' counter of the summary). The only way you can tell is to check whether the summary of the MOVE NODEDATA reports a 'Moved Files' number equal to the amount of files in the entire filespace. This gets difficult if you're moving entire nodes. So I told this to IBM Support in response to their 'works as designed', and above issues are still being checked out. Thanks for your reply, -- Jurjen Oskam PGP Key available at http://www.stupendous.org/
Re: MOVE NODEDATA on a copypool doesn't process anything
I found that you can't do a move nodedata against a copypool. You have to move the data from the onsite pool to another onsite pool and copy this to a different copypool. The data in the old copypool is then inconveniently left around (although existing copy group expiration value will apply). Cheers Andy Wilcox Midrange Services Aquila Networks Services Ltd -Original Message- From: Zlatko Krastev/ACIT [SMTP:[EMAIL PROTECTED] Sent: 01 June 2003 12:33 To: [EMAIL PROTECTED] Subject: Re: MOVE NODEDATA on a copypool doesn't process anything -- ... from storage pool COPY01 to storage pool COPY01 ... TSM is smart enough. Try using TOstgpool=another copypool parameter of MOVe NODEdata command. Zlatko Krastev IT Consultant Jurjen Oskam [EMAIL PROTECTED] Sent by: ADSM: Dist Stor Manager [EMAIL PROTECTED] 19.05.2003 14:17 Please respond to ADSM: Dist Stor Manager To: [EMAIL PROTECTED] cc: Subject:MOVE NODEDATA on a copypool doesn't process anything Hi everybody, I have a non-collocated copy storage pool. I want to issue a MOVE NODEDATA for a filespace in that pool, to get that filespace on one tape. However, the MOVE NODEDATA command doesn't appear to do anything. tsm: SERVER1q occ triprod1 /oracle Node Name TypeFilespace FSIDStorage Number of Physical Logical Name Pool Name Files SpaceSpace Occupied Occupied (MB) (MB) -------- -- TRIPROD1 Bkup/oracle 3COPY01 70,126 6,810.71 6,641.33 TRIPROD1 Bkup/oracle 3DISK01 51 139.50 139.50 TRIPROD1 Bkup/oracle 3PRIM01 70,075 6,868.68 6,501.86 tsm: SERVER1move nodedata triprod1 from=copy01 filespace='/oracle' wait=yes ANR1648W MOVE NODEDATA:This command will move data for nodes stored in volumes in storage pool COPY01 to other volumes within the same storage pool; the data will be inaccessible to users until the operation completes. Do you wish to proceed? (Yes (Y)/No (N)) y ANR0984I Process 11 for MOVE NODE DATA started in the FOREGROUND at 13:12:29. ANR1284I Move node data started as process 11. ANR1288I Move node data process 11 ended for storage pool COPY01. ANR0985I Process 11 for MOVE NODE DATA running in the FOREGROUND completed with completion state SUCCESS at 13:12:29. ANR1290I Move node data from storage pool COPY01 to storage pool COPY01 has ended. Files Moved: 0, Bytes Moved: 0, Unreadable Files: 0, Unreadable Bytes: 0. The TSM server is at level 5.1.6.5 on AIX 4.3.3 ML10. It is interesting that this command also successfully returns if I specify an unexistant filespace. Does anybody know what I'm doing wrong? Thanks, -- Jurjen Oskam PGP Key available at http://www.stupendous.org/ ** ** Confidentiality: This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error, use of this information (including disclosure, copying or distribution) may be unlawful. Please notify [EMAIL PROTECTED] and delete the message immediately. Security: Internet e-mail is not a 100% secure communications medium. Viruses: This e-mail (and any attachments) has been checked (using Sophos Sweep 3.68 + patches) and found to be clean from any virus infection before leaving. Therefore neither Aquila Networks Services Ltd nor Midlands Electricity plc or any of their group undertakings (as defined by the Companies Act 1989) (together referred to as the Companies) accept legal responsibility for this message or liability for the consequences of any computer viruses which may have been transmitted by this e-mail. Monitoring: All electronic communications with the Companies may be monitored in accordance with the UK Regulation of Investigatory Powers Act, Lawful Business Practice Regulations, 2000. If you do not consent to such monitoring, you should contact the sender of this e-mail. Aquila Networks Services Limited, Registered office: Whittington Hall, Whittington, Worcester, WR5 2RB Registered in England and Wales number 3600545 This e-mail may be sent on behalf of any of the Companies. ** **
Re: Move nodedata
You need to isolate the data for that server/filespace in the copypool in order to delete ONLY that data. I've used this brute force method before: Turn colocation on for the copypool at client/filespace level as needed. find copypool volumes containing data for the client using: select volume_name from volumeusage where node_name='...client name...' and stgpool_name='...blah...' and filespace_name='..fs name as needed' MOVE DATA for each of these volumes (this should create a new set of tapes containing only the data for the specific node UPD vol ...blah... ACC=reado for output volumes from step 3 Turn off colocation on copypool Optionally, Q CON for each volume from step 3 to verify what's on each volume from step 3 DEL VOL DISCARDD=YES for each volume from step 3 If someone's got a better way, please let me know! Over a year ago I submitted these enhancement requests Add the NODENAME= parameter to the MOVE DATA command (we got a partial solution with the MOVE NODEDATA, but it only works for primary pools) Add the STGPOOL= parameter to the DELETE FILESPACE command (this would eliminate the steps above) By allowing MOVE NODEDATA to work with copypools and by providing the enhanced DELETE FILESPACE, we gain much needed ability to manage our backend storage. -- Al John Naylor [EMAIL PROTECTED] Sent by: ADSM: Dist Stor Manager [EMAIL PROTECTED] 02/05/03 04:51 AM Please respond to ADSM: Dist Stor Manager To: [EMAIL PROTECTED] cc: Subject:Re: Move nodedata Can't you just delete the volumes in the old copy storage pool ? That seems too easy, so I could be wrong Zlatko Krastev/ACIT [EMAIL PROTECTED] on 02/05/2003 06:15:11 AM Please respond to ADSM: Dist Stor Manager [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc:(bcc: John Naylor/HAV/SSE) Subject: Re: Move nodedata Bruce, your mistake is *by design*. You can move data (with both move data and move nodedata) between *primary* pools. Copypools *do not* contain node's data, they contain primary pools' data copies. To achieve the goal I would suggest you the following: 1. create new primary pool (if not done already) 2. create new policy domain, set its copygroups to point new primary pool and move the node into it 3. export the node's data, delete filespaces ... 4. ... and import it back (sorry I know it is time consuming and might look silly) 5. backup the primary pool to second copypool (C1_FS_DRMP) Now what am I proposing: - in step 3 the data will be deleted from both originating primary pool and the source copypool. This is the only way I know to clean up the copypool. - in step 4 the data will be imported back into the server but in new primary pool. - steps 3-4 result similar to move nodedata but with deletion from copypool - step 5 is explanatory by itself If you can afford the data to stay in old copypool until it expires on its own you can use move nodedata and backup stgpool to finish faster. If you insist to clean the old copypool and have copies only in primary pools and new copypool then you have to go down the export-import road. Zlatko Krastev IT Consultant Kamp, Bruce [EMAIL PROTECTED] Sent by: ADSM: Dist Stor Manager [EMAIL PROTECTED] 03.02.2003 14:03 Please respond to ADSM: Dist Stor Manager To: [EMAIL PROTECTED] cc: Subject:Move nodedata I need to move a couple of nodes from one offsite copy pool to another offsite copy pool. I tried using the move nodedata command but It gives me the following error: ANR1719E Storage pool C1_FS_DRMP specified on the MOVE NODEDATA command is not a valid pool name or pool type. ANS8001I Return code 3. This is the command I was using: move nodedata tsmserv from=drmpool to=C1_FS_DRMP TYPE=any From reading the help is it my understanding that I can not do this with the move nodedata? If not. Will this work? 1. Bind nodes to new management class. 2. Use move nodedata command to move onsite data to new storage pool. 3. Use backup stgpool from new onsite storage pool to new offsite copy storage pool. 4. This is the step I'm not sure about! How do I remove the data from the old offsite storage pool? Thanks, -- Bruce Kamp Midrange Systems Analyst II Memorial Healthcare System E: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] P: (954) 987-2020 x4597 F: (954) 985-1404 --- ** The information in this E-Mail is confidential and may be legally privileged. It may not represent the views of Scottish and Southern Energy plc. It is intended solely for the addressees. Access to this E-Mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any unauthorised recipient should advise the sender immediately of the error
Re: Move nodedata (removing a filespace from a copy pool)
Yes, but it is ugly. Move the filespace to a new primary pool temporarily, or permanently if you like. Create a new Copy storage pool and run a backup storage pool command of the original storage pool command. The delete the old copy storage pool (you have to delete all the volumes in that copy storage pool). Rename the new copy storage pool to the old copy storage pool if you like. Done. I would like move nodedata to work on copy storage pools, but the way the bitfile objects are architected this would be very difficult to provide. What we need is some functionality to setup permanent backup storage pool excludes and a delete filespace xxx copypool= The excludes prevent stuff we do not need copied from being copied to a copy pool. The delete allows us to get rid of what we do not want to keep. Paul D. Seay, Jr. Technical Specialist Northrop Grumman Information Technology 757-688-8180 -Original Message- From: Kamp, Bruce [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 04, 2003 2:11 PM To: [EMAIL PROTECTED] Subject: Re: Move nodedata Is there anyway to delete a file space from a copy storage pool without deleting it from all storage pools? -- Bruce Kamp Midrange Systems Analyst II Memorial Healthcare System E: [EMAIL PROTECTED] P: (954) 987-2020 x4597 F: (954) 985-1404 --- -Original Message- From: Daniel Sparrman [mailto:[EMAIL PROTECTED]] Sent: Monday, February 03, 2003 7:34 AM To: [EMAIL PROTECTED] Subject: Re: Move nodedata Or, you can simply do a new backup stgpool, to your new copy storagepool. Best Regards Daniel Sparrman --- Daniel Sparrman Exist i Stockholm AB Propellervägen 6B 183 62 HÄGERNÄS Växel: 08 - 754 98 00 Mobil: 070 - 399 27 51 Kamp, Bruce [EMAIL PROTECTED] Sent by: ADSM: Dist Stor Manager [EMAIL PROTECTED] 2003-02-03 13:03 Please respond to ADSM: Dist Stor Manager To: [EMAIL PROTECTED] cc: Subject:Move nodedata I need to move a couple of nodes from one offsite copy pool to another offsite copy pool. I tried using the move nodedata command but It gives me the following error: ANR1719E Storage pool C1_FS_DRMP specified on the MOVE NODEDATA command is not a valid pool name or pool type. ANS8001I Return code 3. This is the command I was using: move nodedata tsmserv from=drmpool to=C1_FS_DRMP TYPE=any From reading the help is it my understanding that I can not do this with the move nodedata? If not. Will this work? 1. Bind nodes to new management class. 2. Use move nodedata command to move onsite data to new storage pool. 3. Use backup stgpool from new onsite storage pool to new offsite copy storage pool. 4. This is the step I'm not sure about! How do I remove the data from the old offsite storage pool? Thanks, -- Bruce Kamp Midrange Systems Analyst II Memorial Healthcare System E: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] P: (954) 987-2020 x4597 F: (954) 985-1404 ---
Re: Move nodedata
Bruce, your mistake is *by design*. You can move data (with both move data and move nodedata) between *primary* pools. Copypools *do not* contain node's data, they contain primary pools' data copies. To achieve the goal I would suggest you the following: 1. create new primary pool (if not done already) 2. create new policy domain, set its copygroups to point new primary pool and move the node into it 3. export the node's data, delete filespaces ... 4. ... and import it back (sorry I know it is time consuming and might look silly) 5. backup the primary pool to second copypool (C1_FS_DRMP) Now what am I proposing: - in step 3 the data will be deleted from both originating primary pool and the source copypool. This is the only way I know to clean up the copypool. - in step 4 the data will be imported back into the server but in new primary pool. - steps 3-4 result similar to move nodedata but with deletion from copypool - step 5 is explanatory by itself If you can afford the data to stay in old copypool until it expires on its own you can use move nodedata and backup stgpool to finish faster. If you insist to clean the old copypool and have copies only in primary pools and new copypool then you have to go down the export-import road. Zlatko Krastev IT Consultant Kamp, Bruce [EMAIL PROTECTED] Sent by: ADSM: Dist Stor Manager [EMAIL PROTECTED] 03.02.2003 14:03 Please respond to ADSM: Dist Stor Manager To: [EMAIL PROTECTED] cc: Subject:Move nodedata I need to move a couple of nodes from one offsite copy pool to another offsite copy pool. I tried using the move nodedata command but It gives me the following error: ANR1719E Storage pool C1_FS_DRMP specified on the MOVE NODEDATA command is not a valid pool name or pool type. ANS8001I Return code 3. This is the command I was using: move nodedata tsmserv from=drmpool to=C1_FS_DRMP TYPE=any From reading the help is it my understanding that I can not do this with the move nodedata? If not. Will this work? 1. Bind nodes to new management class. 2. Use move nodedata command to move onsite data to new storage pool. 3. Use backup stgpool from new onsite storage pool to new offsite copy storage pool. 4. This is the step I'm not sure about! How do I remove the data from the old offsite storage pool? Thanks, -- Bruce Kamp Midrange Systems Analyst II Memorial Healthcare System E: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] P: (954) 987-2020 x4597 F: (954) 985-1404 ---
Re: Move nodedata
Is there anyway to delete a file space from a copy storage pool without deleting it from all storage pools? -- Bruce Kamp Midrange Systems Analyst II Memorial Healthcare System E: [EMAIL PROTECTED] P: (954) 987-2020 x4597 F: (954) 985-1404 --- -Original Message- From: Daniel Sparrman [mailto:[EMAIL PROTECTED]] Sent: Monday, February 03, 2003 7:34 AM To: [EMAIL PROTECTED] Subject: Re: Move nodedata Or, you can simply do a new backup stgpool, to your new copy storagepool. Best Regards Daniel Sparrman --- Daniel Sparrman Exist i Stockholm AB Propellervägen 6B 183 62 HÄGERNÄS Växel: 08 - 754 98 00 Mobil: 070 - 399 27 51 Kamp, Bruce [EMAIL PROTECTED] Sent by: ADSM: Dist Stor Manager [EMAIL PROTECTED] 2003-02-03 13:03 Please respond to ADSM: Dist Stor Manager To: [EMAIL PROTECTED] cc: Subject:Move nodedata I need to move a couple of nodes from one offsite copy pool to another offsite copy pool. I tried using the move nodedata command but It gives me the following error: ANR1719E Storage pool C1_FS_DRMP specified on the MOVE NODEDATA command is not a valid pool name or pool type. ANS8001I Return code 3. This is the command I was using: move nodedata tsmserv from=drmpool to=C1_FS_DRMP TYPE=any From reading the help is it my understanding that I can not do this with the move nodedata? If not. Will this work? 1. Bind nodes to new management class. 2. Use move nodedata command to move onsite data to new storage pool. 3. Use backup stgpool from new onsite storage pool to new offsite copy storage pool. 4. This is the step I'm not sure about! How do I remove the data from the old offsite storage pool? Thanks, -- Bruce Kamp Midrange Systems Analyst II Memorial Healthcare System E: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] P: (954) 987-2020 x4597 F: (954) 985-1404 ---
Move nodedata
I need to move a couple of nodes from one offsite copy pool to another offsite copy pool. I tried using the move nodedata command but It gives me the following error: ANR1719E Storage pool C1_FS_DRMP specified on the MOVE NODEDATA command is not a valid pool name or pool type. ANS8001I Return code 3. This is the command I was using: move nodedata tsmserv from=drmpool to=C1_FS_DRMP TYPE=any From reading the help is it my understanding that I can not do this with the move nodedata? If not. Will this work? 1. Bind nodes to new management class. 2. Use move nodedata command to move onsite data to new storage pool. 3. Use backup stgpool from new onsite storage pool to new offsite copy storage pool. 4. This is the step I'm not sure about! How do I remove the data from the old offsite storage pool? Thanks, -- Bruce Kamp Midrange Systems Analyst II Memorial Healthcare System E: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] P: (954) 987-2020 x4597 F: (954) 985-1404 ---
Re: Move nodedata
Or, you can simply do a new backup stgpool, to your new copy storagepool. Best Regards Daniel Sparrman --- Daniel Sparrman Exist i Stockholm AB Propellervägen 6B 183 62 HÄGERNÄS Växel: 08 - 754 98 00 Mobil: 070 - 399 27 51 Kamp, Bruce [EMAIL PROTECTED] Sent by: ADSM: Dist Stor Manager [EMAIL PROTECTED] 2003-02-03 13:03 Please respond to ADSM: Dist Stor Manager To: [EMAIL PROTECTED] cc: Subject:Move nodedata I need to move a couple of nodes from one offsite copy pool to another offsite copy pool. I tried using the move nodedata command but It gives me the following error: ANR1719E Storage pool C1_FS_DRMP specified on the MOVE NODEDATA command is not a valid pool name or pool type. ANS8001I Return code 3. This is the command I was using: move nodedata tsmserv from=drmpool to=C1_FS_DRMP TYPE=any From reading the help is it my understanding that I can not do this with the move nodedata? If not. Will this work? 1. Bind nodes to new management class. 2. Use move nodedata command to move onsite data to new storage pool. 3. Use backup stgpool from new onsite storage pool to new offsite copy storage pool. 4. This is the step I'm not sure about! How do I remove the data from the old offsite storage pool? Thanks, -- Bruce Kamp Midrange Systems Analyst II Memorial Healthcare System E: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] P: (954) 987-2020 x4597 F: (954) 985-1404 ---
Re: Move nodedata
What will happen to the data in the old copy storage pool? -- Bruce Kamp Midrange Systems Analyst II Memorial Healthcare System E: [EMAIL PROTECTED] P: (954) 987-2020 x4597 F: (954) 985-1404 --- -Original Message- From: Daniel Sparrman [mailto:[EMAIL PROTECTED]] Sent: Monday, February 03, 2003 7:34 AM To: [EMAIL PROTECTED] Subject: Re: Move nodedata Or, you can simply do a new backup stgpool, to your new copy storagepool. Best Regards Daniel Sparrman --- Daniel Sparrman Exist i Stockholm AB Propellervägen 6B 183 62 HÄGERNÄS Växel: 08 - 754 98 00 Mobil: 070 - 399 27 51 Kamp, Bruce [EMAIL PROTECTED] Sent by: ADSM: Dist Stor Manager [EMAIL PROTECTED] 2003-02-03 13:03 Please respond to ADSM: Dist Stor Manager To: [EMAIL PROTECTED] cc: Subject:Move nodedata I need to move a couple of nodes from one offsite copy pool to another offsite copy pool. I tried using the move nodedata command but It gives me the following error: ANR1719E Storage pool C1_FS_DRMP specified on the MOVE NODEDATA command is not a valid pool name or pool type. ANS8001I Return code 3. This is the command I was using: move nodedata tsmserv from=drmpool to=C1_FS_DRMP TYPE=any From reading the help is it my understanding that I can not do this with the move nodedata? If not. Will this work? 1. Bind nodes to new management class. 2. Use move nodedata command to move onsite data to new storage pool. 3. Use backup stgpool from new onsite storage pool to new offsite copy storage pool. 4. This is the step I'm not sure about! How do I remove the data from the old offsite storage pool? Thanks, -- Bruce Kamp Midrange Systems Analyst II Memorial Healthcare System E: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] P: (954) 987-2020 x4597 F: (954) 985-1404 ---
