| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| MQ for z/OS Disaster Recovery |
« View previous topic :: View next topic » |
| Author |
Message
|
| SuzyMari |
 Posted: Tue Jun 14, 2005 5:43 am Post subject: MQ for z/OS Disaster Recovery |
 |
|
Newbie
Joined: 16 May 2005
Posts: 1
Location: Brazil
|
Hi,
I have a DR Test in my client and I need to restart a QM, in the alternate site. It is a QM (v5.3.1).
The full volume backups waste 2 or 3 hours.
Have anyone ever tried to use the commands SUSPEND QMGR LOG before the backups and after finished, RESUME QMGR LOG?
I would like to have another way to take copies, instead of let the Queue Manager down.
Tks. |
|
| Back to top |
|
 |
| EddieA |
| Posted: Tue Jun 14, 2005 6:10 am Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
| Quote: |
| Have anyone ever tried to use the commands SUSPEND QMGR LOG before the backups |
Do you issue that command before you take your backups today. Are you planning to do this every time you take a backup.
| Quote: |
| I would like to have another way to take copies, instead of let the Queue Manager down. |
Will you be taking the QM down every time you take a backup in the "real world".
The idea of a DR Test is to ensure that the backups you are currently taking will be sufficient to perform a recovery. Taking the backups with "special conditions" is not the way to do it.
I thought the mainframe version had the ability to take, and recover from, a "fuzzy" backup. It's only the distributed world where you need to end the QM for a backup.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Jun 14, 2005 6:17 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I'm by no means a mainframe expert, but I also thought the z/OS MQ software had the ability to keep duplicate logs. Presumably this would help in some way - possibly by allowing you to back up one set without taking down the qmgr.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Robbo |
| Posted: Tue Jun 14, 2005 6:59 am Post subject: |
|
|
Newbie
Joined: 09 Feb 2005
Posts: 5
Location: UK
|
| We currently back up our page sets and bsds hourly, the Coupling facility for the shared queues daily, and the archived logs on a daily basis. We also make a daily copy of all queue / channel / processes / storage classes. We use fuzzy backups as we have a broker running 24/7. |
|
| Back to top |
|
|
| JWJ |
| Posted: Tue Jun 14, 2005 8:26 am Post subject: |
|
|
Novice
Joined: 13 Jun 2002
Posts: 18
Location: Farmers Insurance Group
|
Our approach is a bit different. First off, I'm not really sure how to deal with providing message recovery at the DR site. We do not have "Electronic Vaulting". Our DR backups consist of ABARS dataset backups, including the CSQINP file, and a PDS that contains the jobs necessary to allocate new page and log datasets. These tapes are sent out once a day to our offsite tape storage vendor. For local recovery, once a night, we do a fuzzy backup of the page files and also run the command to output all of the resource defining commands back into our CSQINP PDS. Prior to this command we make a backup of the CSQINP file. By the way, we are doing the CF structure backups once an hour.
As I said, I'm not sure what to commit to as to message recovery for DR, so we say we don't, and just recovery the Qmgr, but with no data.
Maybe if we get a offsite storage that we can electronically send logs to, we'll try to do a bit more.
Jerry
_________________
JWJ |
|
| Back to top |
|
|
| javagate |
| Posted: Wed Jun 22, 2005 8:12 am Post subject: |
|
|
Disciple
Joined: 15 Nov 2004
Posts: 159
|
| JWJ wrote: |
just recovery the Qmgr, but with no data.
Jerry |
If you just want to recover the queue-manager (no data) then there should be no need to send any logs offsite. Rather run the makedef utility and send the object defs offsite. say do this weekly? At the offsite delete the logcopy,bsds reallocate and reformat the PSID's then run the defs through the qmgr after you start it or stick in the startup JCL. In this case you bring the queue-manager up cold. No need to send anything off site except for the makdef objects, JCL to recreate the BSDS, Lopgcopy's, startup JCL, etc. Trying to recover MQ with the ARC's (B ony) at a DR hotsite is a trick in and of itself.
_________________
WebSphere Application Server 7.0 z/OS &
MQ 6.0. I work with WebSphere in the real world not in some IBM lab. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
