Odd behavior during CIFS file restore

[Robert Talda]

Folks:
  Now that Paul Zarnowski and his extensive knowledge and experience have 
retired to greener pastures, we need to reach out to the community for some 
insight.

  We have a NetApp appliance that supports our Shared File Service for campus, 
offering both CIFS and NFS shares.  In line with a recent list discussion about 
the problems with NDMP backups, we use two proxy systems for backup (Windows 
Server 2012 R2 for CIFS shares; RHEL 6 for NFS shares).  While we have our fair 
share of issues with the backups, in general this architecture has worked for 
us.

  Recently, though, we had to perform a restore of a directory on a CIFS share 
for a user.  This is outside our normal boundaries, but it was an emergency.  
In the process, we encountered something odd that I can’t explain.  Actually, 
there were 2 oddities.

So, starting with the facts:

   NetApp Filer Version Information: NetApp Release 9.1P5: Sun Jun 11 
02:26:58 UTC 2017
   SP Client Version 8, Release 1, Level 0.1
   TSM Server Version 7, Release 1, Level 7.200

The restore was not back to the source directory, but rather to a new directory 
created by the user as a target for the restore.  As such, we initially started 
out using UNC names for both the source AND the larget directory, namely

 Dsmc restore -optfile=“share.opt” -latest -subdir=yes 
“\\share.files.cornell.edu\vol\user\source 
dir\*” 
“\\share.files.cornell.edu\vol\user\target dir”

Obviously, the actual UNC names differ, but the “ “ in both the source and 
target directory names did exist.

Oddity 1: Issuing the command as written resulted in the SP client attempting 
to restore to the source directory, for we got a prompt about overwriting an 
existing file.  However, SP client wrote no message of any kind about not being 
able to access the target directory to either standard output or the 
dsmerror.log.  It just tried to restore back to the source directory.

Oddity 2: it appears that the “ “ in the target directory was causing the 
problem.  That is, we eventually got the restore to work, via trial and error, 
via the following sequence
Net use Z: 
“\\share.files.cornell.edu\vol\user\target dir”
Dsmc restore -optfile=“share.opt” -latest -subdir=yes 
“\\share.files.cornell.edu\vol\user\source 
dir\*” “z:\”

However, any attempt to set the drive letter to a higher level directory 
failed, i.e.
Net use Z:  “\\share.files.cornell.edu\vol\user”
Dsmc restore -optfile=“share.opt” -latest -subdir=yes 
“\\share.files.cornell.edu\vol\user\source 
dir\*” “z:\target dir\”
failed.

Has any one seen anything like this?

Thanks,
Bob T



Robert Talda
EZ-Backup Systems Engineer
Cornell University
+1 607-255-8280
r...@cornell.edu

Re: [EXTERNAL] Re: [ADSM-L] sp 8.1.2

[Zoltan Forray]

Thanks for the suggestions but none of them will ever work in our chosen
configuration/environment.  Since it was clarified that the web
interface/support is being removed from the server only (not the client), I
no longer have a concern.

On Thu, Aug 10, 2017 at 11:02 AM, J. Pohlmann  wrote:

> Hi Zoltan. I suppose the approach now for a helpdesk is to have the
> helpdesk folks have root access, have X11/Xwindows installed on the client,
> and then if the helpdesk uses Windows, have MobaXterm or similar to provide
> access to dsmj. On Windows, RDP or TeamViewer or similar might be the
> solution. I find that usually in UNIX/Linux environments that people have
> used the Web Client. If anyone has a simpler solution than root access and
> X11+Xwindows client, I would appreciate hearing about it.
>
> Regards,
> Joerg Pohlmann
>
> -Original Message-
> From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of
> Shawn Drew
> Sent: Wednesday, August 09, 2017 10:12
> To: ADSM-L@VM.MARIST.EDU
> Subject: Re: [ADSM-L] [EXTERNAL] Re: [ADSM-L] sp 8.1.2
>
> www.ibm.com/support/knowledgecenter/SSEQVQ_8.1.2/
> client/r_new_for_version.html
>
> "You can no longer use the web client to connect to IBM Spectrum Protect
> V8.1.2 or later"
>
> On Aug 9, 2017, 1:04 PM -0400, Zoltan Forray , wrote:
> > Say what? If there is no longer a web-client interface, that will
> > totally destroy our current process of having 1-server with 40-TSM
> > clients/nodes and all access for restores is via the web-interface.
> > Can you point me to the document you are referring to?
> >
> > On Wed, Aug 9, 2017 at 12:53 PM, Shawn Drew  wrote:
> >
> > > Geez, just read the client section. The web client is deprecated,
> > > which means ndmp is a command-line-only thing now?
> > >
> > > On Aug 9, 2017, 12:34 PM -0400, Shawn DREW
> > > ,
> > > wrote:
> > > > Probably just referring to the documentation:
> > > >
> > > > https://www.ibm.com/support/knowledgecenter/en/SSEQVQ_8.1.
> > > 2/srv.common/r_wn_tsmserver.html
> > > >
> > > >
> > > > -Original Message-
> > > > From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On
> > > > Behalf
> > > Of Zoltan Forray
> > > > Sent: Wednesday, August 09, 2017 11:51 AM
> > > > To: ADSM-L@VM.MARIST.EDU
> > > > Subject: [EXTERNAL] Re: [ADSM-L] sp 8.1.2
> > > >
> > > > I am curious how you got 8.1.2? I just searched and it isn't on
> > > > the FTP
> > > site or Passport? Are you a beta tester?
> > > >
> > >
> >
> >
> >
> > --
> > *Zoltan Forray*
> > Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator Xymon
> > Monitor Administrator VMware Administrator Virginia Commonwealth
> > University UCC/Office of Technology Services www.ucc.vcu.edu
> > zfor...@vcu.edu - 804-828-4807 Don't be a phishing victim - VCU and
> > other reputable organizations will never use email to request that you
> > reply with your password, social security number or confidential
> > personal information. For more details visit
> > http://infosecurity.vcu.edu/phishing.html
>



--
*Zoltan Forray*
Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator
Xymon Monitor Administrator
VMware Administrator
Virginia Commonwealth University
UCC/Office of Technology Services
www.ucc.vcu.edu
zfor...@vcu.edu - 804-828-4807
Don't be a phishing victim - VCU and other reputable organizations will
never use email to request that you reply with your password, social
security number or confidential personal information. For more details
visit http://infosecurity.vcu.edu/phishing.html

Re: deleting a directory container

[Loon, Eric van (ITOPT3) - KLM]

Hi Remco!
Yes, there is a small delay of a few minutes before containers are actually 
removed, I noticed that behavior too.
You stated "it should not, there is no use in retaining damaged containers". 
True, but if you roll back your database for some reason, you want all 
containers to be there too, even the damaged ones, otherwise you can't fix them 
(and your database) with an audit.
Kind regards,
Eric van Loon
Air France/KLM Storage Engineering


-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Remco 
Post
Sent: donderdag 10 augustus 2017 16:57
To: ADSM-L@VM.MARIST.EDU
Subject: Re: deleting a directory container

and apparently, waiting for some time does help….

> On 10 Aug 2017, at 16:48, Remco Post  wrote:
> 
>> On 10 Aug 2017, at 16:42, Loon, Eric van (ITOPT3) - KLM 
>>  wrote:
>> 
>> Hi Remco!
>> Could it be that the reusedelay on the storagepool is preventing TSM from 
>> removing the containers? 
> 
> it should not, there is no us in retaining damaged containers. But to make 
> sure, I’ve set the reusedelay to 0 and retried the audit etc. unfortunately, 
> that didn’t help.
> 
>> Kind regards,
>> Eric van Loon
>> Air France/KLM Storage Engineering
>> 
>> -Original Message-
>> From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of 
>> Remco Post
>> Sent: donderdag 10 augustus 2017 16:26
>> To: ADSM-L@VM.MARIST.EDU
>> Subject: deleting a directory container
>> 
>> Hi all,
>> 
>> On our new tsm 8.1.1 server I have a directory container pool CC_COM that I 
>> no longer want to use. It has been used as a target pool for protect stg 
>> once, but when I saw that a subsequent repl node again copies all data 
>> because the stgpool in the copygroup is CP_COM (which also exists), I 
>> decided to do away with the CC_COM pool.
>> 
>> So I updated the stgpooldir to destroyed and ran audit container … 
>> action=removedamaged
>> 
>> unfortunately, there are still containers in the directory and no matter 
>> what I do… the server insists that the container directory still has active 
>> data. How do I get rid of this directory container?
>> 
>> -- 
>> 
>> Met vriendelijke groeten/Kind Regards,
>> 
>> Remco Post
>> r.p...@plcs.nl
>> +31 6 248 21 622
>> 
>> For information, services and offers, please visit our web site: 
>> http://www.klm.com. This e-mail and any attachment may contain confidential 
>> and privileged material intended for the addressee only. If you are not the 
>> addressee, you are notified that no part of the e-mail or any attachment may 
>> be disclosed, copied or distributed, and that any other action related to 
>> this e-mail or attachment is strictly prohibited, and may be unlawful. If 
>> you have received this e-mail by error, please notify the sender immediately 
>> by return e-mail, and delete this message. 
>> 
>> Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
>> employees shall not be liable for the incorrect or incomplete transmission 
>> of this e-mail or any attachments, nor responsible for any delay in receipt. 
>> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
>> Airlines) is registered in Amstelveen, The Netherlands, with registered 
>> number 33014286
>> 
> 
> -- 
> 
> Met vriendelijke groeten/Kind Regards,
> 
> Remco Post
> r.p...@plcs.nl
> +31 6 248 21 622

-- 

 Met vriendelijke groeten/Kind Regards,

Remco Post
r.p...@plcs.nl
+31 6 248 21 622

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286

Re: [EXTERNAL] Re: [ADSM-L] sp 8.1.2

[J. Pohlmann]

Hi Zoltan. I suppose the approach now for a helpdesk is to have the helpdesk 
folks have root access, have X11/Xwindows installed on the client, and then if 
the helpdesk uses Windows, have MobaXterm or similar to provide access to dsmj. 
On Windows, RDP or TeamViewer or similar might be the solution. I find that 
usually in UNIX/Linux environments that people have used the Web Client. If 
anyone has a simpler solution than root access and X11+Xwindows client, I would 
appreciate hearing about it.

Regards,
Joerg Pohlmann

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Shawn 
Drew
Sent: Wednesday, August 09, 2017 10:12
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] [EXTERNAL] Re: [ADSM-L] sp 8.1.2

www.ibm.com/support/knowledgecenter/SSEQVQ_8.1.2/client/r_new_for_version.html

"You can no longer use the web client to connect to IBM Spectrum Protect V8.1.2 
or later"

On Aug 9, 2017, 1:04 PM -0400, Zoltan Forray , wrote:
> Say what? If there is no longer a web-client interface, that will 
> totally destroy our current process of having 1-server with 40-TSM 
> clients/nodes and all access for restores is via the web-interface. 
> Can you point me to the document you are referring to?
>
> On Wed, Aug 9, 2017 at 12:53 PM, Shawn Drew  wrote:
>
> > Geez, just read the client section. The web client is deprecated, 
> > which means ndmp is a command-line-only thing now?
> >
> > On Aug 9, 2017, 12:34 PM -0400, Shawn DREW 
> > ,
> > wrote:
> > > Probably just referring to the documentation:
> > >
> > > https://www.ibm.com/support/knowledgecenter/en/SSEQVQ_8.1.
> > 2/srv.common/r_wn_tsmserver.html
> > >
> > >
> > > -Original Message-
> > > From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On 
> > > Behalf
> > Of Zoltan Forray
> > > Sent: Wednesday, August 09, 2017 11:51 AM
> > > To: ADSM-L@VM.MARIST.EDU
> > > Subject: [EXTERNAL] Re: [ADSM-L] sp 8.1.2
> > >
> > > I am curious how you got 8.1.2? I just searched and it isn't on 
> > > the FTP
> > site or Passport? Are you a beta tester?
> > >
> >
>
>
>
> --
> *Zoltan Forray*
> Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator Xymon 
> Monitor Administrator VMware Administrator Virginia Commonwealth 
> University UCC/Office of Technology Services www.ucc.vcu.edu 
> zfor...@vcu.edu - 804-828-4807 Don't be a phishing victim - VCU and 
> other reputable organizations will never use email to request that you 
> reply with your password, social security number or confidential 
> personal information. For more details visit 
> http://infosecurity.vcu.edu/phishing.html

AW: deleting a directory container

[Michael Malitz]

Hallo,

 

If your command sequence happend today,  you only  have to wait another day and 
the extents should be gone.

 

If this ist the  case BUT you  would like to delete  the unused container(s)  
earlier:

 

Try:

 

q extentupdates

 

if you see  „Extent Reuse Delay (Days)  NOT equal to 0  please try to update 

 

 

update stgpool  “  reusedelay=0

 

After 30 Minutes (sometime also more) the container should be gone (have also a 
look to the meaning of reusedelay).

 

++

 

Another general  point regarding the  update of a stgpooldir with 
"access=destroyed":   

 

In general, the commands  you entered should work but in some of my customer 
cases this was not always  true.

 

The  update of a stgpooldir with "access=destroyed"   command should mark the 
objects as damaged . 

 

After that you should be able to see damaged objects -  enter:„q damaged   
“

 

 

   If not,  you can also  try to use the  audit container  command 
with  „action=markdamaged“  and after that  „ with action=removedamaged„

 

 

Rgds michael

 

-Ursprüngliche Nachricht-
Von: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] Im Auftrag von Remco 
Post
Gesendet: Donnerstag, 10. August 2017 16:26
An: ADSM-L@VM.MARIST.EDU
Betreff: deleting a directory container

 

Hi all,

 

On our new tsm 8.1.1 server I have a directory container pool CC_COM that I no 
longer want to use. It has been used as a target pool for protect stg once, but 
when I saw that a subsequent repl node again copies all data because the 
stgpool in the copygroup is CP_COM (which also exists), I decided to do away 
with the CC_COM pool.

 

So I updated the stgpooldir to destroyed and ran audit container … 
action=removedamaged

 

unfortunately, there are still containers in the directory and no matter what I 
do… the server insists that the container directory still has active data. How 
do I get rid of this directory container?

 

-- 

 

Met vriendelijke groeten/Kind Regards,

 

Remco Post

  r.p...@plcs.nl

+31 6 248 21 622

Re: deleting a directory container

[Remco Post]

and apparently, waiting for some time does help….

> On 10 Aug 2017, at 16:48, Remco Post  wrote:
> 
>> On 10 Aug 2017, at 16:42, Loon, Eric van (ITOPT3) - KLM 
>>  wrote:
>> 
>> Hi Remco!
>> Could it be that the reusedelay on the storagepool is preventing TSM from 
>> removing the containers? 
> 
> it should not, there is no us in retaining damaged containers. But to make 
> sure, I’ve set the reusedelay to 0 and retried the audit etc. unfortunately, 
> that didn’t help.
> 
>> Kind regards,
>> Eric van Loon
>> Air France/KLM Storage Engineering
>> 
>> -Original Message-
>> From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of 
>> Remco Post
>> Sent: donderdag 10 augustus 2017 16:26
>> To: ADSM-L@VM.MARIST.EDU
>> Subject: deleting a directory container
>> 
>> Hi all,
>> 
>> On our new tsm 8.1.1 server I have a directory container pool CC_COM that I 
>> no longer want to use. It has been used as a target pool for protect stg 
>> once, but when I saw that a subsequent repl node again copies all data 
>> because the stgpool in the copygroup is CP_COM (which also exists), I 
>> decided to do away with the CC_COM pool.
>> 
>> So I updated the stgpooldir to destroyed and ran audit container … 
>> action=removedamaged
>> 
>> unfortunately, there are still containers in the directory and no matter 
>> what I do… the server insists that the container directory still has active 
>> data. How do I get rid of this directory container?
>> 
>> -- 
>> 
>> Met vriendelijke groeten/Kind Regards,
>> 
>> Remco Post
>> r.p...@plcs.nl
>> +31 6 248 21 622
>> 
>> For information, services and offers, please visit our web site: 
>> http://www.klm.com. This e-mail and any attachment may contain confidential 
>> and privileged material intended for the addressee only. If you are not the 
>> addressee, you are notified that no part of the e-mail or any attachment may 
>> be disclosed, copied or distributed, and that any other action related to 
>> this e-mail or attachment is strictly prohibited, and may be unlawful. If 
>> you have received this e-mail by error, please notify the sender immediately 
>> by return e-mail, and delete this message. 
>> 
>> Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
>> employees shall not be liable for the incorrect or incomplete transmission 
>> of this e-mail or any attachments, nor responsible for any delay in receipt. 
>> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
>> Airlines) is registered in Amstelveen, The Netherlands, with registered 
>> number 33014286
>> 
> 
> -- 
> 
> Met vriendelijke groeten/Kind Regards,
> 
> Remco Post
> r.p...@plcs.nl
> +31 6 248 21 622

-- 

 Met vriendelijke groeten/Kind Regards,

Remco Post
r.p...@plcs.nl
+31 6 248 21 622

Re: deleting a directory container

[Remco Post]

> On 10 Aug 2017, at 16:42, Loon, Eric van (ITOPT3) - KLM 
>  wrote:
> 
> Hi Remco!
> Could it be that the reusedelay on the storagepool is preventing TSM from 
> removing the containers? 

it should not, there is no us in retaining damaged containers. But to make 
sure, I’ve set the reusedelay to 0 and retried the audit etc. unfortunately, 
that didn’t help.

> Kind regards,
> Eric van Loon
> Air France/KLM Storage Engineering
> 
> -Original Message-
> From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of 
> Remco Post
> Sent: donderdag 10 augustus 2017 16:26
> To: ADSM-L@VM.MARIST.EDU
> Subject: deleting a directory container
> 
> Hi all,
> 
> On our new tsm 8.1.1 server I have a directory container pool CC_COM that I 
> no longer want to use. It has been used as a target pool for protect stg 
> once, but when I saw that a subsequent repl node again copies all data 
> because the stgpool in the copygroup is CP_COM (which also exists), I decided 
> to do away with the CC_COM pool.
> 
> So I updated the stgpooldir to destroyed and ran audit container … 
> action=removedamaged
> 
> unfortunately, there are still containers in the directory and no matter what 
> I do… the server insists that the container directory still has active data. 
> How do I get rid of this directory container?
> 
> -- 
> 
> Met vriendelijke groeten/Kind Regards,
> 
> Remco Post
> r.p...@plcs.nl
> +31 6 248 21 622
> 
> For information, services and offers, please visit our web site: 
> http://www.klm.com. This e-mail and any attachment may contain confidential 
> and privileged material intended for the addressee only. If you are not the 
> addressee, you are notified that no part of the e-mail or any attachment may 
> be disclosed, copied or distributed, and that any other action related to 
> this e-mail or attachment is strictly prohibited, and may be unlawful. If you 
> have received this e-mail by error, please notify the sender immediately by 
> return e-mail, and delete this message. 
> 
> Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
> employees shall not be liable for the incorrect or incomplete transmission of 
> this e-mail or any attachments, nor responsible for any delay in receipt. 
> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
> Airlines) is registered in Amstelveen, The Netherlands, with registered 
> number 33014286
> 

-- 

 Met vriendelijke groeten/Kind Regards,

Remco Post
r.p...@plcs.nl
+31 6 248 21 622

Re: deleting a directory container

[Loon, Eric van (ITOPT3) - KLM]

Hi Remco!
Could it be that the reusedelay on the storagepool is preventing TSM from 
removing the containers? 
Kind regards,
Eric van Loon
Air France/KLM Storage Engineering

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Remco 
Post
Sent: donderdag 10 augustus 2017 16:26
To: ADSM-L@VM.MARIST.EDU
Subject: deleting a directory container

Hi all,

On our new tsm 8.1.1 server I have a directory container pool CC_COM that I no 
longer want to use. It has been used as a target pool for protect stg once, but 
when I saw that a subsequent repl node again copies all data because the 
stgpool in the copygroup is CP_COM (which also exists), I decided to do away 
with the CC_COM pool.

So I updated the stgpooldir to destroyed and ran audit container … 
action=removedamaged

unfortunately, there are still containers in the directory and no matter what I 
do… the server insists that the container directory still has active data. How 
do I get rid of this directory container?

-- 

 Met vriendelijke groeten/Kind Regards,

Remco Post
r.p...@plcs.nl
+31 6 248 21 622

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286

Re: deleting a directory container

[Remco Post]

and, as long as we’re on the topic of directory container pools:

it is suggested to define a next stg on e.g. tape, but then, how do I get the 
data from tape back into the directory container pool once I’ve added extra 
space?

> On 10 Aug 2017, at 16:26, Remco Post  wrote:
> 
> Hi all,
> 
> On our new tsm 8.1.1 server I have a directory container pool CC_COM that I 
> no longer want to use. It has been used as a target pool for protect stg 
> once, but when I saw that a subsequent repl node again copies all data 
> because the stgpool in the copygroup is CP_COM (which also exists), I decided 
> to do away with the CC_COM pool.
> 
> So I updated the stgpooldir to destroyed and ran audit container … 
> action=removedamaged
> 
> unfortunately, there are still containers in the directory and no matter what 
> I do… the server insists that the container directory still has active data. 
> How do I get rid of this directory container?
> 
> -- 
> 
> Met vriendelijke groeten/Kind Regards,
> 
> Remco Post
> r.p...@plcs.nl
> +31 6 248 21 622

-- 

 Met vriendelijke groeten/Kind Regards,

Remco Post
r.p...@plcs.nl
+31 6 248 21 622

deleting a directory container

[Remco Post]

Hi all,

On our new tsm 8.1.1 server I have a directory container pool CC_COM that I no 
longer want to use. It has been used as a target pool for protect stg once, but 
when I saw that a subsequent repl node again copies all data because the 
stgpool in the copygroup is CP_COM (which also exists), I decided to do away 
with the CC_COM pool.

So I updated the stgpooldir to destroyed and ran audit container … 
action=removedamaged

unfortunately, there are still containers in the directory and no matter what I 
do… the server insists that the container directory still has active data. How 
do I get rid of this directory container?

-- 

 Met vriendelijke groeten/Kind Regards,

Remco Post
r.p...@plcs.nl
+31 6 248 21 622