Re: Hey Big Blue....Why not MOVE DATA across copy pools?!?
Hi Bill,
As you might expect I avoid shooting myself in the footbut
compost happens. :)
Any number of commands if not used properly could destroy
integrity of backups, none the less they are still usefull to have.
Generally speaking, I try not to think of auditorsIt is
similar to the anticipation one feels prior to an enema. :)
My primary pool is 40TB...backing it up to a new copypool would
present a number of problems for me.
Dave Nicholson
Whirlpool Corporation
"William F. Colwell" <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
06/10/2004 06:01 PM
Please respond to "ADSM: Dist Stor Manager"
To: [EMAIL PROTECTED]
cc:
Subject: Re: Hey Big BlueWhy not MOVE DATA across copy pools?!?
At 07:56 AM 6/10/2004, you wrote:
>I already performed the move data from the primary pool to another
primary
>pool. I guess TSM cant figure out that the primary copies are in a
>different primary storage pool than where they were origianlly backed up
>from.
>
>A "DELETE FILES node filespace STG=stgpool" sure would be niceor a
>"DELETE NODEDATA STG=stgpool". (sigh)
No! It would not be nice - unless you like shooting yourself in the foot.
Anything that lets you alter a backup destroys the integrity of the
backup.
Think of your auditors - if they understood how good tsm is, this command
would destroy all their confidence.
If you have gone to the trouble of collocating the primary pool with move
nodedata
commands, you can collocate the offsite pool by defining a new copypool
and backing up to
it. After the new pool is all offsite, delete the volumes in the old
copypool with 'discarddata=yes'.
I really hope this helps,
Bill Colwell
>Dave Nicholson
>Whirlpool Corporation
>
>
>
>
>
>"Stapleton, Mark" <[EMAIL PROTECTED]>
>Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
>06/09/2004 10:44 PM
>Please respond to "ADSM: Dist Stor Manager"
>
>
>To: [EMAIL PROTECTED]
>cc:
>Subject:Re: Hey Big BlueWhy not MOVE DATA across copy
pools?!?
>
>
>From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On
>Behalf Of David Nicholson
>>I tried a MOVE DATA for offsite data...it did not go after the
>>data in the primary pool...it wanted to mount the volume in the copy
>>pool...which was offsite.
>>Am I missing something?
>
>Something is wrong. MOVE DATA will only call for offsite volumes if the
>required files are not available in the primary pool. Do you have
>volumes in unavailable status?
>
>--
>Mark Stapleton
--
Bill Colwell
C. S. Draper Lab
Cambridge Ma.
Re: Hey Big Blue....Why not MOVE DATA across copy pools?!?
At 07:56 AM 6/10/2004, you wrote: >I already performed the move data from the primary pool to another primary >pool. I guess TSM cant figure out that the primary copies are in a >different primary storage pool than where they were origianlly backed up >from. > >A "DELETE FILES node filespace STG=stgpool" sure would be niceor a >"DELETE NODEDATA STG=stgpool". (sigh) No! It would not be nice - unless you like shooting yourself in the foot. Anything that lets you alter a backup destroys the integrity of the backup. Think of your auditors - if they understood how good tsm is, this command would destroy all their confidence. If you have gone to the trouble of collocating the primary pool with move nodedata commands, you can collocate the offsite pool by defining a new copypool and backing up to it. After the new pool is all offsite, delete the volumes in the old copypool with 'discarddata=yes'. I really hope this helps, Bill Colwell >Dave Nicholson >Whirlpool Corporation > > > > > >"Stapleton, Mark" <[EMAIL PROTECTED]> >Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> >06/09/2004 10:44 PM >Please respond to "ADSM: Dist Stor Manager" > > >To: [EMAIL PROTECTED] >cc: >Subject:Re: Hey Big BlueWhy not MOVE DATA across copy pools?!? > > >From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On >Behalf Of David Nicholson >>I tried a MOVE DATA for offsite data...it did not go after the >>data in the primary pool...it wanted to mount the volume in the copy >>pool...which was offsite. >>Am I missing something? > >Something is wrong. MOVE DATA will only call for offsite volumes if the >required files are not available in the primary pool. Do you have >volumes in unavailable status? > >-- >Mark Stapleton -- Bill Colwell C. S. Draper Lab Cambridge Ma.
Re: Hey Big Blue....Why not MOVE DATA across copy pools?!?
Have you changed the access mode for the volumes to offsite?
Jim
At 07:56 AM 6/10/2004 -0400, you wrote:
I already performed the move data from the primary pool to another primary
pool. I guess TSM cant figure out that the primary copies are in a
different primary storage pool than where they were origianlly backed up
from.
A "DELETE FILES node filespace STG=stgpool" sure would be niceor a
"DELETE NODEDATA STG=stgpool". (sigh)
Dave Nicholson
Whirlpool Corporation
"Stapleton, Mark" <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
06/09/2004 10:44 PM
Please respond to "ADSM: Dist Stor Manager"
To: [EMAIL PROTECTED]
cc:
Subject: Re: Hey Big BlueWhy not MOVE DATA across copy
pools?!?
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On
Behalf Of David Nicholson
>I tried a MOVE DATA for offsite data...it did not go after the
>data in the primary pool...it wanted to mount the volume in the copy
>pool...which was offsite.
>Am I missing something?
Something is wrong. MOVE DATA will only call for offsite volumes if the
required files are not available in the primary pool. Do you have
volumes in unavailable status?
--
Mark Stapleton
Re: Hey Big Blue....Why not MOVE DATA across copy pools?!?
I already performed the move data from the primary pool to another primary
pool. I guess TSM cant figure out that the primary copies are in a
different primary storage pool than where they were origianlly backed up
from.
A "DELETE FILES node filespace STG=stgpool" sure would be niceor a
"DELETE NODEDATA STG=stgpool". (sigh)
Dave Nicholson
Whirlpool Corporation
"Stapleton, Mark" <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
06/09/2004 10:44 PM
Please respond to "ADSM: Dist Stor Manager"
To: [EMAIL PROTECTED]
cc:
Subject: Re: Hey Big BlueWhy not MOVE DATA across copy pools?!?
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On
Behalf Of David Nicholson
>I tried a MOVE DATA for offsite data...it did not go after the
>data in the primary pool...it wanted to mount the volume in the copy
>pool...which was offsite.
>Am I missing something?
Something is wrong. MOVE DATA will only call for offsite volumes if the
required files are not available in the primary pool. Do you have
volumes in unavailable status?
--
Mark Stapleton
Re: Hey Big Blue....Why not MOVE DATA across copy pools?!?
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of David Nicholson >I tried a MOVE DATA for offsite data...it did not go after the >data in the primary pool...it wanted to mount the volume in the copy >pool...which was offsite. >Am I missing something? Something is wrong. MOVE DATA will only call for offsite volumes if the required files are not available in the primary pool. Do you have volumes in unavailable status? -- Mark Stapleton
Re: Hey Big Blue....Why not MOVE DATA across copy pools?!?
We do this all of the time - it works for us! And the help for move data says it works this way. We are currently running 5.2.2.4 but were previously at 5.1.6.4 and it worked there also. It is basically the same way offsite reclamation works. >From the help: "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." Tim Rushforth City of Winnipeg -Original Message- From: David Nicholson [mailto:[EMAIL PROTECTED] Sent: June 9, 2004 3:06 PM To: [EMAIL PROTECTED] Subject: Re: Hey Big Blue....Why not MOVE DATA across copy pools?!? Tim, I tried a MOVE DATA for offsite data...it did not go after the data in the primary pool...it wanted to mount the volume in the copy pool...which was offsite. Am I missing something? Dave Nicholson Whirlpool Corporation
Re: Hey Big Blue....Why not MOVE DATA across copy pools?!?
Tim,
I tried a MOVE DATA for offsite data...it did not go after the
data in the primary pool...it wanted to mount the volume in the copy
pool...which was offsite.
Am I missing something?
Dave Nicholson
Whirlpool Corporation
"Rushforth, Tim" <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
06/09/2004 03:43 PM
Please respond to "ADSM: Dist Stor Manager"
To: [EMAIL PROTECTED]
cc:
Subject: Re: Hey Big BlueWhy not MOVE DATA across copy pools?!?
Yeah you would think this is easy unless I'm missing something ...
MOVE DATA "works properly" for offsite data - ie if you issue a move data
for a volume that is offsite, it will move the data to another volume in
the
same copy pool using the primary storage pool as input.
Why does MOVE NODEDATA work differently? It is doing the same thing -
only
selectively moving data.
-Original Message-
From: Jurjen Oskam [mailto:[EMAIL PROTECTED]
Sent: June 9, 2004 2:30 PM
To: [EMAIL PROTECTED]
Subject: Re: Hey Big BlueWhy not MOVE DATA across copy pools?!?
On Wed, Jun 09, 2004 at 12:10:32PM -0500, Stapleton, Mark wrote:
> I used to think the same thing, but it occurred to me that, while there
> is a one-to-one correspondence between a file in an copy pool and the
> copy of the file in a primary pool, there is not necessarily a
> one-to-one relationship in the other direction.
Especially with MOVE NODEDATA used to move data from one primary pool to
another, where the first primary pool is backed up to COPY01 and the
second primary pool is backed up to COPY02. The data in COPY01 is now
(sort of) 'orphaned', and cannot be removed. (Not easily, at least)
Maybe a DELETE NODEDATA would be nice. (However, a MOVE NODEDATA that
would work on offsite volumes would be *much* nicer. That way, you can
once in a while 'collocate' all files of a node manually, and greatly
speed up a DR when all you got is the copypool.)
> The more I look into this, the more I am inclined to never use more than
> one copy pool for any given TSM server.
Especially so with a MOVE NODEDATA that would work on offsite volumes.
--
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: Hey Big Blue....Why not MOVE DATA across copy pools?!?
That is a good question. We just did the same thing, and I was thinking there should be a better way to do it. On Wed, 9 Jun 2004, David Nicholson wrote: > As luck would have it, the nodes I moved were large file servers and my > copy pool is not collocated. I probably have data spread across 600 > volumes. I think I'll pass on bringing them back > > This is by no means a "new" frustration for many folks. Any idea why old > big blue hasn't tried to add this functionality? The process of migrating > data to new media is severely handicapped by the lack of flexibility to > MOVE DATA across copy pools. > > Dave Nicholson > Whirlpool Corporation > > > > > > "Stapleton, Mark" <[EMAIL PROTECTED]> > Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> > 06/09/2004 12:19 PM > Please respond to "ADSM: Dist Stor Manager" > > > To: [EMAIL PROTECTED] > cc: > Subject:Re: Primary Pool and Copypool Relationship > > > If you want to pursue this, you'll have to run a select statement > against the VOLUMEUSAGE to find the relevant offsite pool volumes. Check > in the volumes from the resultant list, and run your MOVE NODEDATA. > > -- > Mark Stapleton > > >-Original Message- > >From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On > >Behalf Of Rushforth, Tim > >Sent: Wednesday, June 09, 2004 9:39 AM > >To: [EMAIL PROTECTED] > >Subject: Re: Primary Pool and Copypool Relationship > > > >OK, #1 below wouldn't work either without bringing offsite tapes back! > > > >>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 > > > >-Original Message- > >From: Rushforth, Tim > >Sent: June 7, 2004 3:05 PM > >To: 'ADSM: Dist Stor Manager' > >Subject: RE: Primary Pool and Copypool Relationship > > > >Ooops forgot about that restriction. To do this without bringing back > >offsite tapes or deleting all copy pool data for some nodes > >temporarily: > > > >1. Move nodedata from Copy Pool #1 to Copy Pool #1 (to new > >volumes) for the > >nodes you want to move. > >2. Move nodedata Primary Pool #1 to Primary Pool #2 > >3. Backup primary pool #2 to Copy Pool #2 > >4. Delete the new volumes from 1. > > > > > >-Original Message- > >From: Stapleton, Mark [mailto:[EMAIL PROTECTED] > >Sent: June 7, 2004 2:54 PM > >To: [EMAIL PROTECTED] > >Subject: Re: Primary Pool and Copypool Relationship > > > >From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On > >Behalf Of > >Rushforth, Tim > >>I guess the proper sequence should have been: > >> > >>1. Move nodedata from Copy Pool #1 to Copy Pool #2 (this way TSM will > >use > >>the data on Primary Pool #1 as the source data) > >>2. Move nodedata from Primary Pool #1 to Primary Pool #2 > > > >Unfortunately, step #1 is not possible. MOVE NODEDATA supports data > >moves within a single copy pool, but not between two copy pools. > > > >-- > >Mark Stapleton > > > > > >
Re: Hey Big Blue....Why not MOVE DATA across copy pools?!?
Yeah you would think this is easy unless I'm missing something ... MOVE DATA "works properly" for offsite data - ie if you issue a move data for a volume that is offsite, it will move the data to another volume in the same copy pool using the primary storage pool as input. Why does MOVE NODEDATA work differently? It is doing the same thing - only selectively moving data. -Original Message- From: Jurjen Oskam [mailto:[EMAIL PROTECTED] Sent: June 9, 2004 2:30 PM To: [EMAIL PROTECTED] Subject: Re: Hey Big Blue....Why not MOVE DATA across copy pools?!? On Wed, Jun 09, 2004 at 12:10:32PM -0500, Stapleton, Mark wrote: > I used to think the same thing, but it occurred to me that, while there > is a one-to-one correspondence between a file in an copy pool and the > copy of the file in a primary pool, there is not necessarily a > one-to-one relationship in the other direction. Especially with MOVE NODEDATA used to move data from one primary pool to another, where the first primary pool is backed up to COPY01 and the second primary pool is backed up to COPY02. The data in COPY01 is now (sort of) 'orphaned', and cannot be removed. (Not easily, at least) Maybe a DELETE NODEDATA would be nice. (However, a MOVE NODEDATA that would work on offsite volumes would be *much* nicer. That way, you can once in a while 'collocate' all files of a node manually, and greatly speed up a DR when all you got is the copypool.) > The more I look into this, the more I am inclined to never use more than > one copy pool for any given TSM server. Especially so with a MOVE NODEDATA that would work on offsite volumes. -- 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: Hey Big Blue....Why not MOVE DATA across copy pools?!?
On Wed, Jun 09, 2004 at 12:10:32PM -0500, Stapleton, Mark wrote: > I used to think the same thing, but it occurred to me that, while there > is a one-to-one correspondence between a file in an copy pool and the > copy of the file in a primary pool, there is not necessarily a > one-to-one relationship in the other direction. Especially with MOVE NODEDATA used to move data from one primary pool to another, where the first primary pool is backed up to COPY01 and the second primary pool is backed up to COPY02. The data in COPY01 is now (sort of) 'orphaned', and cannot be removed. (Not easily, at least) Maybe a DELETE NODEDATA would be nice. (However, a MOVE NODEDATA that would work on offsite volumes would be *much* nicer. That way, you can once in a while 'collocate' all files of a node manually, and greatly speed up a DR when all you got is the copypool.) > The more I look into this, the more I am inclined to never use more than > one copy pool for any given TSM server. Especially so with a MOVE NODEDATA that would work on offsite volumes. -- 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: Hey Big Blue....Why not MOVE DATA across copy pools?!?
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of David Nicholson >As luck would have it, the nodes I moved were large file servers and my >copy pool is not collocated. I probably have data spread across 600 >volumes. I think I'll pass on bringing them back > >This is by no means a "new" frustration for many folks. Any >idea why old >big blue hasn't tried to add this functionality? The process >of migrating >data to new media is severely handicapped by the lack of flexibility to >MOVE DATA across copy pools. I used to think the same thing, but it occurred to me that, while there is a one-to-one correspondence between a file in an copy pool and the copy of the file in a primary pool, there is not necessarily a one-to-one relationship in the other direction. You can run BACKUP STGPOOL from a primary pool to any number of copy pools. Allowing a MOVE NODEDATA among multiple copy pools might prove to be problematic, in that a relationship in the TSM database is built between a backed-up file in a primary pool and its copy in a copy pool; this relationship allows commands such as RESTORE VOLUME to work. It could be that maintaining that relationship is problematic if you moved a file from one copy pool to another, since not all copy pools carry files from all primary pools. The more I look into this, the more I am inclined to never use more than one copy pool for any given TSM server. -- Mark Stapleton
Hey Big Blue....Why not MOVE DATA across copy pools?!?
As luck would have it, the nodes I moved were large file servers and my copy pool is not collocated. I probably have data spread across 600 volumes. I think I'll pass on bringing them back This is by no means a "new" frustration for many folks. Any idea why old big blue hasn't tried to add this functionality? The process of migrating data to new media is severely handicapped by the lack of flexibility to MOVE DATA across copy pools. Dave Nicholson Whirlpool Corporation "Stapleton, Mark" <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> 06/09/2004 12:19 PM Please respond to "ADSM: Dist Stor Manager" To: [EMAIL PROTECTED] cc: Subject:Re: Primary Pool and Copypool Relationship If you want to pursue this, you'll have to run a select statement against the VOLUMEUSAGE to find the relevant offsite pool volumes. Check in the volumes from the resultant list, and run your MOVE NODEDATA. -- Mark Stapleton >-Original Message- >From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On >Behalf Of Rushforth, Tim >Sent: Wednesday, June 09, 2004 9:39 AM >To: [EMAIL PROTECTED] >Subject: Re: Primary Pool and Copypool Relationship > >OK, #1 below wouldn't work either without bringing offsite tapes back! > >>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 > >-Original Message- >From: Rushforth, Tim >Sent: June 7, 2004 3:05 PM >To: 'ADSM: Dist Stor Manager' >Subject: RE: Primary Pool and Copypool Relationship > >Ooops forgot about that restriction. To do this without bringing back >offsite tapes or deleting all copy pool data for some nodes >temporarily: > >1. Move nodedata from Copy Pool #1 to Copy Pool #1 (to new >volumes) for the >nodes you want to move. >2. Move nodedata Primary Pool #1 to Primary Pool #2 >3. Backup primary pool #2 to Copy Pool #2 >4. Delete the new volumes from 1. > > >-Original Message- >From: Stapleton, Mark [mailto:[EMAIL PROTECTED] >Sent: June 7, 2004 2:54 PM >To: [EMAIL PROTECTED] >Subject: Re: Primary Pool and Copypool Relationship > >From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On >Behalf Of >Rushforth, Tim >>I guess the proper sequence should have been: >> >>1. Move nodedata from Copy Pool #1 to Copy Pool #2 (this way TSM will >use >>the data on Primary Pool #1 as the source data) >>2. Move nodedata from Primary Pool #1 to Primary Pool #2 > >Unfortunately, step #1 is not possible. MOVE NODEDATA supports data >moves within a single copy pool, but not between two copy pools. > >-- >Mark Stapleton > >
