| Author |
Message
|
| jonny |
 Posted: Wed Oct 20, 2004 6:50 am Post subject: Backup and Recovery |
 |
|
Acolyte
Joined: 03 Jul 2003
Posts: 57
|
Hi,
I have looked at some of the backup and recovery threads here, but I am still confused, could you please advice me as what should be backed up and when. Why I mean by when, is lets say I am goind to deploy a new changes to a flow, would then take a backup before you deploy the changes, and to which components?
WBIMB, CSD04, WMQ 5.3 CSD08, Sybase on Solars for the broker
Thanks in advance |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Wed Oct 20, 2004 7:19 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
If you are using version 5, then you should backup your broker and broker database merely to provide failure recovery.
You should put all of your message flows and sets under version control, and redeploy from version control for purposes of point-in-time recovery.
You should backup your version control repository for purposes of crash recovery and point-in-time recovery.
This is my opinion.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| PGoodhart |
| Posted: Wed Oct 20, 2004 8:56 am Post subject: |
|
|
Master
Joined: 17 Jun 2004
Posts: 278
Location: Harrisburg PA
|
Ditto.
You need your queue manager objects (queues channels etc) as well. (Version control on these would be best.)
Take a baseline file system backup with everything stopped.
Then backup you dbs at least weekly.
Backup your queue manager as per IBM every day. This requires a shutdown.
_________________
Patrick Goodhart
MQ Admin/Web Developer/Consultant
WebSphere Application Server Admin |
|
| Back to top |
|
|
| kirani |
| Posted: Wed Oct 20, 2004 10:44 am Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001
Posts: 3779
Location: Torrance, CA, USA
|
If you are interested in WMQ object defn backup then you can use one of the supportpac which will backup your object defn.
We use TSM client on our servers to backup WMQI related databases and app databases in real-time mode.
_________________
Kiran
IBM Cert. Solution Designer & System Administrator - WBIMB V5
IBM Cert. Solutions Expert - WMQI
IBM Cert. Specialist - WMQI, MQSeries
IBM Cert. Developer - MQSeries
|
|
| Back to top |
|
|
| jonny |
| Posted: Thu Oct 21, 2004 1:03 am Post subject: |
|
|
Acolyte
Joined: 03 Jul 2003
Posts: 57
|
| So If I don't backup the configuration manager or its database, and if I had to rebuid the configuration manager and its database, and then try to register it with the existing broker that was registered witht he old configuration manager, wouldn't this cause a probelm? I just want some confirmation that there is no need to backup the configuration manager database. |
|
| Back to top |
|
|
| kirani |
| Posted: Thu Oct 21, 2004 8:39 am Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001
Posts: 3779
Location: Torrance, CA, USA
|
Yes, it would cause the problem. But in that case you can always re-create your Broker and re-deploy the BAR files.
_________________
Kiran
IBM Cert. Solution Designer & System Administrator - WBIMB V5
IBM Cert. Solutions Expert - WMQI
IBM Cert. Specialist - WMQI, MQSeries
IBM Cert. Developer - MQSeries
|
|
| Back to top |
|
|
| jonny |
| Posted: Mon Oct 25, 2004 6:56 am Post subject: |
|
|
Acolyte
Joined: 03 Jul 2003
Posts: 57
|
| It looks like the best backup and recovery strategy is to only backup the CVS repository where the message flows and message sets are, so in case of recvery just recreate the broker and the configuration manager and then register the broker, recreate execution groups, and the final step redeploy the bar files... This is sounds good to me, it will save us the headach of backing up the configuration manager and the broker database. But imagine if we have a big number of brokers and execution groups, As you know registering the broker and the creation of execution groups must be done using the toolkit, so this step cannot be automated, and it means it will take longer to recover out environment. What is the best backup and recovery strategy for a more complex environment. |
|
| Back to top |
|
|
|
|
