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" <andy.wilcox AT AQUILA-NETWORKS.CO DOT UK>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
03.09.2003 10:42
Please respond to "ADSM: Dist Stor Manager"
To: ADSM-L AT VM.MARIST DOT EDU
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:acit AT ATTGLOBAL DOT NET]
> Sent: 02 September 2003 18:07
> To: ADSM-L AT VM.MARIST DOT EDU
> 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" <andy.wilcox AT AQUILA-NETWORKS.CO DOT UK>
> Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
> 02.09.2003 14:21
> Please respond to "ADSM: Dist Stor Manager"
>
>
> To: ADSM-L AT VM.MARIST DOT EDU
> 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:shwl AT STATOIL DOT COM]
> > Sent: 02 September 2003 09:51
> > To: ADSM-L AT VM.MARIST DOT EDU
> > 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-W03>h 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 postmaster AT aquila-networks.co DOT uk. 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.
> >
>
**************************************************************************
> > **************************
|
