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 eric-van.l...@klm.com Sent by: ADSM-L@VM.MARIST.EDU 03/30/2012 04:03 AM Please respond to ADSM-L@VM.MARIST.EDU 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:ADSM-L@VM.MARIST.EDU] On Behalf Of Shawn Drew Sent: donderdag 29 maart 2012 23:54 To: ADSM-L@VM.MARIST.EDU 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 r.p...@plcs.nl Sent by: ADSM-L@VM.MARIST.EDU 03/29/2012 04:09 PM Please respond to ADSM-L@VM.MARIST.EDU 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:ADSM-L@VM.MARIST.EDU] On Behalf Of Loon, EJ van - SPLXO > Sent: Thursday, March 29, 2012 3:31 AM > To: ADSM-L@VM.MARIST.EDU > 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:ADSM-L@VM.MARIST.EDU] On Behalf Of Remco Post > Sent: woensdag 28 maart 2012 20:43 > To: ADSM-L@VM.MARIST.EDU > 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 > r.p...@plcs.nl > +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 r.p...@plcs.nl +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.
