Hi Paul,
Thanks a lot for appreciated feedback !
I discussed this with some consultant in between time, who is not the same mind
than IBM support : this might be working "as designed" , but in this case, the
design is clearly flawed !
I might admit that the deletion on replication server would not be immediate,
due to some settings like the "Delay Period for Container Reuse" one, but the
fact that deletion does not take place at all is definitely wrong to my eyes.
Regarding your kind offer for scripts to help in such a situation : thanks a
lot, but fortunately such "forced" deletion of file spaces in TSM is not very
common in our shop, and I do believe that, despite my old age, I still will be
able to type an additional "del fi" command on the replication server when
needed ;-)
Cheers.
Arnaud
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Paul van Dongen
Sent: Tuesday, July 04, 2017 9:20 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Delete filespace operation not replicated ?
Hi Arnaud,
I posted a similar question a few months ago. Got no answers from the list, but
after opening a PMR I got the "works as designed" answer.
Since we use a script to delete filespaces in our environment (to check last
backup dates, customer IDs, etc.) we inserted some extra code to check if the
node is involved in replication, and, if so, check which server is the
replication partner in order to delete the correct filespace on the "target"
server.
Please send me a private message if you need more details.
Kind regards/Met vriendelijke groet,
Paul van Dongen
System Expert
T: +31 (0)20 560 6600 | M: +31 (0)6 41 81 44 46 | E: Paul.vanDongen AT
vancis DOT nl
Science Park 402 | 1098 XH Amsterdam | www.vancis.nl
Dit e-mailbericht is slechts bestemd voor de persoon of entiteit aan wie het is
gericht en kan informatie bevatten die persoonlijk of vertrouwelijk is en niet
openbaar mag worden gemaakt krachtens wet of overeenkomst. Indien de ontvanger
van dit bericht niet de bedoelde persoon of entiteit is, wordt hierbij vermeld
dat verdere verspreiding, openbaarmaking of vermenigvuldiging van dit bericht
strikt verboden is. Indien u dit bericht per vergissing heeft ontvangen,
verzoeken wij u om dit bericht terug te sturen naar de afzender en het
originele bericht te verwijderen zonder het eerst te vermenigvuldigen of te
publiceren. Dank voor uw medewerking.
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
PAC Brion Arnaud
Sent: dinsdag 20 juni 2017 12:46
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [ADSM-L] Delete filespace operation not replicated ?
Hi all,
A question regarding replicated data , and how a deleted filespace should be
treated by the process ...
First of all, the environment : two TSM servers 7.1.7.2, making use only of
directory pools and configured to perform cross replication (A replicates to B,
and B replicates to A).
I have the situation where I recently deleted a filespace from a node on its
primary server.
Since this deletion, following processes took place on the primary server :
protect stgpool, as well as replicate node and expire inventory.
However, I can still see the deleted filespace on the replication server for
the involved replicated node.
Is this normal ?
Thanks for any advice !
Cheers.
Arnaud
******************************************************************************************************************************
Backup and Recovery Systems Administrator Panalpina Management Ltd., Basle,
Switzerland, CIT Department Viadukstrasse 42, P.O. Box 4002 Basel/CH
Phone: +41 (61) 226 11 11, FAX: +41 (61) 226 17 01
Direct: +41 (61) 226 19 78
e-mail: arnaud.brion AT panalpina DOT com<mailto:arnaud.brion AT panalpina DOT
com>
This electronic message transmission contains information from Panalpina and is
confidential or privileged. This information is intended only for the person
(s) named above. If you are not the intended recipient, any disclosure,
copying, distribution or use or any other action based on the contents of this
information is strictly prohibited.
If you receive this electronic transmission in error, please notify the sender
by e-mail, telephone or fax at the numbers listed above. Thank you.
******************************************************************************************************************************
|
