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. ** **
