Hi Eric,
This should be fine.
I will work with the owner of the documentation to get something added
moving forward.
Del
----------------------------------------------------
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 08/04/2017
02:38:10 AM:
> From: "Loon, Eric van (ITOPT3) - KLM" <Eric-van.Loon AT KLM DOT COM>
> To: ADSM-L AT VM.MARIST DOT EDU
> Date: 08/04/2017 02:39 AM
> Subject: Re: Database restore and containerpools
> Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>
> Hi Stefan!
> I think too this is the way to do it, but I prefer to have an
> 'official' confirmation from IBM (Del?). IBM might have to correct
> the manual too than, because an audit of a container that is not in
> the database doesn't seem to work...
> Kind regards,
> Eric van Loon
> Air France/KLM Storage Engineering
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On
> Behalf Of Stefan Folkerts
> Sent: donderdag 3 augustus 2017 19:50
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: Database restore and containerpools
>
> Hi Eric,
>
> I've been in this situation before a while back and what I did was
> about the same, I did a query container from a for loop based on the
> output from the find command on the filesytems I believe and every
> container I did not find in Spectrum protect was deleted (rc != 0 on
> the dsmadmc q container) was deleted on the filesystem by hand, I
> double checked everything.
>
>
>
>
>
> On Thu, Aug 3, 2017 at 3:14 PM, Loon, Eric van (ITOPT3) - KLM <
> Eric-van.Loon AT klm DOT com> wrote:
>
> > Hi all,
> > I'm working on a procedure on how to handle a TSM server (with a
> > container
> > pool) when a database is restored to the latest backup. When you do
> > this, you might end up with containers which were created after the
> > last backup and which are not known to the TSM server because they
> > were not yet created at the time of the last backup.
> > In my case all containers are located in subdirectories in
> > /tech/tsm/server, I use the following command to count them:
> >
> > find /tech/tsm/server/container* -type f|wc -l
> >
> > and then I use this command to count the amount of containers in TSM:
> >
> > select count(*) from containers
> >
> > The amount should be the same. If there are more files on the local
> > filesystem than in TSM, these are obsolete and should be removed. The
> > SP manual (chapter Recovery from data loss outages) suggests to use
> > the audit container <container_name> action=removedamaged to delete
> > the container, but that doesn't seem to work. To test this I copied a
> > container to a temp file on the local filesystem, moved the source
> > container to a new one in TSM (temporarily set reusedelay=0) and as
> > soon as the source file was gone, renamed the temp file to the same
> > name as the source file. As soon as I audit it, it is not being
removed:
> >
> > ANR2017I Administrator ADMIN command: AUDIT CONTAINER
> > /tech/tsm/server/container00/01/00000000000001c7.dcf
> > action=removedamaged ANR3710I This command will delete container
> > /tech/tsm/server/container00/01/00000000000001c7.dcf
> > from the file system.
> > ANR3711E Container
> > /tech/tsm/server/container00/01/00000000000001c7.dcf
> > will not be removed from the file system.
> > ANR2017I Administrator ADMIN issued command: ROLLBACK
> >
> > The message ANR3711E seems to indicate that the header could not be
> > validated...
> >
> > What should be the right procedure to handle such a situation then?
> > Just delete the obsolete containers manually?
> > Thanks for any help in advance!
> > Kind regards,
> > Eric van Loon
> > Air France/KLM Storage Engineering
> > ********************************************************
> > 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
> > ********************************************************
> >
> ********************************************************
> 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
> ********************************************************
|