Re: Database restore and containerpools
Hi Del! Thanks for your confirmation! 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 Del Hoobler Sent: maandag 7 augustus 2017 17:08 To: ADSM-L@VM.MARIST.EDU Subject: Re: Database restore and containerpools 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" wrote on 08/04/2017 02:38:10 AM: > From: "Loon, Eric van (ITOPT3) - KLM" > 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" > > 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 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/01c7.dcf > > action=removedamaged ANR3710I This command will delete container > > /tech/tsm/server/container00/01/01c7.dcf > > from the file system. > > ANR3711E Container > > /tech/tsm/server/container00/01/01c7.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
Re: Database restore and containerpools
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" wrote on 08/04/2017 02:38:10 AM: > From: "Loon, Eric van (ITOPT3) - KLM" > 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" > > 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 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/01c7.dcf > > action=removedamaged ANR3710I This command will delete container > > /tech/tsm/server/container00/01/01c7.dcf > > from the file system. > > ANR3711E Container > > /tech/tsm/server/container00/01/01c7.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
Re: Database restore and containerpools
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 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/01c7.dcf > action=removedamaged ANR3710I This command will delete container > /tech/tsm/server/container00/01/01c7.dcf > from the file system. > ANR3711E Container > /tech/tsm/server/container00/01/01c7.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
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 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/01c7.dcf action=removedamaged > ANR3710I This command will delete container > /tech/tsm/server/container00/01/01c7.dcf > from the file system. > ANR3711E Container /tech/tsm/server/container00/01/01c7.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 > >
Database restore and containerpools
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 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/01c7.dcf action=removedamaged ANR3710I This command will delete container /tech/tsm/server/container00/01/01c7.dcf from the file system. ANR3711E Container /tech/tsm/server/container00/01/01c7.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
