MSMQ Backup
RCIC
message queues and messages gets routed to these queues. We need to
periodically get the backup of the MSMQ. If you use MQBKUP utility, it
requires you to stop message queuing system and because of nature of the
application we cannot stop the message queuing system. Is there any way we
can back up the message queues at real time without stopping message queuing
system.
We run this application under VMWARE environment. Are there any VMWARE tools
to backup the MSMQs. Also I understand MSMQ uses memory mapped files hence we
cannot use backup utility that uses shadow copying. Is that right?
John Breakwell (MSFT)
Hi RCIC,
"MSMQ" and "Backup" shouldn't be used in the same sentence.
MSMQ is better regarded as a transport protocol (like TCP/IP) than a storage
system (such as SQL Server).
MQBKUP is not designed for archiving. Instead it is for situations where,
for example, you want to replace a failing machine with an exact copy on
good hardware. You would take an MQBACKUP snapshot from the old machine and
restore it over a recent system backup applied to the new machine. When you
start the new machine back up, MSMQ runs as if nothing had happened.
The MSMQ messaging system uses data files (\system32\msmq\storage) to store
the actual messages and also to log transactional sequencing numbers;
additionally certain registry values are continually incremented as messages
are sent. This applies to both sending and receiving machines. So if you
want to want to have a backup solution you will need to include all the
sending and receiving machines - instantaneously and simulataneously - so
that all of the sequencing information is kept in synch. If you backup
machine A at one point and then backup machine B a minute later while MSMQ
is still running, you've potentially lost information on messages exchanged
between the two machines in the interval. So a traditional "hot" backup
approach is not practical and probably won't provide the confidence you need
in the data.
A proper "backup" of MSMQ needs to be implemented through resiliant design
in the systems you are running, either in the applications or the hardware.
For example:
1 App Y on Machine A sends a transactional message to Machine B with a
TimeToBeReceived of "x" minutes
2 Machine B loses the message somehow (disk failure, for example).
3 The message is therefore never received by App Z on Machine B.
4 Machine A waits for TimeToBeReceived to expire and puts a copy of the
message in Transactional Dead Letter Queue
5 App Y is monitoring the Transactional Dead Letter Queue and sees the
dead message
6 App Y resends the message
Another example:
1 App Y sends the same message to both Machine B and Machine C
2 App Z receives message from Machine B, processes it successfully and
deletes the copy on Machine C
If Machine B is down, App Z uses Machine C instead
Or you can use high-availability approaches like clustering the MSMQ server.
Better still, don't leave the data in the 1,000+ queues - put it into SQL
server instead and read it from there later when you need the information.
Cheers
John Breakwell (MSFT)
"RCIC" <RC...@discussions.microsoft.com> wrote in message
news:4A03F10E-5561-43FC...@microsoft.com...