and in what world is updating the device class not an intervention? On 2 apr. 2012, at 18:07, Shawn Drew wrote:
> When you fail over the database, the primary pool is still defined. You > just need to update the device class to point to the DR library. > the existing tape volumes are all destroyed, but you can backup to the > pool anyway. It will grab new scratch tapes. > You can automate that. > > Regards, > Shawn > ________________________________________________ > Shawn Drew > > > > > > Internet > [email protected] > > Sent by: [email protected] > 04/02/2012 11:54 AM > Please respond to > [email protected] > > > To > ADSM-L > cc > > Subject > Re: [ADSM-L] RFE 17805 > > > > > > > On 2 apr. 2012, at 17:00, Shawn Drew wrote: > >> So in the original post, I think it was mentioned that there were 2 tape >> libraries. One in the DR site. >> If you have all copypool volumes there and have some scratch tapes, I >> don't see how any functions are missed. >> You can backup directly to the primary pool in the DR site immediately. > > that is where you are wrong, there is no primary pool on the dr site... at > least not one that can be accessed without some human intervention. > >> is only the existing volumes that are >> offline (but available through copypool) New volumes are available > from >> the scratch tapes. >> >> Regards, >> Shawn >> ________________________________________________ >> Shawn Drew >> >> >> >> >> >> Internet >> [email protected] >> >> Sent by: [email protected] >> 04/02/2012 04:57 AM >> Please respond to >> [email protected] >> >> >> To >> ADSM-L >> cc >> >> Subject >> Re: [ADSM-L] RFE 17805 >> >> >> >> >> >> >> Hi Shawn! >> To clarify myself I will explain our current setup. >> Primary location: IBM frame with one of the AIX HACMP cluster nodes, the >> diskpool located on a SAN attached storage box, mirrored to the remote >> location and the library containing the primary storage pool. >> Secondary location: IBM frame with the other HACMP cluster node, the >> mirror of the diskpool located on a SAN attached storage and the library >> containing the copy storage pool. >> If the primary location is lost, I loose one of the cluster nodes (this >> is fixed by switching to the remote location), the mirror copy of the >> diskpool (no problem) and the whole primary tapepool, because the >> library is gone too. >> Kind regards, >> Eric van Loon >> >> -----Original Message----- >> From: ADSM: Dist Stor Manager [mailto:[email protected]] On Behalf Of >> Shawn Drew >> Sent: vrijdag 30 maart 2012 16:24 >> To: [email protected] >> Subject: Re: RFE 17805 >> >> Ok, so this is for an "active-active" cluster relying on a >> active-passive >> backup solution. >> >> As far as tape goes, after a DR situation, what if you just mark the >> individual primary-tapes as destroyed instead of making the whole pool >> unavailable. It should still grab from scratch and just create new >> volumes in the primary pool. I've never done this, but I can't see why >> the primary pool wouldn't be available for backup functions. You can >> then >> rebuild the pool slowly, in the background, with restore-stg from the >> copypool. >> >> Disk solutions also add functions for a more seamless failover (vtl >> replication, svc, srdf, etc), >> >> >> Regards, >> Shawn >> ________________________________________________ >> Shawn Drew >> >> >> >> >> >> Internet >> [email protected] >> >> Sent by: [email protected] >> 03/30/2012 04:03 AM >> Please respond to >> [email protected] >> >> >> To >> ADSM-L >> cc >> >> Subject >> Re: [ADSM-L] RFE 17805 >> >> >> >> >> >> >> Hi Shawn! >> You stated: "I guess I don't see the point of failing over backup >> functions". Like I mentioned in my earlier reply: we are running a lot >> of Oracle nodes which are also configured to be high available. So they >> are running on a cluster, spread over two different locations. If one of >> the locations is hit by a disaster, the cluster switches to the other >> location and everything is up and running again. >> Oracle uses archive logs. These logs are filled and the only way to >> flush them is to make a archive log backup. If that's not possible >> (which is the case if you lost your primary pool) the archive log >> becomes full and the database simply stops. >> Kind regards, >> Eric van Loon >> >> -----Original Message----- >> From: ADSM: Dist Stor Manager [mailto:[email protected]] On Behalf Of >> Shawn Drew >> Sent: donderdag 29 maart 2012 23:54 >> To: [email protected] >> Subject: Re: RFE 17805 >> >> We have a dual Data Center with tape libraries at both sites. Each site >> provides production services for the local backups and DR services for >> the >> other site. >> In the case of a site disaster, all the hosts that would need backups >> also >> go with it. Their DR counterparts are already configured for backups >> at >> the DR site to the local TSM servers. We failover the TSM instances, >> but >> only for restore services (from the copy pools). I guess I don't see >> the >> point of failing over backup functions (as opposed to restore functions) >> >> Is the ultimate goal to make sure the DR backups occur to the same >> nodenames so it's a seamless backup history? >> >> >> >> >> Regards, >> Shawn >> >> >> >> >> Internet >> [email protected] >> >> Sent by: [email protected] >> 03/29/2012 04:09 PM >> Please respond to >> [email protected] >> >> >> To >> ADSM-L >> cc >> >> Subject >> Re: [ADSM-L] RFE 17805 >> >> >> >> >> >> >> Hi, >> >> node replication is nice, but there is no automatic failover, yet. >> >> So, in a dual-DC setup you can failover TSM in HACMP, but it's >> completely >> useless, same for replication, noting automatic. Now, what do you do >> when >> everything (and I mean everything; mainframe LPARS, databases, file >> servers, application servers, NAS filers, everything) fails over in a >> dual-DC setup but you have to manually reconfigure either every TSM >> client >> in the node replication setup, or all of your TSM storage pools. Either >> way your crucial databases have stopped archiving their logs and filled >> up >> the active log filespace long before 24x7 staff even comes round to >> calling the TSM admins. >> >> On 29 mrt. 2012, at 20:23, John Monahan wrote: >> >>> I believe TSM 6.3 node replication is one answer to your request. >>> >>> >>> >>> _______________________________________ >>> John Monahan >>> Delivery Consultant >>> Logicalis, Inc. >>> >>> _______________________________________ >>> Business and technology working as one >>> >>> This e-mail message is intended only for the confidential and >> privileged >> use of the addressee (or others authorized to receive for the >> addressee). >> If you are not an intended recipient, please delete the e-mail and any >> attachments and notify the sender immediately >>> >>> -----Original Message----- >>> From: ADSM: Dist Stor Manager [mailto:[email protected]] On Behalf >> Of >> Loon, EJ van - SPLXO >>> Sent: Thursday, March 29, 2012 3:31 AM >>> To: [email protected] >>> Subject: Re: RFE 17805 >>> >>> Hi Remco! >>> I totally agree! >>> In our shop we had to create a dedicated server to enable backups in >> case of a disaster. It contains a standby primary pool with 500 tapes, >> just sitting there, costing money. This pool is located on the remote >> location and is readonly. When the primary pool is lost, we have to make >> this pool readwrite so backups can continue. >>> In this case you can see that the primary focus of development is >> still >> on restore, while backing up became equally vital. Oracle database rely >> on >> a frequent backup of the archive logs. When they become full, Oracle >> simply stops. >>> I voted for your RFE and request others to do the same. It takes just >> one minute of your time. >>> Kind regards, >>> Eric van Loon >>> >>> -----Original Message----- >>> From: ADSM: Dist Stor Manager [mailto:[email protected]] On Behalf >> Of >> Remco Post >>> Sent: woensdag 28 maart 2012 20:43 >>> To: [email protected] >>> Subject: RFE 17805 >>> >>> Hi all, >>> >>> I submitted a RFE for TSM regarding the behavior of copy pools. >>> >>> You can find the RFE via >>> http://www.ibm.com/developerworks/rfe/execute?use_case=viewRFEs and >> search for RFE ID 17805. >>> >>> I'd like to invite all off you to vote on this RFE if you find it >> useful, so that development can get a good idea of how important this >> FRE >> would be to the customers. >>> >>> Below you find the input I submitted: >>> >>> Description: For one storage pool to be an exact replica of >> another >>> pool and be equivalent in every way, to the extend that if one pool >> becomes unavailable all activity continues on the remaining pool, >> including write activity. >>> >>> This would also involve changing the behavior of commands like delete >> volume, migration, etc. >>> >>> Use case: In a dual-site setup with two tape libraries, >> one >> would >>> want operations to continue as seamless as possible in case of a site >> disaster. Current copy storage pools can't be promoted to primary pools, >> so with the current technology one has to create new storage pools on >> the >> second site, even though a copy storage pool is already available. >>> >>> Business justification: there are many dual site setup >> with IBM and its >>> customers. All data in a TSM server environment (disk) can be >> mirrored, >> but as soon as the primary tape storage pools become unavailable, there >> is >> a lot of manual intervention involved before normal operations can >> continue. >>> >>> -- >>> Met vriendelijke groeten/Kind Regards, >>> >>> Remco Post >>> [email protected] >>> +31 6 248 21 622 >>> ******************************************************** >>> 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 >>> ******************************************************** >>> >> >> -- >> Met vriendelijke groeten/Kind Regards, >> >> Remco Post >> [email protected] >> +31 6 248 21 622 >> >> >> >> This message and any attachments (the "message") is intended solely for >> the addressees and is confidential. If you receive this message in >> error, >> please delete it and immediately notify the sender. Any use not in >> accord >> with its purpose, any dissemination or disclosure, either whole or >> partial, >> is prohibited except formal approval. The internet can not guarantee the >> integrity of this message. BNP PARIBAS (and its subsidiaries) shall >> (will) >> not therefore be liable for the message if modified. Please note that >> certain >> functions and services for BNP Paribas may be performed by BNP Paribas >> RCC, Inc. >> ******************************************************** >> 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 >> ******************************************************** >> >> >> >> >> This message and any attachments (the "message") is intended solely for >> the addressees and is confidential. If you receive this message in >> error, >> please delete it and immediately notify the sender. Any use not in >> accord >> with its purpose, any dissemination or disclosure, either whole or >> partial, >> is prohibited except formal approval. The internet can not guarantee the >> integrity of this message. BNP PARIBAS (and its subsidiaries) shall >> (will) >> not therefore be liable for the message if modified. Please note that >> certain >> functions and services for BNP Paribas may be performed by BNP Paribas >> RCC, Inc. >> ******************************************************** >> 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 >> ******************************************************** >> >> >> >> >> This message and any attachments (the "message") is intended solely for >> the addressees and is confidential. If you receive this message in > error, >> please delete it and immediately notify the sender. Any use not in > accord >> with its purpose, any dissemination or disclosure, either whole or > partial, >> is prohibited except formal approval. The internet can not guarantee the >> integrity of this message. BNP PARIBAS (and its subsidiaries) shall > (will) >> not therefore be liable for the message if modified. Please note that > certain >> functions and services for BNP Paribas may be performed by BNP Paribas > RCC, Inc. > > -- > Met vriendelijke groeten/Kind Regards, > > Remco Post > [email protected] > +31 6 248 21 622 > > > > This message and any attachments (the "message") is intended solely for > the addressees and is confidential. If you receive this message in error, > please delete it and immediately notify the sender. Any use not in accord > with its purpose, any dissemination or disclosure, either whole or partial, > is prohibited except formal approval. The internet can not guarantee the > integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) > not therefore be liable for the message if modified. Please note that certain > functions and services for BNP Paribas may be performed by BNP Paribas RCC, > Inc. -- Met vriendelijke groeten/Kind Regards, Remco Post [email protected] +31 6 248 21 622
