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" <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 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 st
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" <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 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
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, and delete this message.
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 > >
Re: Database restore and mirrored volume question
Hi, volumes. If so, I think you have to do the restore prior to setting up the mirrored copies, since the syntax for 'dsmserv format' has no provision for specifying mirrored volumes. I recently had to restore our database. It has mirrored volumes, but the restore was written to the first copy. After completion TSM synchronized the copies, what took another hour or so. -- Regards, Dirk Kastens Universitaet Osnabrueck, Rechenzentrum (Computer Center) Albrechtstr. 28, 49069 Osnabrueck, Germany Tel.: +49-541-969-2347, FAX: -2470
Re: Database restore and mirrored volume question
Quick question, when setting up a new server and restoring the database, is it best to do the restore prior to setting up the mirrored copies, or does it not matter either way? It sounds like you are planning something very much like a server disaster recovery: running multiple 'dsmfmt' commands to prepare disk files for use, running a 'dsmserv format' command to record the names of the disk files in the server directory, and running 'dsmserv restore db' to write the database contents onto the new volumes. If so, I think you have to do the restore prior to setting up the mirrored copies, since the syntax for 'dsmserv format' has no provision for specifying mirrored volumes.
Re: Database restore and mirrored volume question
Farren, On a restore we did recently to a live tsm mirrored environment, we could see the restore writing to both disks simulaneously (iostat). Then when the server was started, it promptly assumed one of the plexes was broken, and kicked off 26 simultaneous plex resync jobs - which finished surprisingly quickly. So, do whichever is most convenient. If you have the time available, set up the plexes first, do the restore, and let tsm take care of the resync. Regards Dave It's not broken... it's just functionally challenged Dave Frost Technical Consultant SunGard Availability Services (UK) Limited London Technology Centre Heathrow Corporate Park Hounslow UK. TW4 6ER Farren Minns [EMAIL PROTECTED] Sent by: ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU 06/02/2006 14:27 Please respond to ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU To ADSM-L@VM.MARIST.EDU cc Subject [ADSM-L] Database restore and mirrored volume question Hi all Quick question, when setting up a new server and restoring the database, is it best to do the restore prior to setting up the mirrored copies, or does it not matter either way? Thanks Farren Minns ## The information contained in this e-mail and any subsequent correspondence is private and confidential and intended solely for the named recipient(s). If you are not a named recipient, you must not copy, distribute, or disseminate the information, open any attachment, or take any action in reliance on it. If you have received the e-mail in error, please notify the sender and delete the e-mail. Any views or opinions expressed in this e-mail are those of the individual sender, unless otherwise stated. Although this e-mail has been scanned for viruses you should rely on your own virus check, as the sender accepts no liability for any damage arising out of any bug or virus infection. ##
Re: database restore
You can use raw devices for DB, log or stg volumes and there is no dsmserv format command needed. Just create the raw devices and then start to use them. No long wait to do format them... Ben -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Justin Bleistein Sent: Friday, January 16, 2004 7:14 AM To: [EMAIL PROTECTED] Subject: database restore I'm about to restore a tsm database from one physical site to another. Now on the source/current site the tsm and database log volumes are on AIX raw logical volumes/lv's/non-fs. Now I want to restore this database to the target tsm server at the target site. I assume that all I have to do is create the logical volumes without a filesystem of equal or more size on the target system's disk. Then just type in the restore command as if I do when there file volumes? When I issue the dsmserv format command before the restore to initialize the volumes I usually type in a path of the file of the database and log volumes. I'm assuming all I have to do is replace those filenames with: /dev/rlvname for the database and log?. Is this a correct assumption?. Does anyone have any commands/docs on restoring a tsm database when it's on raw logical volumes? I can't find docs anywhere for that situation. Also if I decided I wanted the volumes to be files on mounted filesystems instead of rlvs, I'm assuming I just specify the volume destination as the mounted filesystem, during the actual database restore?. Thanks in advance.. --Justin Richard Bleistein
Re: database restore on a different server
Tae, Yes, you can do this if you set up a FILE devclass for the output. When restoring, use -volume=fullpathandfilename as an arguement to the restore db command. Bill Smoldt STORServer, Inc. -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] Behalf Of Tae Kim Sent: Wednesday, September 24, 2003 12:57 PM To: [EMAIL PROTECTED] Subject: database restore on a different server Hi guys. I will be attempting to restore TSM database to a test server and run audit db. The question is if I backup up the db to disk, is it possible for me copy the file over and restore the database? TIA Tae
Re: Database Restore
Hi Bert, No - first of all you can not restore an older DB(3.1.2.90), to a newer level of the server(4.1) - even if it were on the same platform. Secondly - you can not restore the db from AIX to OS/390 - cross-platform. You need to do export db and import on OS/390 to achieve this. I would at least have the AIX server also on 4.1 before exporting data. Cheers Christo Hello ADSM/TSM guys, Can I restore an ADSM 3.1.2.90 Database running on AIX 4.3, into TSM 4.1 running on an OS/390 platform. Greetings, Bert Moonen ABP Heerlen Netherlands.
