| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Help With Backups |
« View previous topic :: View next topic » |
| Author |
Message
|
| Boomn4x4 |
 Posted: Tue Sep 10, 2013 11:34 am Post subject: Help With Backups |
 |
|
Disciple
Joined: 28 Nov 2011
Posts: 172
|
I had an original backup configuration setup where I had a primary qmgr (with linear logging) on one machine and a secondary qmgr on another. The primary routinly advanced the log files, and copied the necessary files over to the secondary which were then replayed (strmqm -r $QMGR) ... this worked fine... BUT it didn't mesh well with our existing backup procedures for other applications.
I was challenged to make the backup procedure more in sync with everthing else. What I started doing was during the regular nightly backup shut down the qmgr. Once down, archive /var/mqm/qmgrs /var/mqm/log and mqs.ini and copy them over to the secondary. Then clean up any old log files on the secondary. Then start the qmgr backup Then through out the day, advance the log files and copy them to a backup directory on the secondary. My thinking was to get a fresh backup of the entire QMGR every night. Then, save the log files through the day and only apply them if a failure happened and they were needed.
Then, when a restore needed to happen, extract the archive, then copy the remaining log files that that were in the backup directory to /var/mqm/log/QMGR/active then start the QMGR.
This seemed to work, at first. But, after I started advancing the logs past a few iterations I ran into a scenario where there QMGR failed to start AMQ7017
A: Any suggestions as to why I started getting the AMQ7017
B: Any suggestions as to how to accomplish what I've been asked to do. Namely, just backup the qmgr at the end of day, yet keep the current day logs available if a restore needs to happen.
Thank you. |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Tue Sep 10, 2013 12:13 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
log files copied while the queue manager is running may not be consistent.
You should consider whether this is a case better suited to an MI qmgr, or to a disk-replication backup rather than a file system backup. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Tue Sep 10, 2013 3:05 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
What is the point of this this type of convoluted backup? It doesn't seem very practical to me.
Do you have a large number of application messages sitting in MQ at any given time and you want to back these up?
_________________
Glenn |
|
| Back to top |
|
|
| Andyh |
| Posted: Wed Sep 11, 2013 2:52 am Post subject: |
|
|
Master
Joined: 29 Jul 2010
Posts: 239
|
If you think of the overnight copy of the queue manager as re-instantiating the backup, and then you replay the days logs (only in the event of a failure) with strmqm -r, and eventually finish off with an strmqm -a then I think what you're doing should work.
Note that you should only copy a log extent when the primary has finished writing to that extent (for example advancing the log will make any 'current' extent complete) or when the queue manager is stopped.
Note also that you should only copy the log extent files, and NOT the log control files during the second phase (i.e the log control file is copied as part of the complete backup, but not after that). |
|
| Back to top |
|
|
| Boomn4x4 |
| Posted: Wed Sep 11, 2013 3:53 am Post subject: |
|
|
Disciple
Joined: 28 Nov 2011
Posts: 172
|
| mqjeff wrote: |
You should consider whether this is a case better suited to an MI qmgr, or to a disk-replication backup rather than a file system backup. |
Very much so, but... a MI qmgr requires a license for both qmgrs, and disk replication backups would require the purchase of new hardware for each qmgr, I have over 6,000 qmgrs, this wasn't budgeted for.
| gbaddeley wrote: |
What is the point of this this type of convoluted backup? It doesn't seem very practical to me.
Do you have a large number of application messages sitting in MQ at any given time and you want to back these up? |
There shouldn't be a large number of messages, however, network connectivity isn't highly reliable and can be down between qmgrs (we are using clustering to relay messages over a global network) so messages could be sitting on queues for several hours before the network is back up and messages can be dumped from the transmission queues. I want these messages backed up as much as possible.
With that said, I welcome further discussion on this subject as I was kind of dumped into this project with no formal training going strictly off of the documentation from the WebSphere Information Center and development guides. If I'm way off base here, I would appreciate any input.
| Andyh wrote: |
| If you think of the overnight copy of the queue manager as re-instantiating the backup, and then you replay the days logs (only in the event of a failure) with strmqm -r, and eventually finish off with an strmqm -a then I think what you're doing should work. |
That was a huge help, I was missing the replay step during my recovery. I was just trying to start the qmgr. I added the strmqm -r -> strmqm -a -> strmqm and it came up. Thank you! |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Sep 11, 2013 4:14 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Boomn4x4 wrote: |
| mqjeff wrote: |
You should consider whether this is a case better suited to an MI qmgr, or to a disk-replication backup rather than a file system backup. |
Very much so, but... a MI qmgr requires a license for both qmgrs, and disk replication backups would require the purchase of new hardware for each qmgr, I have over 6,000 qmgrs, this wasn't budgeted for. |
I believe that an MI qmgr only requires a license for both machines if the second machine is actually running. With the introduction of MI, the pattern for HA changed to use the same technology base as MI, and the main difference between the two is that under MI, there's an MQ process running on the secondary machine, and under HA there isn't.
So I believe that running the second process changes the licensing requirements for the standby machine.
Obviously a question to resolve with your IBM Sales Rep.
It might be more architecturally sound to build a cluster setup that moves all messages that have to cross the unreliable network boundary to a small set of qmgrs, and then make those MI/HA/something.
But this assumes that there's only a small set of unreliable network boundaries, and that you don't have unreliable network boundaries between every single one of those 6,000 qmgrs. |
|
| 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
|
|
|
|
