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@VM.MARIST.EDU> wrote on 08/04/2017 02:38:10 AM: > From: "Loon, Eric van (ITOPT3) - KLM" <eric-van.l...@klm.com> > To: ADSM-L@VM.MARIST.EDU > Date: 08/04/2017 02:39 AM > Subject: Re: Database restore and containerpools > Sent by: "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.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@VM.MARIST.EDU] On > Behalf Of Stefan Folkerts > Sent: donderdag 3 augustus 2017 19:50 > To: ADSM-L@VM.MARIST.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.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 > > ******************************************************** > > > ******************************************************** > 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 > ********************************************************
