T.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 sto
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
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 FROMSTGPO
listing of CopyPool media that is
required to
perform the restore?
On Mon, Apr 2, 2012 at 10:03 AM, Shaffer, Gene wrote:
> Hi George;
>
> The short story - 'move data' to get files off a specific tape volume
> 'move nodedata' to conso
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
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 nodeda
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 operati
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 dat
8-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" 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
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 collocatio
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
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
er 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] mo
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.
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 stgpoo
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
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
wi
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.
aniel Davis <[EMAIL PROTECTED]>
To: "ADSM: Dist Stor Manager"
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 wou
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:
D
T.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
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 da
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 befor
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
re 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
&g
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
"ADSM: Dist Stor Manager" 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
>
: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$ fs
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
an
>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
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
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
==> 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 p
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
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
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
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
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
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
An: [EMAIL PROTECTED]
Kopie:
Thema: Re: Move Nodedata starts and
ends without doing anything
M - 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
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 NODEDA
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
/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 prima
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&#
>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 pro
>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 refer
Don't think you can do a move nodedata for a copy pool. Must be done on a primary
pool.
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
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?
;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
>But nothing moved. What is wrong?
The tapes are offsite and thus the data can't be moved?
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
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
nager" <[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
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
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
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
>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) h
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
>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 restor
|
|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 DIR
---
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
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 ha
stedt [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
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 OrigCop
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,node
D]>
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 i
essage-
> 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
T 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 node
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
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 schedu
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: BASKE
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.
"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
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 FILESP
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 Informatio
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 anot
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
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= parameter of
> MOVe NODEdata command.
This is not possible (emphasis mine):
TOstgpool
Specifie
--> ... from storage pool COPY01 to storage pool COPY01 ...
TSM is smart enough. Try using TOstgpool= parameter of
MOVe NODEdata command.
Zlatko Krastev
IT Consultant
Jurjen Oskam <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
19.05.200
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 NODEDAT
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
---
-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
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. c
-
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
AIL 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 p
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
89 matches
Mail list logo
