ADSM-L

Re: [ADSM-L] move nodedata functionality

2008-04-30 16:02:42
Subject: Re: [ADSM-L] move nodedata functionality
From: Howard Coles <Howard.Coles AT ARDENTHEALTH DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 30 Apr 2008 15:01:16 -0500
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:ADSM-L AT VM.MARIST DOT EDU] On Behalf
> Of Nicholas Rodolfich
> Sent: Wednesday, April 30, 2008 2:43 PM
> To: ADSM-L AT VM.MARIST DOT 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.
> 
> >>> deehre01 AT LOUISVILLE DOT EDU 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 <nrodolfich AT EJGH DOT ORG> 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.

<Prev in Thread] Current Thread [Next in Thread>