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.l...@klm.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 > ******************************************************** >
