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
> ********************************************************
>
|
